Skip to main content

Agent-to-Human Delegation: Why Your AI Shouldn't DM Coworkers

Agent-to-human delegation is the pattern nobody designed for: your AI messaging a coworker. Why it lands badly, and the handoff rules that fix it.

10 min read
Agent-to-human delegation — an AI agent handing a task to a human coworker in a chat tool

Agent-to-human delegation — an AI agent assigning work to a person who isn’t its operator — is the one interaction pattern in agent engineering that nobody wrote a spec for. It is also shipping by default in every tool you use. OpenAI president Greg Brockman posted a throwaway observation on August 1 that is, quietly, the most useful piece of design guidance on it released this year. At OpenAI, engineers wire ChatGPT into Slack. And then this happens:

“at openai, many people hook their chatgpt up to slack. people really don’t like when a coworker’s chatgpt contacts them asking for help with a task, even when they’d be perfectly happy doing that same work if asked by that coworker.”

That’s the whole finding, and it should stop you cold. The task is identical. The recipient is willing. The requester is a colleague they like. And it still lands badly.

TL;DR

  • Agent-to-human delegation is an agent assigning work to a human who isn’t its operator. It is not human-in-the-loop; it’s the inverse, and it needs its own design rules.
  • The same request lands differently from an agent because it strips out cost, effort signal, and reciprocity — the three things that make an ask socially payable.
  • The safe default: an agent may spend its principal’s time freely and other people’s time never. Third-party attention routes back through the human first.
  • Ship an escalation budget: cheapest source first, attach your own work, name the human principal, one ask per thread.
  • This is not a chat-tool problem. Coding agents that spray pull requests and reviewer pings are doing the same thing at higher volume.

What is agent-to-human delegation?

Agent-to-human delegation is the pattern where an autonomous agent, acting on behalf of one person, originates work for a different person. Not “asks its user for approval.” Not “escalates to a human reviewer who owns the agent.” It reaches sideways, into someone else’s inbox, and puts a task there.

We already have vocabulary for the other directions, and it’s worth being precise, because the industry keeps collapsing them:

PatternWho holds initiativeWho holds authorityWhat it costs
Human-in-the-loopAgentThe supervising humanThe operator’s own attention
Agent-to-agent (A2A)AgentNeither — protocol arbitratesCompute and tokens
Agent-to-human delegationAgentNobody, by defaultA third party’s attention
Human-to-humanHumanBoth, mutuallySocial capital, reciprocally

That third row is the problem. It’s the only pattern where the entity spending a scarce resource — another person’s focused attention — has no stake in it, no budget for it, and no relationship that the spending draws down.

💡 Key insight: Every other agent pattern spends resources the operator owns. Agent-to-human delegation spends a resource that belongs to someone who never agreed to the transaction.

Why the same request lands differently

The instinct is to call this irrational. Same task, same requester, same day — why does the wrapper matter? It matters because a request between colleagues is never just the task. It carries three signals, and an agent strips all of them.

It strips the cost of asking. When a coworker DMs you for help, they spent something: the small awkwardness of admitting they’re stuck, the interruption of composing the message, the deliberate choice to prioritize this over doing it themselves. That cost is the filter. It’s why you get five good asks a week instead of fifty mediocre ones. An agent’s marginal cost to ask is effectively zero, so the filter disappears — and a filter that costs nothing to pass stops carrying information.

It strips the effort signal. “I’ve been at this for an hour and I’m stuck on the auth callback” tells you the problem is real. An agent’s version has no such history, or worse, has a fabricated politeness layer over one failed tool call. You can’t tell a hard problem from a lazy one.

It strips reciprocity. Helping a colleague builds a ledger. They’ll help you back. Helping their agent builds nothing — you can’t call in a favor from a background process. Brockman’s framing lands the point precisely: people “want AI to give time back — or enhance time together — rather than become a layer separating people.” The resentment isn’t about the work. It’s about being made a dependency in someone else’s automation.

This is not a transitional discomfort that fades as people get used to agents. It’s a structural property of removing price from a market for attention.

The stakes are rising, fast

This isn’t a curiosity confined to one company’s Slack. OpenAI announced ChatGPT Work on July 9, 2026 — a GPT-5.6-based agent that “can operate across apps and files, work for hours on complex projects, and deliver finished outputs.” Slack sits in its plugin directory alongside Teams, Gmail, Outlook, and Salesforce. Slack itself has been rebuilding around agents as first-class participants in channels.

So the surface area is: agents that run autonomously for hours, with write access to the exact tools your colleagues live in. The pattern Brockman is describing at OpenAI — where the culture is maximally AI-friendly and people still bristle — is the leading indicator for every company that turns these integrations on next quarter.

If you’re building anything in this space, the question isn’t whether your agent can message a human. It’s whether it should, and under what budget. Same discipline you’d apply to any other scarce resource — the kind of constraint that belongs in your agent instruction files rather than in a post-incident retro.

How to design agent-to-human handoffs

Here’s the rule I’d write into any agent spec, and it’s deliberately blunt:

An agent may spend its principal’s time freely and other people’s time never. Anything that costs a third party attention routes back through the principal for a human send.

That’s the default. Everything below is how you carve narrow, legitimate exceptions.

1. Give the agent an escalation budget. Not a permission flag — a countable budget. maxHumanAsks: 1 per task, spent only after cheaper sources are exhausted. Budgets force prioritization in a way booleans never do; an agent with unlimited permission to ask will ask about everything.

YAML
escalation:
  order: [docs, codebase, prior_threads, principal, third_party]
  maxHumanAsks: 1          # third-party asks per task, hard cap
  requireAttachedWork: true # must show what it already tried
  labelAs: "agent"          # never impersonate the principal

2. Make it exhaust the cheap lanes first. Docs, the codebase, prior threads on the same topic, then its own operator. A third-party human is the last resort, not the first search. Most “the agent asked a coworker” incidents are really “the agent didn’t read the repo” incidents — the same failure mode that makes an unscoped agent burn tokens rediscovering your architecture every session. Good project context solves a startling share of this; that’s most of the argument for writing a real CLAUDE.md.

3. Require attached work. The agent must show what it tried and where it got stuck before it’s allowed to ask. This restores the effort signal artificially, and it has a useful side effect: an agent that can’t produce a coherent account of its attempt usually shouldn’t be asking yet.

4. Label it, and name the human. “Umesh’s agent is asking, on Umesh’s behalf, about X” is a fundamentally different message from an unattributed bot ping. It keeps the ledger intact — the recipient knows whose favor bank they’re crediting. Never let an agent send under a human’s identity without disclosure. That’s not just rude, it’s an impersonation surface, and impersonation surfaces get exploited by attackers the moment they’re normalized.

5. Prefer notify over request. “Deploy finished, here’s the diff” costs the recipient a glance. “Can you review this and get back to me?” costs them a context switch and an obligation. Agents should default hard toward the first shape.

6. Make consent explicit and revocable. Recipients should be able to say “no agent messages” once, globally, and have it hold. If your integration doesn’t ship that switch, you’ve built an opt-out that doesn’t exist.

Common mistakes

Treating this as human-in-the-loop. They are opposites. HITL is a safety mechanism where a human holds authority over an agent’s output. Agent-to-human delegation is a social act where the agent holds initiative over a human’s time. Wiring one and claiming you’ve handled the other is the single most common error I see in agent architecture docs.

Assuming an @mention is free. It isn’t, and it’s especially not free in a channel, where the cost is multiplied by everyone who reads it. Channel posts should be the most restricted lane your agent has, not the least.

Letting volume creep. One agent asking a colleague one question a week is fine. Forty engineers’ agents, each asking a few times a day, is a denial-of-service attack on your senior people. Budget per-agent and watch the aggregate — the failure is emergent, not individual.

Applying it only to chat. A coding agent that opens speculative pull requests, auto-requests reviews, or tags maintainers on every ambiguity is doing exactly this, at machine volume, in a system with far worse social affordances than Slack. Every rule above transfers. The stronger fix is upstream: agents that work from a real spec ask fewer questions in the first place, which is a large part of why spec-driven development is worth the setup cost.

Exposing a delegation tool with no guardrails. If you’re building an MCP server that wraps a messaging API, you’ve just handed every connected agent a channel into other people’s attention. Rate-limit it, require attribution, and scope it to opted-in recipients — at the server, where the agent can’t route around it.

FAQ

What is agent-to-human delegation?

Agent-to-human delegation is when an autonomous AI agent, acting on one person’s behalf, assigns work to a different human being. It is the inverse of the usual human-in-the-loop pattern: instead of a person supervising the agent, the agent is now dispatching a person. The distinction matters because the social contract around the request changes even when the task itself is identical.

Why do people dislike getting messages from a coworker’s AI agent?

Because the request arrives without the things that normally make a request reasonable — evidence the asker tried first, a sense of what it cost them to ask, and an implicit promise of reciprocity. Brockman observed exactly this at OpenAI: people who would happily help a colleague resent the same task when the colleague’s ChatGPT asks. The work didn’t change; the relationship around it did.

Should AI agents ever contact other people?

Yes, but only in narrow, pre-authorized lanes: notifying rather than requesting, contacting people who opted in, or reaching a human the requester has an existing standing agreement with. The safe default is that an agent may spend its principal’s time freely and other people’s time never — anything that costs a third party attention should route back through the principal first.

How do I design an agent handoff that doesn’t annoy people?

Give the agent an escalation budget, make it exhaust cheaper options first, force it to attach its own work before asking, and always label the message as agent-originated with the human principal named. If the agent can’t produce a specific question with context attached, it should return to its own operator instead of broadcasting a vague ask into a channel.

Is agent-to-human delegation the same as human-in-the-loop?

No, and conflating them is the root of most bad agent UX. Human-in-the-loop means a human reviews or approves the agent’s output — the human holds authority. Agent-to-human delegation means the agent is originating work for a human to do — the agent holds initiative. The first is a safety mechanism; the second is a social act that needs its own rules.

Does this apply to coding agents too?

Directly. A coding agent that opens noisy pull requests, auto-requests reviews, or tags maintainers on every ambiguity is doing agent-to-human delegation at scale. The fix is the same: raise the bar for what earns a human’s attention, attach the agent’s own attempted work to every ask, and make the requesting human’s name the one on the request.

The take

The interesting thing about Brockman’s observation is that it’s not a complaint about AI quality. The agents work. The tasks are legitimate. People are refusing anyway, and they’re right to.

We spent two years optimizing agents to act autonomously and almost no time deciding whose resources they’re allowed to spend. Attention is the scarcest resource in any engineering org, and we just handed every employee a tireless process with unmetered access to everyone else’s. Rate-limit it like you’d rate-limit anything else pointed at a shared resource.

Build agents that give time back. The ones that take other people’s time to save their operator’s will get muted, and deservedly so.

If this was useful, read what a large study of AI coding agents found about instruction files next — it’s the same lesson about agent attention, pointed at a different scarce resource.

Sources

Share this article:
X LinkedIn

Keep reading

Get new posts on AI, Claude Code & LLMs

New deep-dives on AI engineering, Claude Code, and developer tooling — follow along however you prefer.