« Phase 03 · Warmup · Track Overview
Principal Deep Dive — Architecture, Tradeoffs & Blast Radius
Table of Contents
- 1. The three tradeoffs of inter-agent architecture
- 2. Should this be an agent at all?
- 3. Topology and accountability
- 4. Scaling envelope
- 5. Failure modes and blast radius
- 6. The boundary problem
- 7. Decisions that look wrong but are intentional
- 8. What changes at 10×
1. The three tradeoffs of inter-agent architecture
Tradeoff 1 — autonomy vs accountability. Letting teams delegate freely is what makes a platform feel like a platform. It also means that when an investigation produces a wrong answer, the chain of responsibility runs through three organizations, and each one saw only its own hop.
The resolution: autonomy in who you delegate to, centralization in how. Teams choose their counterparties from the directory; the platform owns the chain construction, the depth limit, the cycle check and the trace. That way "who is accountable for this outcome" has an answer that does not require three teams in a room.
Tradeoff 2 — richness vs interoperability. The more your task model expresses (priorities, deadlines, compensation hooks, cost budgets), the better your platform works — and the less of it survives a hop into a hyperscaler fabric that has never heard of any of it.
The resolution: a rich internal model, a lossy edge, and an explicit refusal policy. Fields that cannot cross the boundary are either (a) enforced on your side before delegating, or (b) a reason to refuse the delegation. What they must never be is silently dropped — a cost budget that does not survive the hop is not a budget.
Tradeoff 3 — decomposition vs reliability. Every hop is a full agent run. Reliability compounds as \( p^n \), latency adds, cost adds, and the trace fragments across owners.
The resolution is the rule from the WARMUP, stated as a design constraint: delegate across an ownership boundary, not across a task boundary. If the decomposition does not correspond to two teams, two data domains or two approval regimes, it is a function call and should be one.
2. Should this be an agent at all?
Before topology, ask what the counterparty actually is. Four options, in increasing order of cost:
| Shape | When | Cost |
|---|---|---|
| A function in your code | deterministic, same owner | ~0 |
| An MCP tool | deterministic or near-deterministic, another owner, sub-second, no interaction | one integration |
| A workflow step | multi-step, deterministic sequence, needs durability and compensation | a workflow engine |
| A delegated agent | needs judgment, is long-running, may need to ask, and belongs to another owner | a full agent run per hop, plus governance |
Most "multi-agent architectures" presented in design reviews are the third row wearing the fourth row's clothes. The diagnostic question: does the counterparty need to make a judgement that cannot be expressed as a rule? If not, it is a workflow step, and a workflow engine will give you better reliability, cheaper, with a trace you can read.
The corollary is worth saying to teams directly: proposing an agent where a function would do is not ambition, it is a reliability regression you will operate.
3. Topology and accountability
| Topology | Accountability | Failure mode |
|---|---|---|
| Supervisor / worker | clear — the supervisor owns the outcome | supervisor is a bottleneck and a single point of failure; its prompt becomes a monolith |
| Peer-to-peer | diffuse | cycles, unbounded depth, and no one able to answer "why did this happen?" |
| Pipeline | clear per stage | it is a workflow; the agent framing adds cost without adding judgement |
| Blackboard | none | concurrent writes, and an audit trail no human can reconstruct |
For a regulated bank the default is supervisor/worker, for a non-technical reason that is nonetheless decisive: someone must be accountable for the outcome, and a supervisor gives you a named owner and a single place where the whole context exists.
Peer-to-peer is defensible only with the controls this phase builds — bounded depth, cycle detection, a carried chain — and even then it should be reserved for genuinely decentralized structures. "Any agent may call any agent" is a sentence to be nervous about in an architecture review.
The supervisor's own risk deserves a named mitigation: it accumulates context from every worker, so its scratchpad grows fastest, it holds the broadest tool and delegation scope, and it is the single component whose compromise reaches everything. Keep the supervisor's own tool set minimal — it should orchestrate and synthesize, not act.
4. Scaling envelope
| Dimension | First constraint | Second |
|---|---|---|
| Agents in the directory | model selection accuracy over cards | directory query cost |
| Delegation depth | reliability \( p^n \), then latency | your depth limit, which should bind first |
| Concurrent delegated tasks | the callee's capacity, which you do not control | your own task store |
| Task duration | push-notification reliability and callback lifetime | credential lifetime — a 4-hour task outlives a 15-minute token |
| Artifacts | storage and classification handling | evidence retention policy |
| Cross-org hops | trace correlation | the number of organizations that must cooperate on an incident |
Two non-obvious ones.
Credential lifetime versus task duration is the sharpest. A task that parks for four hours
awaiting a human approval will outlive any sensibly-scoped access token. The naive fixes are both
wrong: long-lived tokens defeat the entire Phase 08 model, and re-authenticating silently
re-establishes authority the user may no longer have. The correct shape is that a parked task
holds no live credential at all — it holds a reference, and resumption re-mints a
short-lived credential after re-evaluating policy. Which means input-required and
auth-required are not merely UX states; they are the points at which authority is re-checked.
Cross-org incident response does not scale linearly. Two organizations in a chain means a bridge call with two on-call engineers; four means a coordination problem before any debugging starts. This is a real argument for keeping the depth limit small, and for the supervisor topology where one party has the whole picture.
5. Failure modes and blast radius
| Failure | Blast radius | Detection | Mitigation |
|---|---|---|---|
| Delegation cycle | two or more orgs, unbounded cost | cost anomaly, usually late | cycle check on the carried chain |
| Depth runaway | \( p^n \) collapse and multiplied latency | task success rate by chain depth | depth limit at admission |
| Callee slow | your latency budget, entirely | per-counterparty p95 | timeouts derived from your budget; breaker per counterparty |
| Callee down | agents depending on that skill | per-counterparty error rate | degrade the skill out of discovery; have a documented fallback per skill |
| Push callback fails | tasks that never complete from the caller's view | delivery failure rate; task age | retries with backoff, receiver idempotency, and an age-based sweeper |
| Callback endpoint compromised | task state driven by an attacker | token validation failures | verifiable callback token; allow-listed hosts |
| Hostile agent card | prompt injection on every delegation decision | none at runtime | pin reviewed card text in your registry; compare on connect |
| Identity degraded at a fabric boundary | every downstream authorization | absent user claims in the chain | refuse rather than degrade |
| Artifact with a classification you cannot hold | data spill | classification checks on return, not just on send | check both directions |
That last row is one most designs miss. Admission checks what you may send. A callee can return an artifact carrying data classified above what the caller is cleared for — a screening result containing restricted counterparty detail returned to an internal-cleared agent. Check classification on the return path too, and treat an over-classified artifact as a policy event, not a payload.
The push-callback row deserves the operational note: the caller must have an age-based sweeper for tasks that never reached a terminal state. Without it, a lost callback produces a task that is "working" forever, and nobody notices because nothing errored. Task age is one of the few genuinely useful alerts in a delegation platform.
6. The boundary problem
Every protocol boundary is a place where something is lost. Enumerate them deliberately:
| Crossing | What is at risk | The rule |
|---|---|---|
| Your platform → A2A → another team | delegation chain, classification, cost budget | carry in the token; refuse if the counterparty cannot honour them |
| Your platform → hyperscaler fabric | user identity, tenant, policy version | assert requirements; refuse rather than substitute |
| Fabric → your platform | the chain, and often the user entirely | require a chain; reject a bare workload credential for user-scoped actions |
| A2A ↔ ACP | states with no equivalent | declare the collapse and test it |
The single most important sentence in this section: an adapter that silently substitutes for
missing identity has converted an interoperability gap into an audit finding. If a fabric calls
you with only a workload credential and the action needs a user entitlement, the correct behaviour
is a rejected task with a clear reason — not a service account, and not "the platform" appearing
as the actor in the audit record.
The second most important: decide what you do with an over-privileged inbound call. A fabric whose service principal happens to hold broad scopes must not thereby be able to do more through you than the user it claims to represent. Scope-down at the boundary is not optional.
7. Decisions that look wrong but are intentional
The chain is server-constructed, not caller-asserted. Looks like it prevents legitimate proxying — a gateway that delegates on behalf of another agent cannot state that agent's identity. Correct: that gateway should perform a token exchange so its own verified identity carries the delegation, which is Phase 08. Anything else is an unverifiable claim.
check_delegation runs before the task exists. Looks like it loses the record of a refused
attempt. The audit record still gets it (a denial is an event); the task store does not, so
dashboards, sweepers and task-id enumeration are all unaffected by refused traffic.
Discovery scores by the best skill, not the sum. Looks like it undervalues a versatile agent. It answers the question a caller is actually asking — "who is best at this" — and prevents a generalist with six weak matches outranking a specialist with one exact one.
Push delivery is attached to set_status, not to the handler. Looks like hidden control flow.
It guarantees that the failure paths notify too, which is precisely when a caller waiting on a
webhook needs to hear from you.
Depth counts hops, not agents. Looks off-by-one. The limit is about how far a request may propagate, and the chain length before the new hop is the right measure — tested from both sides because getting it wrong is either a loop or a false refusal.
INTERNAL_TO_ACP_STATUS is deliberately not injective. Looks like a bug in a mapping table.
Some protocols genuinely have fewer states; the discipline is to declare the collapse and pin it
with a test rather than pretend the mapping is total.
8. What changes at 10×
At 5 agents in 2 teams the lab's model is close to shippable. At 50 agents across 12 teams and 2 external organizations:
- The directory needs governance: tag vocabulary, card review, an owner per agent, and a deprecation path. An ungoverned tag namespace becomes unsearchable within a year, and discovery quality is delegation quality.
- Cards must be pinned and verified. At 5 agents you know every card author. At 50, and especially with external counterparties, the description your model reads must be the one you reviewed — so the registry stores it and compares on connect.
- Per-counterparty SLOs and breakers. Each delegation target becomes a dependency with its own availability, its own p95, and its own error budget contribution. The Phase 00 composition arithmetic now runs across organizations.
- Cost attribution per hop. Otherwise a delegating team sees a bill it cannot decompose, and the incentive to delegate carefully disappears.
- Cross-org trace correlation becomes a formal agreement: a shared correlation header, agreed retention, and a joint incident process. Do this before you need it.
- A delegation graph view. At 50 agents, "who delegates to whom" is a graph nobody holds in their head, and it is the artifact that makes cycles, hot spots and single points of failure visible.
- Artifact lifecycle. Retention, classification, and deletion of artifacts produced by other organizations. This is a data-governance workstream, and it is easier to start it early.
The seams to build now: carry the chain in a verifiable credential rather than a parameter, put a
contextId on every emitted artifact and trace, record the counterparty on every delegation, and
keep the internal task model free of any protocol's vocabulary.