« Phase 03 · Warmup · Track Overview

Staff Notes — Judgment, Review Signal & Seniority


Table of Contents


1. Build vs buy

ConcernDefaultWhy
A2A/ACP protocol implementationBuy (SDKs)specifications, moving fast; hand-rolling means owning every revision
SSE transport, resubscriptionBuythe sharp edges are all in reconnection and proxies
Agent card publishing/fetchingBuy, then pinfetching is trivial; pinning the reviewed text in your registry is yours
Delegation admissionBuilddepth, cycles, tenancy, classification, auth — no product knows your control model
The agent directoryBuildit is a registry with your governance on it, exactly like the tool registry
The internal task model + adaptersBuildthis is the architectural decision of the phase
Webhook receiver (auth, retries, idempotency)Build the semantics, buy the plumbingidempotent handling is yours; HTTP is not
Cross-org tracingBuy (OTel) + agreethe technology is solved; the inter-organizational agreement is not

The line again: buy anything with a specification, build anything with a policy. A2A has a specification. "May this agent delegate to that one, carrying this data, at this depth" does not.

2. The decision framework: should this be a delegation?

Five questions, in order. They take three minutes and prevent most multi-agent regret.

  1. Does the counterparty need to make a judgement that cannot be expressed as a rule? If no, it is a function, a tool, or a workflow step. This question alone eliminates most proposals.
  2. Is it owned by a different team, with different data or a different approval regime? If no, you are paying delegation's costs for none of its benefit.
  3. Can it take longer than a request? If no, an MCP tool is simpler and cheaper.
  4. What happens when it fails, and who finds out? If the answer involves three organizations on a bridge call, reconsider the topology before the protocol.
  5. What identity does it need, and does that survive the boundary? If the counterparty cannot receive a user context, everything it does will be attributed to a service account — decide whether that is acceptable before building.

If all five point to delegation, the follow-up is the depth question: how deep can this chain get, and have you set the limit? A design with delegation and no stated maximum depth is not finished.

3. Review red flags

In a design document

  • A diagram with five agents and one owner. That is a workflow.
  • Delegation with no stated maximum depth.
  • No cycle detection, or cycle detection by endpoint rather than by registered identity.
  • Tenancy checked, classification unmentioned.
  • The delegation chain passed as a request field.
  • A callback URL accepted from the caller with no allow-list.
  • "The callee will authenticate itself somehow."
  • A2A objects as the storage model.
  • No answer to "what happens when the callee is down?" — every counterparty is a dependency with an availability, and Phase 00's composition arithmetic now runs across organizations.
  • Classification checked on send but not on the returned artifact.
  • No task-age alert. A lost callback produces a task that is "working" forever and nothing errors.

In code

# Red flag: chain from the message
chain = request["metadata"]["delegation_chain"]      # asserted, not derived

# Red flag: no depth limit
def delegate(target): return client.send(target, task)

# Red flag: cycle check by endpoint
if target.url in visited: refuse()                    # two URLs, one agent

# Red flag: classification only outbound
check(caller.classification <= target.max)            # what did it send BACK?

# Red flag: any callback
push_configs[task_id] = PushConfig(url=request["callbackUrl"])

# Red flag: notify from the handler
def handler(...):
    ...
    notify(url, "completed")                          # the error path forgot to

# Red flag: protocol objects in the store
db.save(task.model_dump())                            # next revision is a backfill

# Red flag: identity substitution at a boundary
user_id = inbound.user_id or "svc-platform"           # an audit finding, written as a default

In an incident review

  • "We didn't notice for six hours" → is there a cost anomaly alert, and a task-age alert?
  • "Both teams thought the other one was handling it" → supervisor topology, or an explicit owner.
  • "The trace stops at the boundary" → correlation header agreement, before you need it.

4. Production war stories

The two-organization loop. Investigation → Credit Risk → (honestly) back to the sanctions agent already in the chain. Neither party misbehaved; neither could see the cycle. Six hours, and the bill was the first symptom. One if target in chain would have prevented it.

The erased hop. A callee built its own chain entry from the request body. A misconfigured intermediary omitted itself; the audit record showed two hops where there had been three. Found during a model-risk validation, not by any monitor. The chain must be derived from verified context, always.

The metadata endpoint. A push callback URL pointing at the cloud metadata service. The server fetched it dutifully. The fix was an allow-list; the finding was a page long.

The service-account attribution. A fabric-hosted agent called the platform with a workload credential. The adapter substituted a platform service account for the missing user "so it would work." Every action that agent took for six weeks is attributed, in the audit record, to the platform itself. Remediation involved reconstructing user context from application logs.

The forever-working tasks. A callback endpoint changed hostname during a migration. Callbacks failed silently; callers' tasks sat in working indefinitely. Nobody noticed for eleven days because nothing errored — the tasks simply never completed. Task age is one of the few genuinely useful alerts here.

The protocol migration that was a data migration. A2A objects stored directly. A state was renamed in the next revision; the fix was a backfill across millions of rows plus a compatibility shim that outlived its author.

Five agents, one squad. A linear four-step workflow implemented as five delegating agents. Latency tripled, cost quadrupled, and every debugging session required correlating five traces. Consolidating to one agent with three tools restored both.

5. The interview signal

Signal 1 — you distinguish delegation from tool calling structurally. Not "A2A is for agents, MCP is for tools," but the five properties: duration, artifacts, interactivity, cancellability, trust boundary. That shows you have hit the timeout.

Signal 2 — you name the undefined half, unprompted. Depth, cycles, tenancy, classification, auth, chain. This is the single highest-value list in the phase, and volunteering it separates someone who has operated a multi-agent platform from someone who has read the spec.

Signal 3 — "derived, never asserted." The chain-forgery insight. It is a small sentence that demonstrates the security habit of asking who controls this field.

Signal 4 — the protocol-agnostic core, with the lossy-mapping caveat. Anyone can say "we'd abstract the protocols." The staff-level version adds: "and where the mapping is lossy — ACP has no rejected — I declare the collapse and pin it with a test, because an undeclared lossy mapping is something an auditor finds."

Signal 5 — you push back on multi-agent. "Delegate across an ownership boundary, not a task boundary." Candidates who are enthusiastic about multi-agent architectures are common; candidates who can say when not to are the ones who have paid for one.

Signal 6 — refuse rather than degrade. At an identity boundary. This is the sentence that lands hardest in a regulated interview.

Anti-signals:

  • Wrapping agents as MCP tools without noticing the duration problem.
  • No depth limit.
  • Enthusiasm for peer-to-peer topologies with no mention of cycles.
  • Treating canceled as "it did not happen."
  • Storing protocol objects.
  • Substituting a service account for a missing user.

The question to ask them: "When an agent delegates to another team's agent and the outcome is wrong, who owns it?" The answer tells you whether the platform has a topology or a diagram.

6. Mentoring notes

Three exercises:

  1. Draw the cycle. Give them two agents that each honestly delegate to the other, and ask them to find where it stops. Then ask what each team's monitoring would show. The realization that neither party is misbehaving and neither can see it is the one that sticks.
  2. Make them implement the ACP adapter after the A2A one. They will discover that the internal model they designed for A2A does not quite fit — and fixing it is exactly the lesson about protocol vocabulary leaking into a core.
  3. Ask "would a function do?" for every agent in a proposed design. Usually three of five collapse. Do this once with a team and they will do it themselves afterwards.

And the framing for the platform team: delegation is an organizational contract, and the platform's job is to make that contract enforceable. Depth limits, cycle checks and chain propagation are not bureaucracy — they are the reason a multi-agent flow across three teams has an owner and an audit trail. Without them you have not built a platform; you have built a way for several teams to generate an untraceable bill.