AGENTUX

The release of the Buzz platform by Block puts a spotlight on an agentic problem I’ve been working on for quite a while:

“what UX/UI for AI agents used jointly by a team, and not necessarily dev/tech people?”

Live in the workflow, not beside it

My long-standing position is that agents must interact in the middle of the workflow, so no dedicated app that requires an extra interface — Slack, Teams, GChat, email, in short whatever is already used in a company to communicate.

Everything has to be doable from these interfaces: creating a new agent specialized on a subject, doing CRUD on documents and artifacts, configuring users, and so on.

Running commands in natural language is possible (“You’re going to create an agent dedicated to project XXX for client YYY with Thierry as owner”). But it’s more interesting to aim for a platform that allows the creation of rich micro-applications, easy to use. /slash commands are nice, but we’ve already lost every non-tech user at that point.

The per-project workspace

Another complex point is the segregation of workspaces and the management of contexts / sessions.

Imagine a law firm with several specialties, say employment law and administrative law — I don’t know a thing about it and that’s not the point. This firm is equipped with two agents specialized on each of these types of law, callable on the fly for every matter: for the dismissal of Dominique S., an employment-law agent will be created and dedicated to that matter — documents, reports, timeline.

As with human beings, you create a dedicated workspace, with its own resources and dedicated collaborators. This workspace is not a new application: it’s a channel, plus a knowledge base linked to that channel. You stay in the existing communication tool, but each matter keeps its own context, isolated from the others.

DM: the easy case

Now let’s talk about agent/human interactions. Ideally, as with any coworker, the agent can be reached by DM and added to a channel dedicated to each case: it has to be immersed where the exchanges are happening.

For DMs, no problem: the user interacts directly with the agent. What remains is managing sessions and context. For reasons of the job itself, of cost, and of performance, the user has to be able to easily start a new “conversation”, that is, create a new working session with the agent.

It’s complex with WhatsApp, for example, for lack of topic or thread management, unless you set up rules for creating a new session programmatically — a /new, for example, which remains complicated and hardly usable for most users — or by using an LLM to detect whether the message requires a new session or the continuation of the existing one. This last approach works, but it adds a layer of ambiguity and cost to every message.

This is where Slack-type messaging tools perform well, with the notion of a thread: one thread = one working session, and contexts can be controlled and isolated properly. A lawyer wants to do case-law research? A thread. Prepare an oral argument from the case documents and the agent’s memory? A thread.

The shared channel: where everything gets complicated

Where it really gets complicated is the agent’s interaction with several users in a shared channel.

Back to our example: in a channel dedicated to the “Dominique S.” case, there are three lawyers, a jurist, an assistant, an intern, and Bob, our AI agent. If the agent replies to everyone in the main channel, chaos is guaranteed: loss of context, spam, costs that explode, and crossed misunderstandings — I don’t use the word “hallucination” by chance: in agentic systems, a hallucination is most often the fruit of bad context engineering, not of an intrinsic defect in the model.

If someone asks a question by tagging the agent @bob, the simplest thing is to create a thread: the agent replies by opening a thread with its own context. But what happens if the tag references previous exchanges — “hey @bob, what do you think?” It’s on the implementation to provide the context needed to create that thread and that session, the real difficulty being knowing what to provide in order to contextualize well, without drowning the agent or blowing up the costs by replaying the whole history every time.

Who has the right to know what

Another difficulty, more structural still: imagine it’s Coralie, the lead lawyer, who calls on the agent, and Thierry the intern who steps in later in the same thread. If the agent is implemented in the simplest way, Coralie = Thierry = “user”, and the agent treats the two the same way.

But does Thierry have the same rights as Coralie? In a DM, the answer is simple: Thierry cannot, for example, contact the opposing party or its agent. The rule is binary and easy to lay down up front.

In a shared channel, it gets complicated along two different axes:

• A vertical axis, hierarchical: the intern doesn’t have the same authorizations as the lead lawyer, and the agent should be able to adapt its register, what it reveals, or what it executes, according to who’s talking to it.
• A horizontal axis, brought up more rarely: as agents come to interact with one another, potentially with another organization’s agent (the opposing party’s lawyer, for example), the question is no longer only “who on my team has the right to know what”, but also “which external agent has the right to talk to which agent, and about what”. It’s an access-control project that goes well beyond prompt engineering: it touches authentication, ACLs, and a role repository that has to be mapped to the identities of the communication platform being used.

The experience starts to get really interesting when you manage to convey to the agent that it is in conversation with N people and their respective roles: it can then adapt its behavior, modulate its rights of action, refuse certain requests depending on the person it’s talking to. But this complexity is far from negligible, and it’s harder still because it remains strongly dependent on the communication platform used — Slack, Teams, and Gmail don’t expose the same role primitives or the same identity guarantees.

In summary

Getting an agent to talk in Slack is easy. Making it so that users can interact with it like a colleague, taking their rights into account, is a bit more complex.