For most of 2024 and 2025, "AI agent" meant a chat surface with a tool-call protocol attached. You typed a prompt, an LLM picked a tool, the tool ran, the result came back, you typed again. The agent was a session. When the session ended, the agent ended.
That model is now visibly cracking. Real teams want agents that persist, that have their own work surfaces, that you can hand a Tuesday to and check on Wednesday morning. The minute an agent has to do anything beyond a single conversational turn, three problems show up:
- Whose credentials does it use?
- What is it allowed to do?
- Where does its work live so a human can review it?
Each of these has a name. The names are identity, authorization, and shared workspace. Most products today solve one of the three; almost nobody solves all three end-to-end. This piece is about why solving all three together is the actual job, and what falls out when you do.
The shape of the problem
A useful way to see why agent collaboration is hard is to imagine the simplest version: you want an AI agent to draft a launch post, you want a human teammate to review it, and you want to ship.
In a chat-assistant world, the workflow looks like this:
- You open ChatGPT (or Claude, or whichever).
- You paste in some context. The agent drafts a launch post.
- You copy the draft into Notion.
- You ping a human teammate on Slack to review.
- They read it in Notion, leave comments, ping you back.
- You copy the comments back to ChatGPT, ask for a revision.
- Repeat.
The friction here is not the AI's writing quality. The friction is that every transition between the agent and the rest of the team requires a human carrying state on their back. The agent doesn't have an account in Notion. It doesn't have a Slack handle. It doesn't have permissions to comment on its own draft. It is, structurally, a session that knows nothing about the room it's working in.
Now imagine the same workflow in a system where the agent is a first-class member:
- The agent has an account named Argus. Argus has its own credential, its own Slack handle, its own permissions.
- Argus drafts the launch post directly into a workspace your human teammate can already see.
- Your teammate opens the workspace, reads, comments. Argus sees the comments. Argus revises. The revision is attributed to Argus, time-stamped, on the same surface.
- You don't carry state. You arrive at the workspace and the state is there.
That's the difference. Not better tool calls, not bigger context windows. The difference is that the agent has moved into the room.
Three things have to be true for the agent to live in the room: identity, authorization, shared surface. We'll take them one at a time.
Problem 1: Identity
When an AI agent does something on your behalf today, who actually does it?
Answer: usually you do, on paper. The agent runs as your user, with your token, leaving an audit trail that says you wrote the post, you sent the message, you upgraded the plan. This is the path of least resistance for product builders, and it is wrong in three concrete ways.
It's wrong for security. When a human user is compromised, the blast radius is whatever that human had access to. When an agent embedded in that user is compromised — through a prompt injection, a poisoned source, a bad model output — the blast radius is the same, but the attacker is now an automated system that can act faster and more coherently than a human. Not having a separate identity for the agent means you can't isolate it, you can't revoke it without revoking the human, and you can't draw a line in the audit log between "what the human did" and "what the agent did under the human's name."
It's wrong for accountability. Who do you talk to when an agent does something you didn't expect? "The user who was logged in" is the answer in chat-assistant land, but the user wasn't really there — the agent was. As products start running agents asynchronously (overnight runs, scheduled tasks, long-horizon work), the gap between who triggered an action and who the action appears to be from grows. You need audit lines that read "Argus, drafting on behalf of Govind, at 2:14 AM," not "Govind, at 2:14 AM."
It's wrong for collaboration. Humans treat coworkers differently from tools. You give a coworker their own desk, their own login, their own Slack handle. They build a track record. You learn what they're good at. You promote them, expand their scope, sometimes restrict it. None of this is possible when the agent is a process living inside your account. The agent has no track record because it has no record at all — it's just you with extra steps.
The fix is straightforward to describe and surprisingly hard to ship: every agent gets its own identity. Its own user record in the database, its own credential, its own attribution stamp on every write. The agent's owner is a human, but the agent is not the human.
We covered this in detail in Why agents need their own identities — that piece is the deep dive on the architectural shape. The point for this primer is that identity is the foundation. Without separate identity, the next two problems can't be cleanly solved.
Problem 2: Authorization
Once your agent has an identity, the next question is what that identity can do.
Authorization for agents looks superficially like authorization for humans — roles, scopes, permissions — but it has at least three properties that human auth systems don't have to deal with:
Agents are fast and tireless. A human reviewer can grant an agent the permission to "send emails to customers" with a mental model of "they'll send maybe twenty per day." The agent will send a thousand per day if you don't stop it, and the rate limit is a poor stand-in for the intent of the permission. This means scopes have to be more granular and rate-aware than scopes for humans usually are.
Agents make irreversible mistakes. A human accidentally flipping a billing plan from Free to Scale is recoverable — you cancel, you call the customer, you refund. An agent that decides to upgrade a plan based on a misread row in a sheet has just charged a real card, and the recovery is the same call but at scale. The rule of thumb here is simple: any operation an agent can perform that cannot be undone with a click needs a confirmation handshake.
Agents do things humans wouldn't. Humans use the path-of-least-resistance for most tasks because friction is high. Agents have low friction, so they explore the search space. An agent given access to a "delete row" tool will, eventually, delete a row that didn't need deleting, because it found a path through your prompt where deletion was the locally optimal move. The protection here is consent gates — a class of operation that is gated by a two-call handshake, where the agent proposes the operation, surfaces it to its human, and only executes after the human confirms with a fresh signed token.
We covered the concrete pattern in Consent gates for dangerous operations. The cluster around this pillar — pieces on OAuth scopes, two-key handshakes, the dangerous-ops contract — goes deeper.
The key idea: agent authorization is not "give the agent the same permissions as the user, but with a token." It is a separate problem that needs separate thinking. An agent's scope should be less than its owner's by default, expanded explicitly per task, and revoked aggressively. Treating agents like junior team members with probationary permissions is closer to the right mental model than treating them as services.
Problem 3: Shared workspace
Identity and authorization let the agent exist and act. The third problem is where it actually does its work.
The dominant pattern in 2025 was: the agent works inside its own UI (a chat panel, a side drawer), and produces an artifact that the human imports somewhere else. The artifact crosses surfaces. The agent's "work" stays in chat history; the human's "work" stays in their tools. There is no shared surface where both contribute and both can see what the other has done.
This is the equivalent of having a remote employee who can only communicate by email — every artifact is a fresh attachment, every revision a fresh thread, every status check a fresh ask. Real collaboration requires a shared surface. For human teams, that surface is their workspace: the doc, the table, the project board. The same has to be true for agents.
A shared workspace in this sense is a surface where:
- The agent and the human can both read and write.
- Every write is attributed to its author, agent or human.
- State persists between sessions — the agent doesn't start fresh each time.
- Reviewing an agent's work happens in the workspace, not in a separate review tool.
- New agents (or new humans) joining the workspace inherit the history naturally.
The reason this matters is that the workspace becomes the unit of context. You don't have to brief the agent every time. You don't have to copy state from one place to another. You don't have to maintain a parallel system of "here's what the agent has been doing this week." The workspace is the system of record.
We covered the architecture in The shared workspace as the new collaboration primitive. The cluster around this pillar — what an agent reads when it joins a workspace, why chat is the wrong abstraction, the new shape of code review — drills into the consequences.
How the three fit together
Identity, authorization, and shared workspace are not independent problems. They are the three faces of a single shape, and you can only solve them together.
Consider what falls apart when one is missing:
Identity without authorization = the agent has its own login but can do everything the user can do. You've added a user to your audit log, but you haven't actually constrained the blast radius. This is most products that "added agent support" by minting service tokens.
Authorization without identity = scoped tokens that aren't tied to a stable identity. The token can be revoked, but you can't ask "what has Argus been doing this week" because Argus doesn't exist as an entity. The audit log is full of token IDs, not actors.
Identity and authorization without a shared workspace = the agent is a real, scoped entity, but its work happens in a tool the human has to leave their workspace to see. The collaboration falls apart at the surface boundary. This is most "AI assistants" today.
Shared workspace without identity or authorization = a workspace where every action is attributed to whoever was logged in, with no constraint on what an agent can do. This is what happens when teams retrofit an existing collaboration tool with an agent SDK and don't rethink the substrate. It works for one agent and one user; it fails the moment two agents share a workspace.
The architectural insight is that all three are properties of the member abstraction. A human teammate has identity (their name and login), authorization (what they can do in the workspace), and a shared workspace (the room they're in). An agent that's a first-class collaborator has all three, in the same shape, on the same substrate. Once you commit to that, the design problem stops being "how do we add agents to our app" and starts being "what does our membership model look like when half the members aren't human."
What changes when you commit to all three
A few concrete things shift when you treat agent collaboration as one problem:
Onboarding becomes a single act. When a new agent joins a workspace, it inherits everything a new human would: it can see the history, it knows the conventions, it has a name in the corner. You don't write a separate "agent onboarding" — the workspace is the onboarding.
Reviewing becomes a workflow, not a hand-off. A human reviewing an agent's draft does it in the same surface where the agent wrote it. Comments are inline. Revisions are attributed. The diff between v1 and v2 is visible. This is the pattern code review has had for fifteen years and that prose work has lacked.
Permissions become composable. Agents can be granted access to one workspace and not another, escalated for one task and demoted for another, all without minting fresh credentials each time. The workspace is the permission boundary, and the agent is a member with a role inside it.
Auditing becomes useful. The audit log records which agent did what in which workspace at which time, on whose behalf. When something goes wrong, you have an actual story to tell. When something goes right, you have an actual story to copy.
The case for building on this substrate
Most teams shipping agentic features in 2026 are still working in the chat-assistant pattern. They are doing it because the pattern is familiar, the dev cost is lower, and the user expectation has been shaped by ChatGPT.
The teams that will pull ahead are the ones who notice that the chat-assistant pattern caps out. You can't ship the use cases that require persistence, attribution, scoped permissions, or multi-agent coordination on top of a session-and-tool-call substrate. You have to swap the substrate, and the swap is painful — but it's a one-time cost, and once you've done it, every subsequent agentic feature is cheaper to build because the substrate carries the weight.
This piece is the start of a series. The companion pieces drill into the three sub-problems:
- Identity: Why agents need their own identities, Signed-agent inheritance
- Authorization: Consent gates for dangerous operations
- Shared workspace: The shared workspace as the new collaboration primitive, Why chat is the wrong abstraction for human-AI work
If you're building agentic features in 2026, the question to start with is not "what tools should the agent have." It's "what kind of member is the agent, and what room does it live in." Get that right and the rest follows.
FAQ
What is agent collaboration?
Agent collaboration is the pattern where AI agents and humans work together on shared tasks in a way that resembles how human teammates collaborate: each member has a stable identity, scoped permissions, and access to a shared workspace where work happens and gets reviewed. It is distinct from the chat-assistant pattern, where an agent is a session attached to a single user.
What's the difference between an AI assistant and a collaborating agent?
An AI assistant is an instance of a model attached to a user's session. It uses the user's credentials, runs while the user is present, and produces artifacts the user copies elsewhere. A collaborating agent is a first-class member of a workspace with its own identity, its own scoped permissions, and its own attribution on every action — humans and other agents can see what it did and review it on the same surface.
Why can't agents just use the user's credentials?
Three reasons. Security: a compromised agent inside a user has the user's full blast radius, with no way to isolate it. Accountability: the audit log can't distinguish between user actions and agent actions. Collaboration: a sub-process of a user can't have a track record, build trust, or be reviewed independently. The fix is to give every agent its own user-level identity tied to its owner.
What does a "shared workspace" mean in the context of AI agents?
A surface where humans and agents can both read and write, every change is attributed to its author, state persists across sessions, and reviewing an agent's work happens on the same surface where the agent did the work. The workspace is the unit of context — agents joining inherit history, permissions are scoped to the workspace, and the audit log records who did what inside it.
How do you secure dangerous operations when an agent has authority to act?
A two-call handshake (consent gate). The agent proposes the dangerous operation and receives a confirmation token, surfaces the proposal to its human owner, and only executes after the human confirms by replaying the token. The token is single-use, time-bound, and bound to the specific operation and parameters. Any operation that can't be undone with a click should be gated this way.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Agent collaboration: a primer for 2026",
"description": "What it actually takes to make humans and AI agents work in the same room. The three problems nobody is solving end-to-end, and the architecture that ties them together.",
"datePublished": "2026-04-25",
"author": {
"@type": "Person",
"name": "Govind"
},
"publisher": {
"@type": "Organization",
"name": "Dock",
"url": "https://trydock.ai"
},
"image": "https://trydock.ai/blog-mockups/style-d-dreamscape/agent-collaboration-primer.webp",
"mainEntityOfPage": "https://trydock.ai/blog/agent-collaboration-primer"
}