The extensibility landscape

Read these first

• When MCP is the wrong answer
• Choosing an architecture

What you will know

• Build a decision matrix for prompt, tool, MCP server, skill and sub-agent choices, including capability boundary, owner, latency, cost and failure containment

  The matrix should expose who operates the capability and what happens when it is unavailable, stale, expensive or given unsafe inputs.

• Choose correctly between them for three different requirements

  Use requirements that separate standing context, deterministic external actions, reusable integrations and delegated multi-step work rather than three cosmetic variations.

• Instrument two competing implementations and compare their token use, latency, reliability and operational burden

  A server may add availability and security work, while a sub-agent can multiply context and model calls even when both appear functionally adequate.

• Write and defend a recommendation that rejects the heavier option under an explicit cost, latency or risk budget

  The justification should identify the threshold at which the simpler mechanism stops being sufficient and the migration path if that threshold is crossed.

• Recognise a team reaching for a server when a prompt would do

  The warning sign is adding deployment, authentication and versioning surfaces to solve a behavior or context problem that needs no external runtime.

Chapters

1. 1

   Prompt, skill, tool, server, sub-agent: what each hands the model

   A capability request is always one of three gaps: knowledge the model should be carrying, an action it must invoke, or a sub-task to hand off. Learn to classify before choosing, and learn where the non-determinism sits — a tool's body runs the same way every time, but whether the model calls it does not, so wrapping a format rule in code moves the variance rather than removing it.

   Read chapter
2. 2

   A prompt is resident every turn; a skill loads when it matches

   The two cheapest mechanisms are not one row of the matrix. A prompt sits in context on every turn of every session and is paid for whether or not the task needs it, so it is the right home only for what every session must obey. A skill's body loads on demand when its description matches the request, trading that resident cost for a routing risk: it can fail to fire, or fire on a neighbouring task. That is the axis that decides the release-notes case once you have ruled out a runtime, and it is also why neither one errors when it goes stale — both are read as true and followed.

   Read chapter
3. 3

   A tool fails inside your deploy; a server is someone else's uptime

   The sharpest column in any comparison is not capability but operation: who holds the credentials, who cuts the release, who gets paged. A tool ships and fails inside your process; a server is an independently versioned dependency that must stay reachable. This is why three teams needing the same Jira integration is a real reason to build one, and one team needing it is not.

   Read chapter
4. 4

   A sub-agent saves the transcript, not the work

   Delegating a five-step log triage into a fresh context can raise total billed tokens by 40% while the parent transcript shrinks. The brief, the tool schemas and any state get re-serialized from scratch, and the child runs its own multi-turn loop. Learn which numbers to collect on both sides, and why parent context length is the one metric guaranteed to improve whatever you delegate. Price the cheaper repairs first: a log tool that returns an aggregate rather than raw lines, a cap or a page limit on what any call may return, a narrower query, or compacting the parent transcript where the digression starts.

   Read chapter
5. 5

   A down server errors; a stale skill is confidently wrong

   Calling both of these 'capability unavailable' hides the distinction that matters. A failed server call is loud, attributable and bounded: it errors, the trace shows it, the agent can degrade. A skill carrying deploy conventions that went stale after a pipeline migration fails silently, and the agent follows it to produce wrong work indistinguishable from right work. That asymmetry belongs in its own matrix column, alongside unsafe input — because what a server or a sub-agent returns lands in the model's context as text it may act on, containment covers what a reply can cause as well as what a call can do.

   Read chapter
6. 6

   Two implementations that both work are not equally cheap

   Five columns — capability boundary, owner, latency, cost, failure containment — turn an argument into a table. Apply it to three requirements picked to separate standing context, deterministic external actions, reusable integrations and delegated multi-step work rather than three cosmetic variations. Then instrument two competing implementations of one requirement, because functional adequacy tells you nothing about token use, operational burden, or behaviour under unsafe input.

   Read chapter
7. 7

   Name the threshold that flips the decision, or it is just opinion

   Rejecting a server under a stated p95 budget of 800 ms is defensible only when the write-up says what would change the answer: a second consuming team, or a credential the agent host must not hold. Note too that the tool's schema is the server's schema, so crossing the threshold is a relocation behind the same interface rather than a rewrite. That is the migration path reviewers ask for.

   Read chapter
8. 8

   Five servers in a quarter is a symptom, not a scale problem

   A team that wraps a Postgres query, its code-review conventions and a `kubectl` shell-out in three separate servers has a classification failure, not a count failure. Consolidating them into one widens the blast radius and makes its permissions the union of everything it fronts. Learn the warning sign — deployment, auth and versioning surfaces added to solve a context problem — and what to fix in a quarter versus leave alone.

   Read chapter