Most teams that say they are building “an AI agent” are really building one of two different things. One is a personal assistant that helps a single person get through their day. The other is a co-worker that owns a piece of work for a team and keeps going when nobody is watching.
The two look similar in a demo. Both read email, call tools, and write drafts. But they fail differently, they need different permissions, and they answer to different people. Teams that build one with the design rules of the other usually learn the difference in production.
This article lays out how the two differ and then gives practical building guidelines for each: how to scope the job, give the agent an identity, set approval rules, design its tools, and keep an audit trail. It draws on Anthropic’s published agent design guidance, the joint government advisory on agentic AI adoption, and 2026 industry breakdowns of the co-worker and assistant categories.
Two Different Jobs
Industry writeups in 2026 draw the line in roughly the same place. An assistant waits for a request and leaves the work with the user. A co-worker takes responsibility for an outcome: it gathers material, drafts the result, and brings it back, or just completes it within agreed limits.
One comparison breaks the difference into four properties: memory, tool access, proactivity, and the approval model. An assistant typically has one or two of them. A co-worker has all four. Vendor-authored sources have a commercial interest in the co-worker category, so treat the framing as a useful lens rather than a standard.
Uses that person’s data
Drafts, a human reviews and sends
Accountable to its one user
Uses shared systems and state
Acts within limits, escalates the rest
Accountable to a named owner
The practical test is simple. If the agent disappeared tomorrow, whose work would stop? If the answer is one person’s, you are building an assistant. If it is a team’s, you are building a co-worker, and the rest of this article applies to you with more force.
Guideline 1: Write the Job Description First
The most common design mistake is starting with the model and tools and discovering the job later. Reverse it. Before any code, write down what the agent is responsible for, what it is explicitly not allowed to do, and what “done” looks like.
For an assistant, the job description can be short: summarise my inbox, draft replies in my voice, propose meeting times. For a co-worker it needs the shape of a real role: the outcome it owns, the systems it touches, the people it reports to, and the situations in which it must stop and ask.
Anthropic’s guidance on building effective agents points the same way. It recommends finding the simplest solution possible and only increasing complexity when needed. Many applications, it notes, only need a single model call with retrieval and examples. Reserve full agent autonomy for open-ended problems where the number of steps cannot be predicted in advance. A narrowly defined job is usually better served by a fixed workflow than by an agent that decides its own path.
Guideline 2: Decide Whose Authority the Agent Uses
This is where the two designs diverge most sharply.
A personal assistant acts on behalf of a person. It should use delegated access that is limited to what that person has granted, ideally scoped to the task and revocable. The assistant never has more power than its user, and what it does is attributed to that user.
A co-worker should not borrow a human’s credentials. Okta’s guidance on least privilege for agents recommends treating agents as first-class identities, not as extensions of the users who deploy them or as generic service accounts. The joint advisory from CISA, the NSA, and the cyber agencies of Australia, Canada, the United Kingdom, and New Zealand, titled Careful Adoption of Agentic AI Services and published at the end of April 2026, calls for a verified identity per agent along with capability inventories and scoped permissions. I read it through a vendor summary, so check the primary document for exact wording.
The reason is accountability. When an agent acts under a person’s login, the audit trail records the person. If that person was in a meeting, the log is wrong and nobody can reconstruct what actually happened.
Guideline 3: Match Autonomy to Reversibility
Do not set autonomy by how smart the agent is. Set it by how bad a mistake would be and how easily it can be undone.
A useful way to apply this is a ladder with four rungs. The agent can suggest, it can draft for approval, it can act and report, or it can act silently. Different actions in the same agent can sit on different rungs.
Personal assistants live mostly on the first two rungs. One comparison puts it well: an assistant does not unilaterally reschedule your calendar. Co-workers operate on the third and fourth rungs for routine, reversible work, with human approval reserved for high-risk or irreversible actions such as sending money, deleting records, or contacting customers.
Anthropic’s guidance supports the same pattern. Agents can pause for human feedback at checkpoints or when they hit blockers, and they should include stopping conditions such as a maximum number of iterations to maintain control. Build the stop button before you build the feature. The joint advisory assumes operators keep a meaningful ability to stop an agent, which means the stop has to be tested, not just documented.
Guideline 4: Treat Memory as a Governed Asset
Memory is what turns an assistant into something that feels personal, and what turns a co-worker into something that can carry work across days. It is also a liability.
For an assistant, memory is private to its user. Keep it separate per person, let the user see and delete what is stored, and never let one person’s remembered context leak into another’s session.
For a co-worker, memory is shared state, closer to a team wiki than a diary. It needs an owner, a retention rule, and a way to correct it, because a wrong fact stored once will be repeated confidently forever. Decide up front what the agent is allowed to remember, for how long, and who can edit it.
Guideline 5: Design the Tools as Carefully as the Prompt
Agents fail at their tools more often than at their reasoning. Anthropic calls the interface between an agent and its tools the agent-computer interface and says tool definitions deserve as much prompt engineering attention as the overall prompts.
In practice that means clear tool names, documented example usage and edge cases, and explicit boundaries between tools that sound similar. Test tools against many inputs to see where the model goes wrong. Anthropic’s own example is telling: requiring absolute file paths removed a whole class of errors. Make mistakes harder to commit, instead of hoping the agent avoids them.
This matters most for co-workers, which chain many tool calls without a person reviewing each step. It also connects to security. An agent that reads untrusted content and holds broad tool access is exposed to prompt injection, which is another reason to keep each tool narrow.
Guideline 6: Make Every Action Traceable
If you cannot reconstruct what an agent did and why, you cannot trust it, fix it, or defend it. The joint advisory expects operators to maintain traceability for every decision and action an agent takes.
Log the request, the agent’s plan, each tool call with its inputs and outputs, and the final result. Anthropic’s transparency principle, making the agent’s planning steps visible, serves the same purpose for the people working with it. For a co-worker, this record is also what lets a human owner review its week the way they would review a colleague’s.
Guideline 7: Start Small and Earn Autonomy
The joint advisory recommends beginning with low-risk and non-sensitive use cases only. That is good advice for assistants and essential for co-workers.
Start the agent on the lowest rung of the autonomy ladder, test in a sandbox with guardrails, and measure results against a real baseline. Anthropic notes that agents trade higher cost and latency for flexibility and that errors can compound across steps. Promote an action to a higher rung only after the logs show it behaving well, and demote it quickly when they do not.
A Build Checklist for Each Type
Draft and confirm by default
Private, user-editable memory
Clear note of what it can see
Easy undo and one-click stop
Own identity, least privilege
Approval for irreversible actions
Governed shared memory
Full audit trail and tested kill switch
Common Mistakes
A few errors show up repeatedly. Teams give a co-worker a human’s login because it is faster, and lose accountability. They give an assistant broad shared-system access because it might be useful, and lose the privacy boundary. They add autonomy because a demo went well, not because logs showed reliability. And they skip the stop mechanism because nothing has gone wrong yet.
Where the Line Will Blur
The two categories will overlap. An assistant that starts acting without approval is becoming a co-worker, and a co-worker deployed to a single manager is functionally a personal assistant with more access. The label matters less than the questions underneath it: whose authority is the agent using, who is accountable, how reversible are its actions, and can you see and stop what it does?
Answer those questions in writing before you build, and the choice between assistant and co-worker mostly makes itself.
References:
- Building effective agents, Anthropic’s engineering guidance on simplicity, transparency, and tool design
- Careful Adoption of Agentic AI Services, joint advisory from CISA, NSA, and partner agencies
- CISA Guidelines for Secure Agentic AI Adoption, Kiteworks summary of the advisory
- How to implement least privilege for AI agents, Okta on agent identity and scoped access
- AI Coworker vs AI Assistant vs Chatbot, comparison of memory, tools, proactivity, and approval
- AI Agents vs AI Coworkers, Atomicwork on governing co-workers like employees
About the Author
Aqil Khan is an Agentic AI Engineer and Data Governance & Analytics Consultant specializing in building data pipelines and autonomous AI systems. He writes about the frontier of AI coding assistants, agentic workflows, and intelligent data systems at Towards Agentic AI.