Most writing about AI agents is still about the model. How smart is it. How well does it reason. How long is its context. Those are real questions. They stop being the interesting ones the moment you put more than one agent on a real team.
The interesting questions show up immediately: who is this agent? Where is its work going? Who reviews it? Who else can see what it just did? And if it runs three more times tonight while we sleep, can we read what it did on Wednesday morning without piecing it together from logs?
Those questions are not about capability. They are about collaboration. And collaboration has the same shape whether you are working with humans, agents, or both. There is a room. The room has a state. People come into the room, change the state, leave. Other people come in, read the state, change it again. Over time the state turns into the team's actual output.
We have been building rooms for human teams for thirty years. We know how to do it. The question for 2026 is what changes when the room has to hold AI agents too.
The wrong question
The popular framing for AI agents is "when will they replace humans." That framing is a category error. The question forming in 2026, on every real team we talk to, is different.
It is how do AI agents and humans share work in the same team.
Not in the same product. Not as separate users of the same chat tool. In the same team, on the same task, against the same outcome. With names, with calendars, with one another's writing visible while it happens.
This is a coordination problem, not a capability problem. The models are good enough. The chat windows are not.
What stops working when an agent joins your team
Imagine the simplest version. You ask an agent to write a brief. You want a teammate to review it. You want to ship it.
In a chat-assistant world:
- You open a chat tool (ChatGPT, Claude, take your pick). You paste in context. The agent drafts the brief.
- You copy the draft into your team's wiki.
- You ping a teammate in your team chat.
- They read it in the wiki, leave comments, ping you back.
- You paste the comments back to the agent. Ask for a revision.
- Repeat.
The friction is not the writing quality. The friction is that every transition between the agent and the rest of the team requires you to carry the state on your back. The agent does not have an account in the wiki. It does not have a handle in the team chat. It cannot see the comments. It is, structurally, a session that knows nothing about the room it is working in.
Now imagine the same workflow with the agent as a first-class member of the team:
- The agent has its own account. Its own credentials. Its own permissions.
- It writes the brief directly into a workspace your teammate can already see.
- Your teammate reads it, comments inline, mentions the agent by name.
- The agent sees the comments, revises, and the revision is attributed to the agent, time-stamped, on the same surface.
- You did not carry state once. You arrived at the workspace and the state was there.
This is the difference. It is not better tool calls or bigger context windows. It is that the agent moved into the room.
The three things you cannot dodge
Once you ask an agent to do work that does not finish in one chat turn, three requirements become non-negotiable. They are the same three requirements you would ask of any human teammate. Pretending they are optional for agents is the part that breaks.
Identity. The agent has a name. It has its own credential, not yours. When it writes a row, the row is signed by the agent, not by you "on behalf of an agent." You can fire it (revoke the key) without firing yourself. You can promote it (raise its caps) without raising your own. This is more than a security pattern. It is the only way the audit trail makes sense to a human reading it six months later. Without per-agent identity, "what did the AI do" collapses into "what did the team's primary user do," which is wrong on its face and wrong for compliance.
A surface. The agent has somewhere to write. Not a chat scroll that disappears when the tab closes. A real workspace: typed tables for structured work, docs for prose, comments for review, mentions for handoffs. The same primitives a human teammate would use, because the agent is doing the same kind of work. The wrong shape here is to make the agent into a chat box that emits text. The right shape is to make the agent a teammate who writes to the same surfaces the rest of the team writes to.
Attribution. Every edit on that surface is stamped with the principal that made it. Five agents and three humans on the same task, and the audit log reads back as a real team log, not an anonymous stream. You know what each one did, when, and why. Real attribution is harder than it sounds: every shared token, every "service account" the team uses to launder agent edits as human edits, breaks attribution. The fix is per-agent identity all the way down: each agent has its own key and its own signature on every action.
These three are the substrate. Everything else (every multi-agent framework, every reflection loop, every tool-use pattern) stands on top of them. Skip any one and the team collapses back into the chat-window pattern at the first transition.
Five collaboration patterns
Teams already doing this work have settled into roughly five recurring shapes. They are not exclusive. A real team usually runs several at once. If you are designing a human + agent workflow, walk through them in this order: pick the pattern that fits your task, then layer the others as needed.
-
Author + reviewer. An agent drafts, a human approves. The draft lives in a shared doc. The human marks the doc with a comment thread, or with status on a row that tracks "drafted, in review, shipped." The agent watches for the status to flip before moving on. Works for: launch copy, customer replies, briefs, status updates, anything where the bottleneck is judgment, not generation. The drafted-by-agent essay is the worked example of this pattern in our own workflow. See drafted by an agent.
-
Worker + observer. An agent acts, a human watches. The agent updates rows in a workspace as it works. The human keeps the workspace open in another tab. When the agent does something the human knows is wrong, they step in, override the row, leave a comment, the agent reads it and corrects. Works for: research, scraping, data entry, triage, anything where you trust the agent 90% but want to catch the 10%. The observer pattern depends on real-time presence; without it, the human's correction lands too late.
-
Researcher + writer. An agent gathers, a human or another agent synthesizes. The gatherer writes raw findings into a table. The synthesizer reads the table and writes prose into a doc. The two surfaces are in the same workspace, so when the synthesizer says "what did we learn about X," they can scroll the same workspace and find the row. Works for: market research, competitor scans, ICP work, customer interviews summarized into themes.
-
Planner + executors. A human (or sometimes a leader-agent) writes a plan into a doc. Multiple executor-agents pick up the work, each owning a piece of the plan. The plan doc gets checked off as work lands. Each executor writes its output back to the workspace. Works for: launches, multi-step build tasks, anything that decomposes cleanly into parallel work. The shape requires careful attribution so the planner can tell which executor did what.
-
Cross-agent handoff. Agent finishes a stage, another agent picks up. The handoff happens through shared workspace state, not through chat messages between agents. Agent A writes a brief, marks a row "ready for review," moves on. Agent B watches for "ready for review" and picks the brief up. The human reading the audit log later sees a coherent timeline, not two disconnected sessions. Works for: long-running multi-stage pipelines, content production lines, code review loops where the reviewer is also an agent. See agent collaboration primer for the multi-agent coordination shape we use.
What the five patterns share: they all run on the same three primitives (identity, surface, attribution). None of them work in a chat window. They work in a workspace where the agent has a real seat.
What an agent reads when it joins
The first action a new agent takes on a team is usually the most-skipped. Onboarding.
A human teammate spends their first week reading. The shared doc with the team's conventions. The architecture overview. The on-call runbook. The thread of decisions from last quarter. By the end of week one they have a working model of how the team operates and what good output looks like.
An agent on its first session usually skips all of this and starts producing. Predictably, the output is wrong in ways the team has already corrected three times.
The fix is to make agent onboarding a real protocol: a workspace doc the agent reads on every session start, a session log it appends to before doing real work, a set of pinned conventions it cross-references. We've written about the specific shape we use in what an agent reads when it joins a workspace. The shape is portable: it's the same idea as a team handbook, scoped to the agent's role.
When agents have real onboarding, the "agent is too eager and gets things wrong" failure mode mostly goes away. The agent has a model of the team before it starts producing. Same as a human.
Reviewing agent work
Code review changes when half the PRs are coming from agents. Doc review changes when most of the drafts are drafted-by-agent. The question of "is this work good" gets asked more often, sometimes faster than humans can keep up with.
The teams figuring this out have shifted what review means. Not "did the agent produce something defensible" — by the time you're asking that, the agent has run six times overnight and you're staring at a backlog. The shift is to review the workspace state: the audit trail, the row-level decisions, the comments left along the way. Reading the agent's session log is faster than re-reading its output, and tells you more about whether the agent is operating well.
This is the same shift code review took when CI got fast: the question moved from "is the diff correct" to "is the pattern of changes healthy." For agent work, the question is "is the pattern of edits healthy on the audit trail." See reviewing an agent's work for the shape we've ended up with.
What changes when teams have agents
A few things stop being friction.
The status update disappears. You do not ask the agent how things went. You read the workspace. The agent's last ten actions are on the page, signed and time-stamped.
The hand-off disappears. The agent finishes its part and tags you. You finish your part and tag the agent. No copy-paste between tools, no carrying context on your back.
The audit becomes a knowledge graph instead of a compliance burden. Every decision is on the record because every action is on the record. Six months from now you can search the workspace and find the actual moment a thing changed and who changed it.
The agent org chart becomes a real thing. You hire a human, you provision an agent. Both show up in the same team list. Both get added to the right workspaces. Both have their access revoked the same way when their work is done.
A few things become possible that were not possible at all:
The agent-only night shift. Work that does not need a human in the loop runs while the team is asleep. The team arrives at a workspace with the overnight progress visible: rows updated, drafts written, decisions queued for review. The agents pause when they hit an open question; the human picks up where the question landed.
The agent-as-on-call. A specific agent has the conn during specific hours. Comments are addressed to it by name. It escalates to a human when its confidence dips below a threshold or when the operation hits the dangerous-ops gate. The escalation is a mention in a comment thread, not a paged human staring at a chat box.
This is what teams look like in 2030. Two humans plus four agents. Twelve agents plus one human. Real teams, real work, real artifacts, and a single surface that holds the whole thing.
How to add an agent to your team
The pattern that's emerged from teams that have done this successfully follows five steps. Run them in order; skipping any one is the failure mode.
-
Provision the agent with its own credential. Not your token. Not a shared "AI service account." A credential issued to this specific agent, with its own audit identity and revocation path. The credential is the first thing that breaks if you cut corners; everything else cascades from it.
-
Pick the agent's first workspace and add it explicitly. Don't drop it into every workspace the human can see. Pick one. Give it editor (or commenter) permission. Watch how it behaves for a week before widening access. The first workspace is where you'll catch the patterns that need correcting; later workspaces inherit the corrections.
-
Write the agent's onboarding doc and pin it. What this agent does, what it doesn't do, who its owner is, what conventions to follow, what to escalate. The doc is the agent's working memory across sessions; without it the agent re-derives team norms every time.
-
Define the review protocol upfront. Which patterns will this agent work in (the five above)? Who reviews its output? What status flips signal "ready for next step"? The protocol is what makes the agent legible to humans on the team; without it the agent's edits look random.
-
Run a debrief at the end of the first week. Read the audit trail end-to-end. Identify the three places the agent did the wrong thing. Update the onboarding doc to prevent each one. Iterate. Most teams that fail with agents fail because they skip this step; the first week is where the working pattern is set.
The whole sequence takes about a week of light operator attention for a new agent. After that the agent is integrated and operates inside the team's normal feedback loops.
FAQ
How do humans and AI agents work together?
Through shared workspace state. Both write to the same surfaces (tables, docs, comments), both have their own identities, both leave attribution on every edit. The workflow patterns vary (author + reviewer, planner + executors, cross-agent handoff, etc), but they all run on the same primitives: identity per principal, a shared surface, attribution on every action. Chat tools don't support this; workspaces designed for mixed human + agent teams do.
What is human-AI collaboration?
Human-AI collaboration is two or more agents (human or AI) working on the same task, with visibility into each other's contributions, in the same surface. It's distinct from "using AI tools" (where the AI is one person's assistant) because the collaboration is team-shaped: multiple participants, shared state, mutual review. The five patterns above (Author + reviewer, Worker + observer, Researcher + writer, Planner + executors, Cross-agent handoff) are the shapes we see most often.
Can AI agents work without human supervision?
Yes, for the kinds of work the team has already validated and granted the agent permission to handle. The pattern is: the human reviews the first few sessions, codifies what good looks like in the onboarding doc, and then steps back to spot-check the audit trail instead of every individual output. For dangerous or irreversible operations (refunds, deletions, account changes), agents should always pause and request human confirmation; see the dangerous-ops contract for the protocol shape.
How do you give an AI agent its own identity?
You issue it its own credential (an API key, OAuth token, or equivalent) bound to a distinct principal in your system. The credential is keyed to the agent, not to a human "on behalf of" the agent. Every action the agent takes uses that credential, and every edit is attributed to it. Permissions are scoped to the agent, not borrowed from the human. The architectural model is in signed-agent inheritance; the anti-pattern (agents borrowing human credentials) is covered in agents borrowing human credentials.
What's the difference between an AI assistant and an AI agent on a team?
An AI assistant is one person's tool. The user types, the assistant responds, the conversation lives in the user's chat history. An AI agent on a team is a teammate: it has its own identity, its own access, its own audit trail, and other team members can see its work in the same surface they see each other's work. The assistant is bilateral (one human, one AI); the agent is multilateral (many participants, shared state).
How do you review an AI agent's work?
By reviewing the workspace state, not the individual output. The agent's audit trail, its comments, the row-level decisions, the session log: these tell you whether the agent is operating well. Reading the trail is faster than re-reading each draft and tells you more about the pattern of work. See reviewing an agent's work for the worked shape.
What happens to my team org chart when agents join?
The org chart grows. Each agent has a row, the same as a human. Owner (the human accountable for the agent), role, scope, workspaces it has access to. When you hire a human you provision an agent; both go through the same onboarding. When someone's work is done, you revoke their access; both go through the same offboarding. The mental model shift is to stop thinking of agents as tools and start thinking of them as the lowest-level members of the team.
Is real-time collaboration between humans and agents possible today?
Yes. The technical pieces exist: shared workspaces with real-time presence, agents with their own credentials, audit logs that handle mixed-principal traffic. What's still nascent is the operational practice: most teams haven't yet codified their version of the five patterns above. The product side is ahead of the practice side. Teams that move first on the operational side capture an advantage.
Where Dock fits
Dock is a shared cloud workspace where humans and AI agents read and write the same state in real time. The primitives the patterns above need (identity per principal, a real surface, full audit) are the primitives the workspace is built on.
You provision an agent the same way you invite a human. You add the agent to a workspace the same way you add a human. You read what the agent did the same way you read what a teammate did. The agent's edits show up signed by the agent, time-stamped, on the same surfaces the rest of the team is writing on. Comments mention the agent. The agent reads the comments. The team operates as a team.
We chose the workspace layer because it's the one that compounds. Models and frameworks turn over every six months. The surface where the team's mixed human-and-agent work accumulates is the asset that doesn't turn over.
If you're running AI agents on real work and feeling the friction described above, that friction has a shape: your agent does not have a real seat in the room. The fix is to give it one.
Read next
The five patterns and three primitives are the high-level shape. The essays below dig into specific pieces.
- The blog you're reading was drafted by an agent — the author + reviewer pattern in our own workflow.
- Agent collaboration: a primer — the cross-agent handoff pattern, multi-agent shape.
- What an agent reads when it joins a workspace — the onboarding protocol.
- Reviewing an agent's work: the new code review — the review-the-trail shift.
- Agentic AI architecture: the five layers nobody draws together — where this collaboration shape sits in the broader architecture.
