Why every AI coding agent is built for one user
It is 2 AM. PagerDuty fires. The on-call engineer opens Claude Code on their laptop. The context they need is a four-hour debugging session from the previous shift, locked to a teammate's session, on that teammate's machine, asleep.
Every AI coding agent on the market is built for one developer at a time. Claude Code is a terminal tool. Cursor's agents are scoped to a seat. OpenCode runs on one machine. Devin can be pinged from Slack, but the session it spins up is its own. None of this is a bug. It is an architectural choice, and for a solo developer it is the right one. This post is about what happens the moment the work involves a second person, because that is where the choice starts to cost something.
The single-user assumption, made concrete
Look at where each agent keeps its state and you can read the assumption straight off the design.
Claude Code is a terminal CLI. Your session, your context, your history live on the disk of the machine you ran it on. There is a Slack surface too, and it has gained real controls since launch, including per-channel invites. But the unit stays the individual. Per Anthropic's own docs, each session runs under your own Claude account, against the repositories you personally connected and your own plan limits. It is one developer's agent whether you reach it from a terminal or a thread, and a teammate cannot open the same agent and continue where it was.
Cursor's agents are tied to a seat. Cloud agents get full repository access and run in a VM; local agents run on your machine and collide when you try to run them in parallel. The whole tension was named in a popular r/cursor thread titled "Cursor is fighting the wrong war": "They rely on running agents in the cloud to achieve isolation, but I want my code and my agents running locally… Running agents in the cloud isolates them, but it makes jumping into the session to manually edit code a huge pain. I am also not comfortable giving cloud agents full repo access." Cursor's own engineering team conceded the early cloud path was rough, describing the original architecture as "a fragile setup" that in beta "often operated at one 9 of reliability." Either way the agent belongs to one seat.
OpenCode is terminal-only. There is no Slack or Discord surface to ship work through, so there is no shared place for a team to see what it did. Users report the single-machine harness is brittle on its own terms, from a r/opencodeCLI thread: "Errors used to be rare; now they're an everyday thing. Terrible performance problems… Prompts adrift."
Devin can be invoked from Slack as a thread, which is closer than the rest. But the agent's state is per-invocation, not shared across a team. Your teammate cannot open the same agent, see its reasoning, and keep going. Each run is a fresh session that happens to start in a channel.
Four different products, one shared shape. The agent is a thing one person operates, and its memory lives wherever that person is.
What breaks when teams try to use them
The assumption is invisible until a second human enters the loop. Then it shows up in three ordinary places.
On-call rotation. Back to the 2 AM page. The engineer going off shift spent four hours narrowing an incident with an agent on their machine. To hand off, they have to compress those four hours into a Slack message, because the agent itself cannot be handed over. The incoming engineer starts from that summary and a cold agent, not from where the work actually was. The continuity that mattered, the agent's own accumulated context, does not survive the shift change.
Async code review. A senior reviewer leaves a comment on a PR at 6 PM. The author picks it up at 9 AM. Overnight, an agent did the work on that branch. Neither human can open that agent and ask why it made a call, because its reasoning lived in a session that has since closed on someone else's machine. The review happens over the diff alone. The one participant who knows the most about the change, the agent, is not in the room.
Multi-engineer feature work. Two engineers share an epic. Each runs their own Claude Code session. There is no shared agent memory, no shared set of rules, no shared tool state. They are not collaborating with one agent that knows the project. They are each supervising a separate one, and reconciling the results by hand. The agent scales to the individual, not to the team.
None of these is a failure of the tool. Each tool does exactly what a single-user tool should. The gap is that most engineering work is not single-user. It is a rotation, a review, an epic with more than one name on it.
What multi-user actually requires
If you wanted an agent a team could share, four properties fall out.
An org-scoped runtime per agent. One agent, one persistent context, and multiple humans who can all interact with it. The state has to outlive any single person's session, because the whole point is that the next person picks up where the agent was, not where a Slack summary left off.
An identity-aware trail. When several people can trigger the same agent, every action has to stay attributable to the human who triggered it. Shared does not mean anonymous. You still need to reconstruct who asked for what.
Shared rules and tools at the org level. The agent's rules, its MCP servers, its credentials are configured once for the organization, not re-installed on each laptop. Otherwise every engineer rebuilds the same setup and they quietly drift apart.
Async by default. The agent finishes work and posts a result. A human does not need to be sitting at the machine for the agent to make progress, and does not need to be the same human who started it. That is what makes a rotation or an overnight review actually work.
Put those together and you are no longer describing a better CLI. You are describing a different unit of deployment, the team, not the terminal.
What Nairi does
This is the slot we built for. Nairi is a shared AI agent for your team in Slack or Discord: configure it once, connect your tools, and let everyone use it.
Each agent runs in its own org-scoped runtime, so the context persists across the humans who talk to it rather than living on one laptop. It is Slack and Discord first-class, not a terminal tool with a chat bolt-on, so the place your team already works is the place the agent works. Rules, tools, and secrets are configured at the org level, with credentials held in a per-agent vault and MCP servers scoped to the agent, so nobody is wiring up their own local setup. Actions stay attributable to the person who triggered them. And because it works in a channel, it is async by default: the agent finishes and posts back, and the next person on the rotation reads the thread, not a handoff note.
The on-call incident response use case is the 2 AM story with the assumption flipped: the agent, and everything it learned during the incident, is in the channel for whoever is on next. If you are weighing this against running Claude Code in Slack directly, we wrote up the difference in Nairi vs Claude Code for Slack.
We are honest about the edges. The shared-agent model is the part we are most confident in. The surrounding surfaces, richer permissions and a fuller audit view, are still being built, and we would rather say so than oversell them.
The honest version
Single-user CLIs are great. If you are a solo developer, Claude Code at your terminal is a genuinely excellent way to work, and none of this argues otherwise. The claim is narrower and, we think, harder to dodge: the moment your work involves another human reading or continuing what the agent did, the single-user assumption breaks. A rotation, a review, a shared epic. Most engineering work is that second category. The agents were built for the first one, and that is exactly why teams are starting to feel the seam.