AI Teammate vs AI Agent: What Delegation Changes

AI teammate vs AI agent is not a rebrand — it is a change in the unit of delegation. An agent takes one task, runs, returns an output, and disappears. A teammate, as vendors now define it, keeps a persistent identity and memory, stays signed into your tools, works unwatched, and reports back by exception. Each of those four properties rewrites a piece of your operating model.

The timing is not subtle. On August 11, 2026, xAI shipped Grok Bot in beta and pitched it in exactly these words: “AI teammates you can give real work to.” Seven weeks earlier, Anthropic published two companion pieces on building human-agent teams and on giving agents their own identity and credentials. Two rival vendors, one shared claim: the thing you delegate to is no longer a prompt run — it is a persistent worker.

This guide argues the four operating-model deltas that follow — persistent identity and memory vs stateless prompting, review-by-exception vs review-every-output, standing tool access vs per-task grants, and who owns the outcome when nobody watched the work. One honesty note up front: no adoption, productivity, or ROI statistics exist for this category at the time of writing, and we will not import figures from adjacent automation literature to fake some. This is a structural read, grounded in what the vendors actually document and what delegation research actually shows.

Start with what the vendors themselves committed to writing. xAI — operating as SpaceXAI since SpaceX acquired the company in February 2026 — framed the Grok Bot launch as “AI teammates you can give real work to,” built first as an internal prototype used company-wide and then opened to subscribers. The launch positioning describes named Bots that sign into the tools you already use, learn multi-step tasks by watching you demonstrate them once, persist that path as a routine that can re-run on a schedule or on demand, and message each other in threads and group chats — in the vendor's words, “so you are not the router between tools.” All of that is vendor-stated capability, not independently verified performance. Our companion piece, the Grok Bot launch breakdown, covers the product itself in detail.

Anthropic's June framing is the structural mirror. Its piece on building effective human-agent teams names three prerequisites for an agent that works inside a team rather than as a tool call: persistent memory “so they can remember goals and tune their execution towards them,” independent credentials “so they can operate within safe, predictable guardrails,” and broad information access “so they can learn how the organization works.” Two vendors with very different architectures converged on the same definition of the category — which is precisely what makes the teammate-vs-agent distinction worth taking seriously as an operating-model question rather than dismissing as marketing.

One open question is worth flagging before the deltas: neither the launch announcement nor the documentation pages we reviewed state which model powers Grok Bot. For something marketed as a coworker with standing access to your systems, “what is actually doing the thinking” is a fair pre-adoption question — and at the time of writing, the vendor does not answer it.

The stateless agent's defining constraint is that every run starts from zero. Whatever context it needs — the client's preferences, the format your team uses, the decision made last Tuesday — must be re-supplied in the prompt or re-fetched from a store you built. The teammate model inverts that. Grok Bot's documentation is explicit about the inversion:

Compounding context is the entire economic pitch of the teammate model. A worker that remembers how you like the weekly report formatted does not need re-briefing; a worker that keeps browser sessions alive does not need re-authentication for every errand; a worker that learned a multi-system workflow by demonstration can re-run it unattended. This is also what makes computer use — the ability to drive apps and sites that have no clean API — practical as a standing capability rather than a per-task stunt. We covered that capability class in our enterprise computer-use playbook.

The flip side gets less airtime in launch posts: persistence preserves everything, not just the useful parts. A misremembered preference compounds exactly as efficiently as a correct one. A stale login, an outdated routine, a file downloaded for one task eight weeks ago — in a stateless model those evaporate at the end of the run; in a persistent model they accumulate until someone audits the workspace. Teams that adopt teammates inherit a new chore that agents never demanded: workspace hygiene for a worker that never forgets on its own.

Anthropic's version of the same foundation adds a dependency most adopters underestimate. Its human-agent teams piece notes that “agents build their understanding entirely from the text a team makes searchable: Slack, code, docs, and meeting notes.” Persistent memory gives a teammate somewhere to put what it learns — but what it can learn in the first place is bounded by your written record. We return to that precondition in section 06.

A per-task agent borrows access; a teammate holds it. That single change is where the two vendors' architectures diverge most sharply — and the divergence is documented on both sides, so you can compare it without speculation.

Grok Bot's answer is one shared, persistent cloud computer per account. The docs state it plainly: “The computer is isolated to your account, not to an individual Bot.” Each Bot gets its own screen so several can work in parallel, but the documentation is explicit that separate screens are not separate security boundaries. Secrets stay human-mediated at the point of use — the security docs instruct that “For passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the Bot should hand you control of the computer.” A masked secret-request mechanism exists for supported connections — the value is “masked, excluded from the transcript, and not shown to the model” — but the docs are careful to say it is “not a general-purpose password manager.”

Anthropic's answer is scoped identity. In its agent-identity model, Claude operates under channel-scoped service accounts rather than personal credentials: “Claude's identity in a legal channel can't reach code that wasn't granted there, and its identity in an engineering channel can't read legal documents that weren't granted there.” Revocation is centralized — “revoking the identity ends Claude's access everywhere that identity was used” — and network egress is allow-listed, with outbound traffic to non-approved hosts blocked outright. Same underlying problem, two architectural answers: one shared workspace with human-gated secrets, or many scoped identities with central revocation.

The comparison below puts the two documented models side by side against the stateless baseline. It is qualitative by design — no adoption statistics exist for either product at the time of writing.

Neither column is a solved problem, and notably, neither vendor claims it is. xAI's own security guidance warns against broad approval rules and states that its model-based Auto Review “should complement, not replace, least privilege and explicit approval boundaries.” When the vendor selling you a teammate tells you to actively constrain its standing access, believe them. For the identity half of this delta, our non-human identity and credentials playbook goes deeper, and the companion agent tool-access review checklist turns this section into an auditable worksheet.

With a per-task agent, review is structural: the output lands in front of you, and nothing counts until you accept it. A teammate that runs standing routines inverts the default — work proceeds unwatched, and you review what gets escalated. Grok Bot's mechanism for this is a per-action approvals ladder: “Allow once lets the Bot continue with that action and Deny blocks it. Always allow can save a matching rule,” with a model-based Auto Review tier above it. For actions on your local machine, as opposed to the cloud computer, the posture is more conservative — per the docs, “The default is Ask every time.”

The efficiency story writes itself: stop reading every output, handle only exceptions, scale one human across many workers. The problem is that the threshold where you stop reviewing is set by your belief about the worker's reliability — and the research on human delegation to AI says those beliefs are predictably mis-calibrated. To be clear about scope: the studies below examine human-AI delegation generally, in controlled settings, and predate the teammate product category — none of them tested Grok Bot, Claude, or any shipping agent product.

Read those three findings against the teammate pitch. Belief carryover means the confidence your team built watching a Bot handle low-stakes inbox triage will silently inflate its prior for the expense workflow it has never run. Conservative updating means evidence of failure corrects that belief slower than it should. And the same study found delegation is driven more by belief about the AI's accuracy than by the person's own confidence in doing the task — so the reviewing human's skill is not the safety net it feels like.

A second line of work sharpens the distinction that matters here. Raees and Papangelis separate trust — a general attitude — from appropriate reliance, meaning dependence actually calibrated to real system performance, and flag two failure modes on the wrong side of that line: over-dependence regardless of actual reliability, and reduced vigilance despite known limitations. Review by exception, in their framing, is a form of reliance calibration — it only pays off if the calibration is accurate, which is exactly what the delegation evidence says humans are bad at.

The operational consequence, and our own reading: do not treat the exception rate as a given. Instrument it. Log what the teammate escalated and what it did not, spot-check the non-escalated work on a schedule, and treat every “Always allow” rule as part of the audit surface — reviewing the standing rules is what replaces reviewing every output. The vendors give you the approval ladder; calibrating it is the part nobody can ship.

Our framing lens here is the distinction between assistance and automation: assistance keeps a person actively involved and accountable throughout, while automation executes end-to-end once triggered, with review checkpoints only where they were explicitly designed in. That distinction cuts through the branding cleanly. A persistent worker that runs on a standing cloud computer and surfaces only what needs approval is architecturally the automation case — the “teammate” label describes the interface, not the accountability structure. There is no continuous human-in-the-loop fallback unless you designed one.

Make it concrete. Suppose an ops teammate at example.com holds the vendor-renewals routine: every month it reviews expiring contracts, renegotiates the small ones by email, and escalates anything above a threshold. Eleven months in, a renewal it handled quietly included an auto-escalating price clause nobody read — because nothing about it tripped an exception. Who owns that? Not the Bot; software does not attend the meeting where the finance lead asks what happened. The human who set the threshold owns it, if you decided that in advance — and nobody does, if you did not.

The audit-trail story helps, but notice what it does and does not give you. Anthropic documents that “every routine, memory write, and network call made with agent credentials is recorded,” and because actions run under the agent's own service accounts, they also land in each connected system's logs — double-logged evidence, which is genuinely better than most human work leaves behind. But an audit trail reconstructs what happened; it does not own what happened. Reconstruction is for the postmortem. Ownership is for the decision you make before the routine ever runs.

Multi-agent coordination raises the stakes another notch. Grok Bot's launch describes Bots messaging each other, sharing context, and handing work off — including an internal “chief of staff” pattern where one Bot coordinates specialists per lane. When a teammate delegates to sub-teammates, the exception that should have escalated to a human can die in a Bot-to-Bot thread instead. The rule that survives contact with that future is simple: every teammate has exactly one named human owner, and no teammate's output is another teammate's authority to act beyond the owner's standing rules.

Both vendors' own material, read carefully, amounts to a readiness checklist that most adopters will not have in place on day one. Five items recur.

A searchable written record. Anthropic's caveat is the quiet precondition of the whole category: an agent teammate's understanding of your business is bounded by the text you have made searchable. Teams that run on tribal knowledge and hallway decisions are onboarding a teammate into an empty room. Getting processes, decisions, and customer context into systems of record is unglamorous work — it is also the substrate teammates learn from, and it is where our CRM and automation engagements usually start.

Approval boundaries designed before adoption, not after. xAI's guidance to avoid broad approval rules and to treat Auto Review as a complement to least privilege is the vendor telling you the default trajectory — accumulating “Always allow” rules until nothing escalates — is the failure mode. Write the boundaries first.

Secret hygiene with an offboarding plan. On a shared-computer architecture, the documentation says to treat any login or file placed on the computer as available to all of your Bots — so credential cleanup has to be a scheduled practice, not a hope. Know how you revoke before you grant.

Escalation design. Review by exception only works if “exception” is defined. Thresholds, categories that always escalate, and a named recipient for each — decided while everyone is calm, not discovered during the first incident.

A named owner per teammate. The single cheapest control in this piece. If nobody's name is on the teammate, the outcome has no owner, and section 05 already showed how that ends.

The four deltas resolve into a usable decision rule: match the delegation unit to the work. Persistence, standing access, and exception-based review are costs as well as capabilities — pay them only where the work shape earns them back.

Sequencing matters as much as selection. The delegation research in section 04 implies the first workflow you hand over will anchor your team's trust for every later one — belief carries across tasks whether it should or not. Choose a first workflow whose failures are cheap, visible, and instructive. Our companion piece on what to hand an AI teammate first is a full triage of that choice.

Looking forward, our expectation is that the operating-model questions in this piece — not model quality — become the axis this category competes on. The vendors already telegraph it: one side documents a shared computer with human-gated secrets, the other a scoped-identity model with centralized revocation, and both ship governance controls as first-class features rather than afterthoughts. As the category matures, expect the two architectures to converge under buyer pressure — scoped identity is the shape enterprise security teams already know how to audit — and expect “who can revoke what, and where is it logged” to appear on procurement checklists long before any reliable productivity statistics exist.