Many people's first intuition about AI coworkers is that they should work like a team, with one agent per role. One for engineering, one for marketing, one that only writes blog posts.
We built it that way too. Okou let you create many agents in a workspace, each with its own name, avatar, Instructions, and Workflows. In August we even published a post about how multiple agents divide work and hand it off. Our own workspace had plenty of them. Lucas wrote our blog posts, Lisa did bookkeeping, Iris handled investor relations, and I had one called Emily that triaged my email.
But user intuition is only a reference point. Before Notion, people's intuition about document tools was that they needed headers and footers.
Multi-agent is also not a foundational capability. Foundational capabilities are the ones every AI product will eventually need: chat, making slides and websites, operating a computer. Multiple agents are not on that list.
Take Lucas, our former blog agent. About a third of its Instructions is the same generic template the default Okou uses. The rest is three specific procedures: how to publish a blog post in Strapi, how to write use case pages for our website, and how to produce the daily signup conversion report. All 13 Workflows attached to Lucas are public in the workspace. None of them belong to Lucas alone.
So the difference between Lucas and the default Okou comes down to a name, an avatar, and three procedures that should have been Workflows. Those procedures are locked inside Lucas. Ask the default Okou to publish a blog post and it has none of those rules.
As the number of agents grew, so did the combinations. Many agents, many Workflows, and many conversations all interact, and every combination is logic we have to maintain and users have to learn. We ran into questions we could not answer well from the user's point of view:
- Why can't two agents share the same Workflow?
- Why can I only talk to Okou in Slack, and not to my own private agent? If Lucas is a person, I should be able to reach it anywhere.
- Why is memory shared across all agents? If each agent is a person, each should have its own memory.
Each of these can be solved, but each one takes real engineering work. Leave them unsolved and multi-agent stays a half-finished experience. We also struggled to find a problem that only multiple agents could solve. The complaint we heard more often was that there were too many agents to manage.
So we decided that each person gets one Okou. The model is simpler:
- Every person has one default Okou.
- Your Okou belongs to you and is private.
- Your Okou and a colleague's Okou are not the same agent.
- Your Okou can use any Workflow that someone in your organization has made Public.
The things that used to hang off an agent now live where they fit better:
- Instructions belong to you. You write one set, and Okou follows it on the web, in Slack, and in automations.
- Workflows belong to the workspace. Anyone can use a Public Workflow a colleague publishes, and you can copy one and make it your own.
- Connected accounts belong to you, so you no longer pick which agent gets access.
- Conversations are grouped with Projects, by customer, project, or topic.
In this model, an agent is little more than a set of Instructions. The three procedures inside Lucas should become Workflows that anyone can use.
Multi-agent is really a management practice inside an organization, a way to manage what AI can do. Every organization has its own management methods, and no single set fits everyone. A single agent is closer to a tool, and tools are easier to understand and adopt. What users need most is to get the task done. Next comes a tool to do it. What they need least is a method for doing it.
Anthropic's Applied AI team saw something similar in a recent post on enterprise agent deployments. In their comparisons across several deployments, a single agent with skills frequently outperformed a design split into specialist subagents on quality, and often at a lower cost and latency per task. They also write that "too often we see enterprises give each team or problem type its own subagent, with the agent architecture becoming a copy of their org chart." Their post is about agent architecture rather than product design, though the reasoning carries over.
Looking across AI products today, we see four models:
- Many agents, many conversations. This was Okou.
- One agent, many conversations. ChatGPT, Codex, and Claude Cowork work this way.
- One agent, one conversation. Instinct works this way.
- Many agents, each with a single conversation. Grok bot works this way.
We had the most complex combination, and it did not solve more problems.
We know this is a breaking change. Two things kept us from making it sooner: asking you to learn a new way of working, with one Okou plus Workflows, and the lack of a clear path for what you had already built. Here is that path:
- Your conversations are still there. You can find them through Projects, search, and their original links.
- If you used different agents to sort conversations, use Projects instead. Keeping conversations grouped by category was the main reason many people created extra agents. Claude and ChatGPT solve the same need with Projects.
- If you wrote different Instructions for different agents, keep what they share in your personal Instructions and turn the specific procedures into Workflows.
The sooner we stop building abstractions on top of multiple agents, the better. When you open Okou, you no longer have to decide which agent to ask. Tell Okou what you need done, and it handles the rest.
