Acting for someone: delegation

Acting for someone: delegation

The concierge agent receives a request from a user, picks an agent from the cards it trusts, and forwards the request. It is the smallest example of what makes agent systems different: three things travel along the chain, the request, the answer and the user's identity.

The exchange is in the style of RFC 8693 (token exchange). The stand-in service checks that the incoming token was issued for the concierge, refuses a wider scope than the original, and never issues a token that outlives the one it received (tests for each). A token is for one audience: an exchanged venue token is rejected by the catering agent.

Loops and depth

Agents that can call agents can call each other. With no protection, the example's experiment made 41 delegations before I stopped it at a cap of 40. A path check (refuse if your own name is already in the path, carried in message metadata) stopped it at 3; a hop limit alone stopped it at 5. The hop limit is a backstop, not a fix: it still permits four wasted calls. The concierge reports REJECTED with the reason in both cases, rather than failing silently.

What the concierge cannot do

It cannot pass AUTH_REQUIRED upward: if the venue agent needs the person's permission, the concierge turns that into FAILED. That is a real gap, and it is an exercise. It also relays an INPUT_REQUIRED question to its own caller and sends the answer to the same remote task, which a test confirms with one remote task and not two.

An agent behind a tool

Many hosts will meet A2A through MCP: somebody wraps a remote agent as one tool. The wrapper decides what the model gets to see. I wrote two and ran five situations through a scripted caller that can read a status field but not intent from prose.

The naive wrapper blocks until the task settles and returns the words with isError false. A question looks like an answer; a permission request looks like an answer; and a job longer than the caller's timeout loses the task id completely. It passes the refusal case only because the agent's sentence says "only plans events up to 2000", not because the wrapper told anyone it was a refusal.

The careful wrapper keeps the state in structuredContent, marks what really failed with isError, says what to do next in words (Call this tool again with task_id=...), tells the model not to guess credentials and to hand a link to the person, and never blocks past its own limit: after 25 virtual seconds it returns working and the task id.

if st == M.INPUT_REQUIRED:
    return _text(f"The agent needs more information: {words} Call this tool again with "
                 f"task_id={t['id']} and request set to your answer.", False,
                 {"status": "needs_input", "taskId": t["id"], "question": words})

A caveat that matters for how you read the table: a real language model might guess correctly more often than my script, for instance by noticing that the naive wrapper's output ends with a question mark. The table says which design gives any reader something to act on, not how often a real model succeeds. Hard exercise 2 asks you to measure it.

The suite: 41 checks, each tied to a rule

The conformance suite (conformance.py) is a list of functions with an id, the rule it comes from, and a title. They run against a server built from make_world(bugs).

Does the suite work? Plant defects

Module 6's lesson applies again: a test is only worth what it would catch. I planted 26 realistic defects, each a switch in the server (a missing version check, a task id accepted from the client, a stream that drops its last event, a webhook sent to a private address, and so on), and wrote down before running which checks I expected to fail.

• On the correct server: 0 failures of 41.
• 24 of 26 defects were caught, and for 24 the checks that failed were exactly the ones I predicted.
• Two predictions were wrong, both by being too narrow: blocking_returns_early also failed T2 (list order is by status-change time, not creation time, so a half-finished task moves in the order), and stream_drops_last_event also failed ST3. Neither was a missed defect; I had under-counted the effects.
• Two defects escaped: working_message_dropped (a message sent to a working task is ignored instead of recorded) and no_push_retry (a failing webhook is not retried). Both are in the code as honest holes. A real check for the first needs to define what the agent should do with the message; for the second it needs a receiver that fails on purpose and a count of attempts. The test file asserts that both escape, so if someone closes the hole the test reminds them to update the counts.

What the example does not do

• No language model anywhere. The agents are scripts. The conclusions about what a model would do are mine, and the tool-wrapper table is the weakest on that point.
• No gRPC. The third binding is named, not built.
• HS256 stands in for public-key signatures. It shows the checks; it does not show key distribution.
• No real discovery. The router ranks cards that are handed to it; the specification leaves registries and curation out of scope, and so do I.
• The concierge cannot pass an authorization request upward (exercise Medium 3).
• Time is virtual, so there is no real clock skew, no real timeouts, and no concurrency.
• My choices where the specification is silent: the transition table, the notification token header, redaction of push secrets on reads, appending messages to working tasks, InvalidParams for another user's context id, and the HTTP status of a JSON-RPC version error.
• The specification is young. I read it on 24 October 2026; check it before you rely on a detail.

A checklist for "ready to expose an agent"

• [ ] The card validates, is public, supports conditional requests, and is signed if clients are expected to rely on it.
• [ ] Every operation checks the caller's identity and audience; another person's task is "not found".
• [ ] Task ids and context ids are server-generated, and a context belongs to one principal.
• [ ] A final task stays final; follow-ups are new tasks.
• [ ] Push URLs are checked against private ranges once, and the checked address is the one used.
• [ ] Secrets are accepted but never echoed.
• [ ] A hop limit and a path check protect against loops.
• [ ] Output from other agents is data, not commands.
• [ ] The suite has planted defects and you know which ones escape.