What to Hand an AI Teammate First: An Ops Triage

Deciding what to delegate first to an AI teammate is now a live operations question, not a thought experiment. xAI launched Grok Bot on August 11, 2026, pitching “AI teammates you can give real work to” — bots that, in the vendor’s words, “finish jobs end to end, and only come back when something needs your approval.” That pitch puts the buyer’s side of the question in play: of everything your team does, which job goes first?

Most teams get this wrong in one of two directions. The timid version delegates something so trivial that nothing is learned — the agent summarizes a document nobody reads, and the pilot quietly dies. The reckless version hands over something consequential and irreversible on day one, and the first failure becomes the last, because trust never recovers. Both failures come from choosing tasks by gut feel instead of by property.

This guide is a decision framework, not product news. It builds the triage on four properties — recurring, bounded, reversible, verifiable — derives the inverse list of work that should not be delegated end to end, and grounds both in checkable sources: one vendor’s own security documentation, a borrowed decision-making lens, and the records-retention and automated-decision rules that apply whether or not an agent is involved.

Whatever you hand an AI teammate first becomes the template for everything you hand it afterwards. The approval rules you set, the logging you require, the verification habit you build — all of it gets copied from delegation one to delegation two. That is why the first choice deserves more care than “whatever annoys the team most.” You are not picking a task; you are setting the default posture for an operating model. We cover how that operating model differs from prompt-at-a-time agent use in our companion piece on AI teammates versus AI agents.

There is also a cost to over-caution, and it is worth naming honestly. The decision literature this post borrows from warns that organizations tend to apply their heaviest, slowest decision process to every choice — including the easily reversible ones — and that the price is slowness, reflexive risk aversion, and less experimentation. Treating every candidate task as if it were irreversible is itself a failure mode. The point of a triage is to spend caution where it buys something, and speed everywhere else.

The detail worth interpreting here is that this vendor’s own documentation argues the same logic. The most useful document xAI published at launch is not the marketing page — it is the approvals and security documentation, which reads like a delegation triage written from the inside: start with read-only tasks and draft outputs, connect only the tools a workflow needs, and keep a specific list of action types behind approval. When the company shipping the agent and the team adopting it arrive at the same checklist, that checklist is probably load-bearing.

Run every candidate task through four questions. A task that passes all four is a strong first delegation. A task that fails one is a later delegation, with the failing property patched by a guardrail. A task that fails two or more — especially reversibility plus verifiability — is not a delegation candidate at all yet.

The four tests are deliberately property-based rather than department-based. “Marketing tasks” or “finance tasks” is the wrong axis: every department contains work that passes all four tests and work that fails all of them. The sorting has to happen at the level of the individual, repeatable job — which is also the level at which an agent actually operates.

Recurrence is the economic test. An AI teammate is taught, corrected, and reviewed — all of which costs senior attention. That investment only pays back across repetitions. The practical signal is boring: look at what your team did last Tuesday and will do again next Tuesday. Status updates from the same sources, intake from the same inbox, the same report assembled from the same systems. Vendors lean into exactly this shape — Grok Bot’s launch materials describe a bot that watches a demonstration, saves the workflow as a routine, takes corrections, and runs it on its own the next time. That is a vendor-stated capability claim, not an independent test result, but it tells you what the product is built to absorb: repetition. How that teach-by-demonstration paradigm compares to explicit workflow builders is its own decision — we unpack it separately.

Boundedness is the containment test. A bounded task has a defined input surface (this inbox, this queue, this form), a defined output shape (this field updated, this ticket filed, this draft produced), and a decidable finish line. Boundedness is also what keeps permissions small: a task with explicit edges can run on narrowly-scoped access, while a vague mandate demands broad access before it can even start. The vendor’s own security docs warn against exactly that drift — “Avoid broad rules such as ‘allow everything in the browser.’ Websites and tool behavior change over time.”

The most useful lens for the reversibility test predates AI agents entirely. In his 2015 shareholder letter, Jeff Bezos distinguished two kinds of decisions: one-way doors — consequential, irreversible or nearly so, deserving slow and deliberate process — and two-way doors, which can be walked back, and which should therefore be made quickly and cheaply. He was writing about corporate decision-making, not AI delegation; borrowing the frame is our application, not his claim. But it transfers cleanly: before handing a task to an agent, ask which kind of door the task walks through when it executes.

Two-way-door work is the natural first delegation. A draft can be discarded. An internal record with edit history can be restored. A reproduction of a bug can simply be rerun. One-way-door work — a message sent to a customer, a payment released, a record deleted, a production configuration changed — executes once, and no approval screen after the fact will un-execute it.

The vendor documentation makes this point with unusual precision, and it is worth quoting because teams routinely assume approval workflows equal safety:

Read that twice: approval gates the next step, not the steps already taken. If an agent runs a twelve-step job and step nine is wrong, the approval prompt at step ten does nothing for steps one through nine. The operational consequence is that reversibility has to be designed into the task itself — draft-first outputs, staging before production, soft-delete over hard-delete — rather than bolted on as a confirmation dialog at the end. And deprovisioning is not a rewind button either: the same docs state plainly that “Deleting a Bot does not remove shared-computer files or browser sessions.” Ending a delegation and reversing its effects are different operations, and only one of them is automatic.

Verifiability is the test teams most often skip, because it is a property of your process, not of the agent. A task is verifiable when someone who did not watch the work can confirm it is correct much faster than they could redo it. A CRM field updated from a call transcript is verifiable — open the transcript, compare. A filed bug reproduction is verifiable — run it. A strategic recommendation is not verifiable in this sense: the only way to check it is to exercise the same judgment the task required in the first place, which means nothing was actually delegated.

The same principle shows up in the vendor’s guidance to its own users, framed as an approval rule: “Do not approve an action whose target or effect you cannot identify. Ask the Bot to explain it in plain language or produce a draft first.” That is a verifiability test wearing an approvals costume — if you cannot tell what an action will do, the task was not ready to be delegated yet. Our experience building agentic systems for clients points the same way: the tasks that survive in production are the ones where verification is structurally cheap — diffs, reruns, drafts against a checklist — not the ones where it depends on a diligent human re-reading everything.

Delegation criteria are also getting formal academic attention — a 2026 arXiv paper, “Intelligent AI Delegation” by Nenad Tomašev, Matija Franklin, and Simon Osindero, proposes a formal treatment of how tasks should be allocated to AI systems. The field is young, and we cite the paper’s existence rather than its specifics; the practical takeaway is that “which tasks, under which controls” is being treated as a discipline now, not a vibe.

xAI’s launch page describes three jobs its bots already run internally — inside the team it calls SpaceXAI: a sales bot updating the CRM with call-transcript notes and drafting follow-ups, an ops bot onboarding new hires and processing invoices received in Gmail, and an engineering bot reproducing a bug, filing the ticket, and handing the fix to another bot. These are vendor-stated descriptions of the vendor’s own usage — not independent case studies, and not evidence your business will get the same result. The same page also names broader internal categories, including sales outbound and marketing campaigns, so these three are not the boundary of what the vendor says its bots do. Their value is different: they are well-chosen illustrations of categories, and every one of them passes the four tests.

The CRM example deserves a special note for operations teams, because it is usually the highest-volume candidate in the building. If your CRM work is heavy enough that an agent is attractive, the delegation question quickly becomes an architecture question — what the agent writes to, and who owns that system. Our framework on agentic CRM buy-vs-build decisions covers that fork, and our CRM automation practice builds exactly this category of pipeline — transcript-to-field, draft-first, human-send.

Invert the four tests and the “do not delegate first” list writes itself: irreversible, unaudited, judgment-dense, regulated. But it gets sharper than adjectives, because three pillars of it are checkable against published sources.

Pillar one: the vendor’s own approval boundary. xAI’s security docs recommend explicit approval gates for seven action types: sending messages or invitations, publishing content, purchases and financial transfers, deleting or overwriting data, changing permissions, production changes, and accepting legal terms. That is the vendor of the agent telling you what not to fully automate. When the seller of the autonomy names the places autonomy should stop, believe them.

Pillar two: retention duties outlive the task. Invoice and document processing is one of the vendor-stated example categories — and it is also where regulatory retention obligations live. Where the IRS’s mandatory machine-sensible-record rules apply — chiefly entities with $10 million or more in assets at year end, controlled foreign and substantially foreign-owned domestic corporations, and taxpayers whose required information exists only in machine-sensible form — those records must be retained as long as they may be material to tax administration, must contain enough detail to support and verify return entries, and must remain retrievable and processable on demand during an examination; an opaque log your own business can no longer query does not satisfy the duty. For public-company audits, the SEC’s Rule 2-06 (implementing Sarbanes-Oxley) requires accounting firms to retain audit-relevant records for seven years — settled law since 2003, scoped to auditors of issuers. A distinct retention regime exists for broker-dealers under SEC Rule 17a-4. None of these rules bans automation. All of them mean the audit trail must survive the automation: automate around the record, never through it.

Pillar three: decisions with legal effects on people. In GDPR-covered jurisdictions, Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects on a person — credit, employment, eligibility-type calls — and requires safeguards including the right to obtain human intervention, to express a point of view, and to contest the decision. The scope trigger matters: this is not “any automated decision,” it is decisions that significantly affect a person’s status. Ordinary back-office automation decides nothing about anyone’s legal position. But if the task in front of you does, an end-to-end delegation is not merely risky — where GDPR applies, it is non-compliant without a human-intervention path.

The reversibility and boundedness tests have to be evaluated against the actual execution environment — and the Grok Bot launch offers an unusually clean, checkable illustration of why. The marketing surface describes bots as having their own computer. The vendor’s own security documentation states the opposite: “All of your Bots share one cloud computer assigned to your user account. Files, browser sessions, and command line credentials on that computer are available across your Bot roster.” And then, in as many words: “Do not use separate Bots as a security boundary.” Both statements are vendor-published. Only one of them should drive your triage.

The operational consequence: if five bots share one computer, one bot’s browser session, downloaded file, or stored credential is every bot’s. The blast radius of your riskiest delegated task becomes the blast radius of all of them. Add the deprovisioning fact from section 04 — deleting a bot does not remove shared-computer files or browser sessions — and “undoing a delegation” turns out to be a checklist, not a button. The vendor’s own off-boarding guidance runs six steps, from pausing routines and signing out of websites to revoking connector authorizations in the source services and clearing workspace files.

Credential handling deserves its own look before any first delegation. The documented model is that for passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the bot hands the human control of the computer; a “secure secret request” exists for supported connections — masked, excluded from the transcript, and not shown to the model — and the docs are explicit that it is not a general-purpose password manager. Local-machine execution is a separate control from the shared cloud computer, and its shipped default is to ask every time. One more structural fact worth checking on any platform: Grok Bot uses Cursor authentication and account data settings, which means the data-governance regime for your delegated work can live in another product’s terms than the brand on the agent. All of this is one vendor’s current design, described in that vendor’s own docs — not an industry standard — but the checklist it implies generalizes: before the first delegation, know where the agent executes, what it shares, who holds its identity, and what its off-boarding actually removes.

This is why we treat tool access as its own review discipline — our agent tool-access authorization checklist is the companion piece to this triage, and the launch itself is covered in our Grok Bot launch analysis. For the broader pattern of agents operating full computer environments, see the computer-use automation playbook.

Here is how the triage plays out for a hypothetical operations team at Example Corp (example.com) — a services business with a busy shared inbox, a CRM nobody loves updating, and a weekly reporting ritual. The triage picks one job: supplier invoices arrive at a single address, in repeating formats, and get keyed into the accounting system. Recurring, bounded, reversible while the agent only proposes entries, verifiable line by line against the PDF. The judgment-dense work — approving unusual invoices, negotiating with the supplier whose totals never match — stays human, with the agent assembling the evidence.

Two weeks in, Example Corp has something more valuable than a working automation: a tested template — property-based selection, shadow-then-draft-then-act, narrow approval rules, a preserved trail — that the second and third delegations inherit. Scaling this from one job to an operating capability is where most teams want a partner; that sequencing question — which systems first, which jobs, which controls — is the core of our AI transformation engagements, and the build-versus-buy fork that usually follows is mapped in our custom-tools versus branded-SaaS framework.

Looking forward, we expect the interesting competition among agent vendors to move exactly here — from capability claims to delegation ergonomics: how cheaply a platform lets you run shadow mode, how narrowly its approval rules scope, how legible its action logs are, and how completely its off-boarding actually revokes. The platforms that win operations teams will be the ones that make the four tests easy to pass safely — because the tasks themselves are the same on every platform.