Sub-Agents and Skills

A single-agent loop gets you a long way, and most FDE work starts there. It stops getting you further at two specific moments: when the gather phase is going to read so much that the main conversation drowns in it, and when the surface area of what the agent should know on-demand grows past what a reasonable prompt can hold.

Sub-agents are the first answer. Skills are the second. The claude-code treatment of both has the fuller version of this mechanic; this lesson is about using them in an FDE deployment, where the context pressure comes from the customer's data shape rather than from the developer's own repo.

Sub-agents as context isolation

A sub-agent is an agent the main agent can spawn to do a bounded piece of work. It gets its own context, runs its own loop, and reports back with a small result. The coordinator does not see the sub-agent's gather phase — the files it read, the queries it ran, the intermediate failures — only the answer. That is the whole point.

In FDE work the gather phase is often large. A customer's warehouse has dozens of relevant views; a support history has thousands of past tickets; a policy document is sixty pages. Reading any of that in the main conversation leaves no room for the actual work. Reading it in a sub-agent leaves the main conversation exactly as it was.

Skills as on-demand loading

A skill is a bundle of instructions — prose, commands, examples — that describes how to do a particular task well, written once and loaded by the agent when the moment arrives. The advertising is cheap. The body is not loaded until the agent decides it is relevant.

That design has a specific shape to it. A skill has a short name and a short description that live in context all session — enough for the agent to know whether this skill matches the current question. If it matches, the full skill body loads, and the agent follows it. If it never matches, the only cost was the advertisement.

A customer-specific data-access skill

Here is the shape of a skill the typical FDE engagement would ship on week two. The customer's data lives in a warehouse. Half the questions the agent gets asked turn into a query over that warehouse. The agent needs to know which views exist, what each one is for, which joins the DBA has blessed, and what the customer's compliance team requires be excluded.

A single system prompt could hold all of that. It would then be paid for on every turn, including the ones that have nothing to do with data — and most of them do not. A skill is the right shape:

---
name: customer-warehouse
description: Query Acme's Snowflake warehouse through blessed views and
  return rows a grounded answer can cite. Use whenever the question requires
  numbers from Acme's own data (orders, invoices, usage, support volume).
---
 
## The views you can read
 
- `v_customer_orders` — one row per order. Joined to `v_customers`, masked
  for finance-only fields. Read-only.
- `v_customer_invoices` — one row per invoice. Does NOT include the PDF
  body (compliance).
- `v_support_volume` — tickets per customer per week, binned.
 
## The joins that are allowed
 
Only through `customer_id`. Do not join through email: emails are masked in
`v_customers` for GDPR, so a join will silently drop rows.
 
## What this skill will never do
 
- Query base tables. Only the views above.
- Return more than 1,000 rows in a single call; summarise instead.
- Touch any view named `_pii_`. These are explicitly masked and surface in
  the audit log.
 
## How to answer
 
Call the `list_recent_orders` or `recent_invoices` tool on the MCP server.
Ground numeric claims in the rows it returns, and cite the view name in the
answer.

The agent does not load this skill on every question. It loads it the moment it decides the user is asking about Acme's own data — which is both how you want it to behave and how you can afford to let it behave.

Skill, sub-agent, or hook?

Three similar-sounding instruments, three different jobs. Worth being precise about:

The Claude Code track has deeper lessons on each; the practical rule as an FDE is that if the question is when you know something, reach for a skill; if the question is where the work happens, reach for a sub-agent; if the question is what must be true, reach for a hook.

The coordinator-plus-specialists shape

The thing a production FDE deployment grows toward is a small coordinator agent plus a handful of specialist sub-agents, each responsible for a distinct part of the domain. One specialist does retrieval; one does compliance checks; one does the write-side of the ledger; one does the customer-facing summary. The coordinator decides which specialist to call for which turn, and the specialists do their work in their own contexts.

That shape is not something to build on day one. It is where the single-agent deployment arrives after about a month of real traffic, once you can see which categories of question are big enough to need their own seat. Start with one agent, measure where the gather phase bloats the context, split that off into the first sub-agent, repeat.

What to take away

Sub-agents give you context isolation; skills give you pay-on-use knowledge; hooks give you deterministic rules. The customer's data shape is what drives where you reach for each one, and the coordinator-plus- specialists pattern is the shape a single-agent deployment grows into rather than something to design up front. The next lesson is about running more than one agent at a time on purpose — and the specific cost and failure modes that choice brings.