Build an agent team and prove it works

The job is orchestration, not prompting

Sierra wrote about this role in May 2026 and put it plainly: "Last year, this role barely existed. Today, it's our fastest-growing team." (Sierra) Their San Francisco listing for Strategist, Agent Development is posted at $200K to $290K plus equity.

And the demand is not theoretical. Microsoft's 2026 Work Trend Index reports that "the number of active agents in the Microsoft 365 ecosystem has grown 15x year over year" (Work Trend Index). Read the requirements on these postings and the same word keeps appearing: Gusto's Agentic Operations Architect asks for "orchestration, HITL protocols, override and escalation logic".

Orchestration is the skill. Not writing one clever prompt, but taking one real job, splitting it across several agents, deciding who gets what and in which order, and then proving the result holds up often enough to be trusted. That is what the five prompts below build, in that order.

The ladder, and where a project sits

A Claude project is a good start and it is genuinely where you should begin. It is also not the comprehensive version, and it is worth being honest about why, because the gap between the two is the entire job.

1. 1 · A project is one assistant with saved instructions and saved context. Great for a repeatable task you do the same way every time. Its ceiling is that one set of instructions and one pile of context has to serve every part of the job at once. Projects are on the free plan, capped at five (Claude Help Center).
2. 2 · A skill is a saved procedure you can hand to Claude on demand. In the Claude app you find it under Customize, then Skills, then the plus button, then Create skill, then Upload a skill, and it takes a zip of your skill folder (Claude Help Center).
3. 3 · A team of subagents is the real version. Each one gets its own objective, its own output format and only the tools its job needs, and several can run at the same time. Anthropic names four reasons for this: context isolation, parallelization, specialized instructions, and tool restrictions (the docs).
4. 4 · An evaluation is what turns the whole thing from a demo into evidence. Twenty real cases, a pass bar you write down in advance, and rounds of fixes until it holds.
5. 5 · The screenshot is what you actually show an employer.

Two minutes of setup

1. 📌 Pick one weekly task. Something you do every week, that has a right answer, and where you have old examples sitting in your email or your drive. Weekly client updates, triaging incoming requests, first-pass qualification, categorising expenses, drafting the same kind of reply. Avoid anything creative, because you cannot score it.
2. 📥 Collect twenty past examples. Twenty real inputs, and next to each one the result you actually approved at the time. This is the only tedious part and it is the part that makes everything else work. Anthropic's own advice for agent evaluations is to start with about 20 queries representing real usage patterns, which is exactly what this is.
3. 🌶️ Include the awkward ones. The edge cases, the ones you got wrong the first time, the ones where you changed your mind. A test set made only of easy cases tells you nothing.
4. 🙈 Do not show the answers first. Keep the approved results out of the chat until the evaluation prompt asks for them. If it sees them upfront it will match them, and you will learn nothing.

Turn your process into agent instructions

Start in a Claude project. This is the good-start rung, and it is worth doing on its own before you split anything, because you cannot divide a job you have not written down.

I want to turn a task I do every week into an AI agent I manage. The task is: [task]. Here is my current process, step by step: [paste your process].

Before writing anything, ask me up to three questions about what a great result looks like and what I would reject outright.

Then write the agent's instructions as if you were briefing a new hire on their first day: its goal in one sentence, the inputs it receives, the steps in order, the exact output format, the quality bar, an explicit list of things it must never do, and the situations where it has to stop and hand the work back to me instead of guessing.

End with a short self-check the agent runs on its own work before returning anything, phrased as questions it has to answer yes to.

Split it into a team

This is where it stops being a prompt and starts being orchestration. It also tells you honestly when the answer is still one agent.

Here are the agent instructions we just wrote: [paste them].

Right now this is one assistant doing everything in one pass, and that is where it starts breaking: the same context gets reused for jobs that need different judgment, and one weak step quietly contaminates the rest.

Split it into a team. Propose three to five specialist roles, and for each one give me the role name, the single objective it owns, the exact output format it must return, the tools or sources it is allowed to touch, and the boundary where its job stops. Nothing vague like "researcher", tell me what it researches and what it hands back.

Then tell me which orchestration pattern fits this work and why, choosing from routing (classify the input and send it to the right specialist), sectioning (split into independent pieces that run at the same time), orchestrator and workers (a lead agent breaks the job down and combines the results), and evaluator and optimizer (one agent produces, another critiques it in a loop).

Finish by telling me which roles can genuinely run at the same time and which have to wait for another role's output, and be honest if this task is simple enough that one agent is still the right answer.

Actually create the subagents

Run this inside Claude Code, in a folder for your project. You are not writing code, you are writing a sentence, and Claude writes the files.

Create these as subagents in this project's .claude/agents/ folder, one markdown file per role, using the roles we just agreed: [paste the roles].

For each file, set a short lowercase hyphenated name, and write the description as the condition under which you should delegate to it, because that description is what you read when you decide who gets the work. Give each subagent only the tools its job actually needs and leave the rest out. Put the full role instructions in the body: its objective, the inputs it will be handed, the output format it must return, and what it must never do.

Then write me a lead agent prompt I can run at the top of a session. It should break an incoming job into pieces, hand each piece to the right subagent with everything that subagent needs written directly into its instructions, run the independent pieces at the same time, and then combine the results into one answer for me.

When you are done, show me the file list, and for each subagent show me its name, its description line and its tool list, so I can check the scoping before I run anything.

The mechanics worth knowing, all from the official docs:

Prove it works

This is the part that turns an opinion into evidence, and it is the part almost nobody does.

I want to prove this agent team actually works, not just that it looked good once.

Build me an evaluation set of twenty test cases from real examples of this task. Here are the inputs and the results I actually approved at the time: [paste your twenty examples]. Include the awkward ones, the edge cases and the two or three I got wrong the first time, because an evaluation set made only of easy cases tells me nothing.

Then propose the pass bar as one specific, measurable sentence. Not "good output", something I could argue about with a manager, for example "at least 18 of 20 match my approved result on the decision, with no invented figures".

Now run all twenty. Give me a table with the case number, pass or fail, the one thing that was different, and whether that difference would have mattered to the person receiving it. Score each one against the pass bar rather than against your own opinion of the output.

Finish with the total, the patterns behind the failures grouped rather than listed one by one, and which specialist role each failure belongs to.

Fix the right agent

Run this after every round. Two or three rounds usually gets you there, and the log it keeps is what you show people.

Here are the failures and which role each one belongs to: [paste the failed rows].

Change the instructions of the specific subagent responsible for each failure, not your approach for this one run, and show me exactly what you changed and why, line by line. If a failure is really a handoff problem rather than a role problem, say so and fix the lead agent's instructions instead.

Then rerun all twenty cases and show me the new table and the new total against the same pass bar. Flag clearly any case that passed before and fails now, because that means the fix broke something that was already working, and tell me which change caused it.

Keep going until we hold the pass bar twice in a row on the same twenty cases, and keep a short log of what each round changed so I can show my working.

What the evidence looks like to an employer

1. 📈 The two score tables. Your first run next to your last, against a pass bar you wrote down before you started. One image, and almost nobody applying has one.
2. 🗂️ The roles. A screenshot of your agents folder with the file names, and one file open showing its description line and its tool list. This is what shows you scoped the work rather than just prompting harder.
3. 📝 The change log. Three or four lines of what each round changed and why. Interviewers ask "how did you know it was working", and this is the answer.
4. 🚫 The never list. Paste it into any interview where somebody asks how you would stop an agent doing damage. A specific list from a real task beats any general answer about guardrails.
5. 🙋 One honest failure you could not fix. Name it, and say what you would need to solve it properly. This reads as judgment, not weakness, and it is the answer that separates people who have actually run this from people who have watched a video about it.
6. 🔂 Then do it again with a second task. Two worked examples is the point where it stops sounding like a hobby project and starts sounding like a practice.

Five certifications that genuinely teach orchestration

There are a lot of "AI certificate" lists that are really prompt-engineering courses with a new title. These five were checked against their own published syllabus on 18 September 2026 and every one of them actually covers multiple agents, delegation or evaluation. Ordered by what I would do first.

1. 1 · Anthropic, Introduction to subagents. Free (the button reads "Register | FREE"). Four lessons: what subagents are, creating one, designing effective ones, and using them well. No duration published. This is the fastest way to understand the thing the reel is about, and it pairs directly with prompt 3. It is a short course rather than a credential, so treat it as the on-ramp. Open it
2. 2 · LangChain Academy, Introduction to Deep Agents. Free. 43 lessons and 0.5 hours of video content. Its module on delegation includes lessons literally called "Building a Subagent Team", "Dynamic Subagents" and "Asynchronous Subagents", and it also covers evaluating agents. The page publishes no prerequisites, but it is a Python framework course in practice, so expect code. Open it
3. 3 · Hugging Face, AI Agents Course. Free, and the page states "The certification process is completely free" with no deadline. Each chapter is designed for one week at roughly 3 to 4 hours. Prerequisites are stated plainly: basic knowledge of Python and basic knowledge of LLMs. Its multi-agent unit teaches a Manager Agent for task delegation and an Orchestrator Agent that manages delegation and interaction. Open it
4. 4 · Salesforce Certified Agentforce Specialist. USD 200 plus tax, retake USD 100. 105 minutes, 60 questions, pass mark 72%, and the exam guide states prerequisites: "None". This is the only one here a genuinely non-technical person can sit, and it is the most credential-shaped. Be honest with yourself about the fit though: Multi-Agent Orchestration is a named section worth 5% of the exam, and the rest is prompt engineering, data and single agents. Open the exam guide
5. 5 · Google Cloud, Deploy Multi-Agent Architectures. 2 hours 45 minutes, marked Advanced, and it ends in a challenge lab. Its first lab covers using sub-agents and container agents to build multi-agent systems, and a later one covers connecting agents over the Agent2Agent protocol. The badge page prints no price: the platform has a no-cost Starter tier with 35 free credits a month and a paid tier at $29 a month, and I could not confirm whether these four labs fit inside the free credits, so go in expecting that you might have to pay. Open it

The job titles to put in an alert

Nobody posts jobs called "Chief Agent Officer" or "AI agent manager". These are the titles the listings actually use, and they change what you find completely.

The listings behind those titles

These are the ones I pulled the numbers from. Postings close, so treat them as proof the category exists rather than as jobs to apply to today.

• Sierra, Strategist, Agent Development, San Francisco, $200K to $290K plus equity. This is the $290k from the reel.
• Decagon, Agent Strategy Manager, San Francisco, $160K to $220K. The one that says coding is not required.
• Decagon, Agent Development Manager, New York, $150K to $220K.
• Gusto, Agentic Operations Architect. Worth reading in full, because its requirements are a free syllabus for this career.

The documentation this guide is built on

Claude Code subagents, the folder, the fields and the concurrency limit
Why subagents, in four named benefits
Anthropic's own multi-agent research system, the lead agent and the 3 to 5 in parallel
The four orchestration patterns
Building an evaluation set and writing a pass bar