Most people I talk to are still using "agent" to mean two different things at once. Sometimes they mean the model doing the task. Sometimes they mean the software that wraps the model, holds the conversation together, and makes the whole thing fit into a real day at work. Those are different categories, and conflating them is making it harder to build the second one well.

The shorthand we use at the studio is simple. An agent is a task-doer. A workmate is the thing that turns one or more agents into a teammate.

Why the distinction matters

When you treat the agent as the whole product, you optimise for the wrong things. You spend your design budget on chat surface area and your engineering budget on model selection. You end up with a demo that lands well in a meeting and a product that struggles the second the user blinks. The agent forgets, the conversation resets, the team's conventions never make it into the next session, and the human ends up doing the coordination work that the software was supposed to absorb.

When you treat the workmate as the product and the agent as one component inside it, the priorities shift. Memory becomes a first-class concern. Handoff becomes a designed event. Role and persona stop being prompt-engineering tricks and start being product features. The agent is still doing the work, but the workmate is what the human relates to.

What a workmate actually is

A workmate has at least four parts. It has memory that survives sessions and model swaps. It has a sense of role — who it is acting as, on whose behalf, with what authority. It has a model of handoff — when to escalate to a human, when to bring in another agent, when to wait. And it has an operating layer that lets a team see what it has been doing, intervene if needed, and learn from the patterns over time.

A workmate remembers what the agent forgot. It speaks the team's vocabulary. It hands off, follows up, and keeps the thread going.

None of these are unsolved research problems. They are product problems. The reason they keep getting deferred is that the agent is shinier, the agent is easier to demo, and the agent is what gets covered in the press. The workmate layer is unglamorous. It is also where most of the value lives.

The shape of the work ahead

If you are building in this space, two practical pieces of advice. First, write the role description for your workmate before you write the prompt for your agent. The role description is what tells you which memories matter, which handoffs need to be smooth, and which conventions the workmate has to internalise. Second, watch your users on a Tuesday afternoon — not in a demo, not on a Wednesday morning when they are paying attention — and notice what they have to remember on the workmate's behalf. Every one of those moments is a workmate feature waiting to exist.

The agent is the worker. The workmate is the colleague. Build for the colleague, and you will end up with something a team can actually rely on.