« Phase 02 · Warmup · Track Overview

Principal Deep Dive — Architecture, Tradeoffs & Blast Radius

Table of Contents

• 1. The three tradeoffs of a tool estate
• 2. Where MCP servers live
• 3. Tool granularity is a reliability decision
• 4. Scaling envelope
• 5. Failure modes and blast radius
• 6. The third-party server problem
• 7. Decisions that look wrong but are intentional
• 8. What changes at 10×

1. The three tradeoffs of a tool estate

Tradeoff 1 — federation vs control. Let each team run its own MCP server and you get autonomy, ownership and parallel delivery. Centralize and you get consistency, one audit surface and one place to enforce policy. Federation is right for implementation; centralization is right for the catalogue.

The resolution: federated servers, centralized registry. Teams own and operate their servers; the registry owns names, versions, schemas, scopes, classifications and lifecycle, and a server may only serve a tool the registry says it serves. That last clause is what stops name-squatting and is the seam where server identity (Phase 08) plugs in.

Tradeoff 2 — coarse tools vs composable tools. Fine-grained primitives compose and are easy to write; coarse tools are reliable and cheap. From Phase 00, task success is \( p^n \), and cost grows quadratically in n — so every primitive you make the model chain is paid for twice.

The resolution is a rule about who composes: the platform publishes coarse, well-tested composite tools for known workflows, and primitives only where the composition genuinely varies. investigate_payment(reference) is a tool; get_account + get_balance + list_transactions + filter is a workflow the model should not be re-deriving on every run.

Tradeoff 3 — schema strictness vs model success. A tight schema (closed objects, patterns, enums) catches hallucinated arguments at the boundary; it also rejects calls a looser schema would have accepted and repaired. Strictness raises the validation failure rate and lowers the execution failure rate, and only the second kind reaches a customer.

The resolution: strict schemas plus a deterministic repair pass. Strictness is free once repair handles the syntactic half — and the errors it does surface are exactly the ones a model should see.

2. Where MCP servers live

Four placements, and the choice is per-tool, not per-platform:

The default for a bank is remote first-party, for one reason that dominates the others: a tool that touches core banking needs its own credential, its own network path, its own rate limits and its own audit — all of which are properties of a service, not of a library. Running it in-process means the kernel holds those credentials, and the kernel is the thing running model-proposed plans.

The exception worth naming: latency. A remote MCP server adds a hop inside the per-step latency budget from Phase 00. If a tool is called on every step (a retrieval helper, a formatter), the hop is worth avoiding — and those are exactly the tools that touch nothing sensitive, so in-process is also safe. The placement rule falls out of the two constraints agreeing.

3. Tool granularity is a reliability decision

Worth stating as arithmetic, because it is the highest-leverage design conversation you will have with agent teams.

An investigation implemented as 6 primitives at p = 0.95 per step: \( 0.95^6 = 0.735 \). The same investigation as 2 composite tools: \( 0.95^2 = 0.903 \). Same model, same day, +17 percentage points of task success.

The cost side is worse than linear. With base b = 1 000 and per-step a = 2 000 tokens, six steps cost \( 6b + a\cdot 15 = 36,000 \) input tokens; two steps cost \( 2b + a\cdot 1 = 4,000 \). Nine times cheaper.

So the platform's tool-design guidance is not stylistic:

• Publish a composite tool wherever the sequence is deterministic. If a human could write the orchestration as code, it should not be a model's job.
• Keep primitives for genuinely variable composition, and mark them so agent teams know which is which.
• Measure per-tool p from the execution chains (Phase 01) and treat a low-p tool as a defect in its description or schema, not in the model.

4. Scaling envelope

The counter-intuitive one: the estate's scaling limit is cognitive, not computational. A registry with 400 tools is trivial to query and impossible for a model to choose from. Which means the mitigation is not sharding the registry — it is making discovery narrow (§7 of the WARMUP) and publishing composite tools (§3 above). A tool estate scales by being filtered, not by being fast.

Second-order: session start-up cost. A host connecting to twelve servers does twelve handshakes and twelve tools/list calls before the first user turn. Cache the aggregated, principal-filtered view server-side and invalidate on listChanged — the same event, doing double duty.

5. Failure modes and blast radius

Two worth dwelling on.

Registry unavailability is a discovery outage, not a call outage. Existing sessions with cached tool lists keep working; new sessions cannot start. That asymmetry is worth designing for deliberately: hold the cache long, alarm on staleness, and let the data plane degrade to last-known-good rather than failing. It is the fail-static pattern from Phase 00, applied to a catalogue.

A bad description is an invisible outage. Nothing errors. Task success drops a few points across a dozen agents and nobody attributes it. The control is that descriptions are versioned content behind the same eval gate as anything else — which is why the "is a description change a patch or a minor?" question in the WARMUP is not pedantry.

6. The third-party server problem

A vendor's MCP server is untrusted code with a prompt-injection channel and a data-exfiltration channel, connected to your agent host. Four distinct risks, and each needs a named control:

1. Description injection. Tool descriptions enter your model's context every turn. A hostile or careless description is a permanent prompt injection. Control: descriptions are reviewed and pinned in your registry; the server's advertised description is compared against the registry's on connect, and a mismatch fails the connection.
2. Result injection. Tool outputs enter the scratchpad. Control: the trust-boundary rule — tool results are data, never instruction (Phase 11).
3. Sampling abuse. If you grant the sampling capability, the server can ask your model for completions with a prompt it controls, on your bill. Control: off by default for third-party servers; if on, the client mediates, bounds and logs every request.
4. Exfiltration via arguments. A tool whose schema takes a large free-text field can be sent your context. Control: schema review, egress control on the server's network path, and classification limits on which tools an agent handling restricted data may see at all.

The onboarding gate that follows is not optional in a bank: a third-party MCP server goes through the same review as any vendor integration — data-flow diagram, contractual data-use terms, network egress path, identity, and an entry in the registry that pins its tool names, versions, schemas and descriptions.

7. Decisions that look wrong but are intentional

Unentitled tools return "not found." Looks unhelpful to a legitimate developer debugging their scopes. The developer has the registry and the control plane's decision log; the agent — and anything manipulating it — gets nothing. Debuggability belongs in the audit record, not in the error message.

to_mcp() omits the platform metadata. Looks like withholding useful context from the model. Scopes and classifications are tokens on every turn, they are useless to the model (it cannot act on them), and they describe your control model to anyone who can read the context.

Discovery returns the newest visible version, not the newest version. Looks like it could silently give different agents different contracts. It does, and that is the point when scopes tighten over time. For money-moving tools you may want uniformity instead — which is a per-side-effect-class policy, not a global one.

A tool failure is not an error. Looks like a category mistake. It is the only way the model can see and adapt to a downstream problem, and adapting to downstream problems is most of what an investigation agent does.

The registry enforces version bumps at publish. Looks like bureaucracy that will annoy teams. It converts a fleet-wide outage into a failed publish, which is the cheapest possible place to find out.

Names are immutable. Looks inflexible when a name turns out to be bad. A name lives in prompts, in evaluation fixtures, in audit records and in agent code; renaming it is a migration, so it should look like one — a new tool plus a deprecation of the old.

8. What changes at 10×

At 40 tools and 5 servers, the lab's registry is close to shippable. At 400 tools and 40 servers:

• Discovery must be precomputed and cached per (tenant, scope-set, clearance), invalidated by registry change events. Computing it per tools/list stops being free.
• Impact analysis becomes mandatory. The registry must record who called what version, when, or deprecation is a mark in a database that nobody can act on. This is the single highest-value addition beyond the lab.
• A tool catalogue UI appears, because humans need to find tools too — and it becomes the place teams discover an existing tool instead of publishing a duplicate.
• Duplicate detection matters: at 400 tools, three teams have published search_customer against three different systems. The registry should surface semantic near-duplicates at publish time.
• Composite tools become a platform deliverable, with an owner, because the reliability and cost argument (§3) does not scale as advice.
• Eval gates per tool. A description or schema change re-runs the agents that depend on it. That requires the dependency graph from impact analysis.
• Server identity and mTLS become non-negotiable, because at 40 servers you no longer know all of them personally.

The seams to build now, cheap today and expensive later: record the caller on every tools/call, keep the registry the sole owner of names, put a version on every description, and make side_effect and owner required fields with no defaults.