Agentic delegation, explained
The Errand.
What sending a kid to the corner shop teaches us about letting AI agents act on our behalf — and why that turns out to be a genuinely hard problem.
Picture it
Sending a kid to the shop.
No smartphones, no apps, no tap-to-pay. You need milk, so you send one of the kids to the corner shop — and the shopkeeper puts it "on the tab" because Mom has an account there.
Swap the kid for software and the shop for an API, and you've got the exact problem AI agents face today: how to safely let something act on your behalf.
Meet the cast
Six people you already understand.
Mom
The one in charge. She decides what's allowed, and the bills come to her. Everyone else acts for her.
AAuth · PersonSam
Mom's kid. He carries no cash — he buys on Mom's tab. No money, no authority of his own.
AAuth · AgentThe ID office
Issued Sam's ID card. He can't print his own — a trusted issuer vouches "this is Sam."
AAuth · Agent ProviderMr. Patel
Runs the shop and Mom's tab. He knows Mom — but he doesn't know Sam well.
AAuth · ResourceDad
The authority Mom designated to speak for the account. The shop turns to him to confirm a purchase — he checks with Mom and confirms consent in the moment.
AAuth · Person ServerThe accounts office
The chain's rulebook. Clears purchases and enforces policy no matter what Mom wants.
AAuth · Access ServerWhat we're trying to learn
How do you safely send someone else to do a job for you?
It sounds easy — we do it all the time. But slow down and look at what actually has to be true for it to work, and not go wrong, and it gets surprisingly deep.
An agent is just Sam — except Sam is software, the shop is some website's API, and Mom is you.old problem · newly urgent
Part one
"Go buy a loaf of bread."
A single, specific thing, on the account. Sounds straightforward — until you have to build the trust from scratch, which is exactly what software forces you to do. So let's handle each piece by hand.
- Sam must convince Mr. Patel he is who he says he is.
- Sam must convince him that Mom actually sent him.
- Mr. Patel must be willing to put it on Mom's tab — trusting both.
Prove it
Saying your name is just a claim.
Anyone can walk in and say "Mom sent me, put it on her account." A name proves nothing. Some other kid could say he's Sam and walk off with goods on Mom's tab — and keep charging until someone catches on.
Not "what's your name." Prove it.identity, step one
- When Sam makes his request he signs it on the spot; Patel checks it against the signature on Sam's ID card.
- The card came from a trusted ID office — not something Sam printed himself.
- The real version is unforgeable: anyone can check a signature, only the real Sam can produce one.
Says who?
Knowing it's Sam isn't enough.
Suppose Patel is totally convinced this is Sam. It still isn't enough, because Sam is a kid. Identity tells you who's standing there — not whether he's allowed to do this.
Is Mom behind this?
What matters is that Mom authorized this, and Sam is carrying her authority. He isn't acting as himself — he's acting on behalf of Mom.
A scrap of paper is weak.
Handwriting can be forged or copied. Worse, Sam could reuse it next week for something Mom never agreed to. A note proves she said something once — not that she means it now.
The shift identity answers "who"; authority answers "allowed to, right now" — and that needs something stronger than paper.
How the shop actually checks
Let the shop drive.
Patel can't tell a real note from a fake one — so he trusts nothing Sam brought with him. Instead Patel writes his own slip — "one loaf, Mom's account, $3" — and hands it to Sam: "bring this back signed by the authority Mom designated."
The shop writes the request
Patel wrote it himself, so it can't be a forgery or a stale reuse — and it names this exact purchase.
Dad signs it
Sam carries the slip to Dad, who checks with Mom and signs "Approved." A real-time okay from the party Patel trusts to speak for the account.
The kid shuttles both ways
Patel never phones Dad; Dad never phones Patel. Sam carries the unsigned request out and the signed approval back.
AAuth · resource token → auth token the shop states the request; the Person Server confirms the person is behind it; the agent carries the paperwork both ways.
The shop has its own rules
Mom's okay does not overrule the shop.
The chain's accounts office has rules — say, "no tobacco on a parent's account for a kid, even if a parent okays it." Now there are two gates: Mom has to approve, and the rulebook has to allow it.
If the accounts office says no, it's no — even with a signed, verified, totally legitimate okay from Mom. The person's permission sits underneath the shop's policy, not above it.AAuth · Access Server
- Patel forwards the charge for clearing; Dad settles it with the accounts office.
- Dad confirms Mom's okay, the office checks the rulebook, the cleared result comes back.
- No separate office? Dad just gives the okay himself — the simpler shape.
The loaf of bread, as a sequence
The agent carries every token.
The shop never rings Dad. It hands Sam a note to get approved, Sam takes that note to Dad, and Sam brings the approval back — the full four-party flow, with the accounts office applying the chain's own policy.
sequenceDiagram
actor Mom as Mom (Person)
participant Sam as Sam (Agent)
participant Patel as Patel (Resource)
participant Dad as Dad (Person Server)
participant HO as Accounts (Access Server)
Sam->>Patel: Signed request for bread (agent token)
Note over Patel: Verify signature vs ID card
Patel-->>Sam: 401 + resource token
Sam->>Dad: Signed request + resource token
Dad->>Mom: Sam wants bread on the account, ok?
Mom-->>Dad: Yes, that's fine
Dad->>HO: Federate: resource token (consent given)
Note over HO: Apply chain policy
HO-->>Dad: auth token
Dad-->>Sam: auth token
Sam->>Patel: Signed request for bread + auth token
Note over Patel: Verify auth token + signature
Patel-->>Sam: 200 OK, bread on the tab
A single, specific request · simpler shops collapse the Person Server and Access Server into one
So far, so good
A specific errand — basically cracked.
Prove who you are
Sign your name — don't just say it. The signature matches the ID card from a trusted issuer.
Prove you're acting for someone
Carry their authority, don't borrow your own. Everything traces back to Mom.
Let the other side check it
Through a trusted party that vouches for the person — plus the resource's own rules on top.
If errands were always this tidy, we'd be done. The trouble is, real jobs are almost never a single, written-down thing.
Part two
"Buy the ingredients for the cake."
No list. Sam has to figure out what "the ingredients" even means — flour, eggs, sugar… out of vanilla… no cake tin, better grab one. Each is a decision he makes as he goes, charged to Mom's account.
The messy middle
Flour, yes. A PlayStation, no. And then…
Easy at the extremes. But the job was handed over in words, not a checklist — so "is this inside the cake?" becomes a judgment call, made by the kid with the account who maybe wouldn't mind some leftover chocolate.
The fancy imported chocolate — "to make it nicer"?judgment call
A second batch — "in case the first cake flops"?judgment call
Sprinkles, candles, a card, a balloon — "the cake" or not?judgment call
A narrow job is easy to check. A broad, fuzzy goal is easy to state — and genuinely hard to fence in.
The note from last weekend
The permission didn't expire. The reason did.
Last weekend Sam bought picnic supplies — all justified. This weekend the picnic is over, but he still has the note: "buy the picnic stuff." The account is still open. Patel would still honor it.
Same kid. Same note. Same shop. Same everything — except the job is already finished.stale authority
- We think of permission as what you can do and who said so.
- There's a third thing hiding underneath: is the goal even still alive?
- A piece of paper has no sense of "done" — it says "buy the picnic stuff" forever.
"Sam, stop!"
Revoking and actually stopping are different acts.
Mom changes her mind — the party's cancelled. She calls the shop to call it off. But Sam is already at the counter, and the cashier is already ringing it onto Mom's account.
"No more."
Mom can revoke all she wants. No new approvals get handed out from this moment on.
Already moving.
If the action is already rung up, "no more" doesn't reach back and undo it. There's always a window between "I changed my mind" and "everything stopped."
For a loaf of bread, who cares. For an agent moving real money or sending real messages, that little window is everything.
Sam sends his little brother
Authority has to flow through Sam — not grow.
There's a lot to carry, so Sam brings his little brother to fetch the milk. The brother is his own person but has no authority of his own — Sam clears the purchase so it goes on Mom's account.
- The helper has its own identity — it can be audited and switched off on its own.
- But it can't get authorization by itself: the parent agent obtains it on the helper's behalf.
- Mom's okay flows through Sam, to his brother — without getting bigger along the way.
- Someone stays responsible, and the shop can see the helper really acts for Sam, who acts for Mom.
AAuth · Sub-agent its own identity for audit; its authority still rides on the person, obtained by the parent.
Patel back-orders from his distributor
The shop becomes an agent itself.
Sam needs a vanilla the shop doesn't stock. Patel offers to back-order it from his supplier, delivered to Sam's house Tuesday. A minute ago Patel was the shop checking Sam — now he's a customer placing an order on behalf of the errand.
"Mr. Patel's shop ordered it" is true but incomplete. The honest answer is a chain: Mom → Sam → the shop → the distributor.
- If anything goes wrong, you want to walk the chain back, hop by hop.
- Each link should be checkable, not just trusted.
- The final delivery carries the full story, all the way back to Mom.
AAuth · Call chaining one party legitimately acting as an agent toward the next, with every hop recorded.
The cart that quietly wandered off
The drift lives in the pattern — not the items.
A cake stand "for the cake." Candles "for the cake." A banner. A card. Party hats. A tablecloth. Look at any single item and you can't object. Each one is defensible. The receipt looks reasonable.
Step back and look at the whole cart: Mom asked for a cake, and Sam is quietly throwing a whole party on her account — one she never approved.
- Checking each item as it's scanned — the thing we're good at — simply doesn't see it.
- No single shop can see it either: each shop only sees its own till.
- The one party that could notice sees all of Sam's purchases together, and remembers the goal.
AAuth · the Person Server spans every shop and keeps a running mission log — positioned to judge whether the pattern still fits.
So what does the cake teach us?
Give the open-ended job some shape.
Instead of a vague "buy what you need," you write down the intent, hand it to the trusted party, and let them check each request against it, keep a log, and call the whole thing off if needed. In AAuth this is a mission.
What a mission gives you
A place to attach governance, audit, and a kill switch. An ending the agent can mark complete and the person can terminate. Short-lived tokens that re-check on renewal.
What it doesn't promise
Not every boundary is sealed. Containment across hops and instant stop-on-revoke are still being worked out. The useful systems name these edges out loud.
The mission layer is important in practice — not a promise that every edge is sealed, but a place to stand while we work on them.
The cake job, as a sequence
Approve the mission once — then judge each scope.
In-scope purchases are approved silently against the mission's stated intent; anything that doesn't fit goes back to Mom.
sequenceDiagram
actor Mom as Mom (Person)
participant Sam as Sam (Agent)
participant Dad as Dad (Person Server)
participant Patel as Patel (Resource)
Note over Sam,Dad: 1. Propose and approve the mission (once)
Sam->>Dad: Propose mission "buy the cake ingredients"
Dad->>Mom: Approve this mission for Sam?
Mom-->>Dad: Approved
Dad-->>Sam: Approved mission + reference
Note over Sam,Patel: 2. In-scope: approved silently
Sam->>Patel: Request flour (agent token + mission ref)
Patel-->>Sam: 401 + resource token (scope: flour)
Sam->>Dad: Request + resource token + mission ref
Note over Dad: "flour" fits the cake mission
Dad-->>Sam: auth token (scope: flour)
Sam->>Patel: Request flour + auth token
Patel-->>Sam: 200 OK
Note over Sam,Patel: 3. Out-of-scope: escalated to Mom
Sam->>Patel: Request a PlayStation (+ mission ref)
Patel-->>Sam: 401 + resource token (scope: PlayStation)
Sam->>Dad: Request + resource token + mission ref
Note over Dad: Does not fit the cake mission
Dad->>Mom: Sam wants a PlayStation. Allow it?
Mom-->>Dad: No
Dad-->>Sam: Denied, outside the mission
An open-ended ask · the mission lets the Person Server decide quickly without asking Mom every time
The same story, real names attached
From kitchen to protocol.
| In the story | In AAuth | What they do |
|---|---|---|
| Mom | Person | The human in charge. Authority starts here; the bills land here. |
| Sam | Agent | The software that goes and does things. No authority of its own. |
| The ID office | Agent Provider | Issues the agent its identity and signing key. |
| Mr. Patel / the shop | Resource | The thing being acted on. Verifies the agent and enforces its rules. |
| Dad | Person Server | Represents the person, confirms consent, holds the mission. |
| The accounts office | Access Server | The resource's policy engine. Final say, even over the person. |
| The little brother | Sub-agent | A helper, still under the person's authority. |
Where to go from here
AAuth is the protocol behind this story — provable agent identity, on-behalf-of authority, real-time consent, and missions. Step through each flow interactively, or read the full spec.