📏 The decision-maker axis
In the previous module, you saw the two questions: who does each part e how the responses combine. Now let’s look at just one axis: who answers the first question. No if you orchestrate, but how much of the decision is yours and how much is the machine’s.
Think of a horizontal spectrum. At one end, left, you decide everything by hand—you open each model, copy, paste, and combine. At the far end right, a model trained to coordinate (a "conductor") decides on its own who does what. Everything else falls in between. This is the autonomy spectrum: the only thing that changes from left to right is who’s at the wheel.
🆕 New here? Three terms
- Autonomy: how much the machine decides without you. Low autonomy = you’re in control; high autonomy = it chooses on its own.
- Routing: the decision of "who does each part." It can be yours (manually) or a model's.
- Maestro / conductor: The component that reads the request and divides it up. On the left side of the spectrum, the maestro is you; on the right, it's a trained model.
Read from left (you’re in control) to right (the model decides). Each topic in this module is a point on this slider. The highlighted point—Fugu—is the destination of Track 2.
✋ Far left: you do it yourself
At the far left, The maestro is you. You take a task and decide in your head that the Codex (OpenAI’s coding agent, which runs in the terminal) is good for writing the skeleton, and that Claude is good for reviewing. Send it to the first one, copy the output, paste it into the second one, read both, and merge everything yourself into a final result. Manual routing, manual fusion.
This it’s already orchestration — except you’re the computer in the middle. It’s the oldest and most common approach: most people who use two AIs at the same time are doing exactly this, and don’t even call it “orchestrating.”
✓ What you gain
- ✓Full control: you see each output before using it
- ✓Clear costs: you pay only for what you send, model by model
- ✓Zero setup: no new platform to learn
✗ What it costs
- ✗Your time: you’re the copy-and-paste link between models
- ✗Doesn’t scale: 2 models are fine, 8 becomes manual labor
- ✗No real parallelism: you run one at a time
💡 Tip: this isn’t “amateur”
Doing it by hand has a reputation for improvisation, but it’s the form with more control of all. For a single important task, opening two models and merging the results yourself usually beats any automatic orchestrator — because you is the best judge of what's at stake. The problem isn't quality; it's repetition.
🧑🤝🧑 The middle ground: sub-agents and workflows
Take one step to the right and you delegate the copy and paste, but keep control. With sub-agents (workers that Claude Code opens, each able to run a different model—haiku, sonnet, opus) you say “open 3 agents in parallel, each from a different angle, and merge at the end.” The tool performs the fan-out and merge; you still defined the plan.
A little farther to the right are the workflows: a fixed rule you wrote once — "always run A, then B, then combine" — that triggers automatically. You still made the decision; it just became frozen Into a recipe. All of this generally runs within a single provider (intra-provider): same model family, same account.
💡 Copy-run: orchestrate in the middle of the spectrum
Goal: get a feel for the "sub-agents" setup — you define the plan, and the machine handles the fan-out + merge. Paste this prompt into Claude Code:
Abra 3 sub-agents em PARALELO sobre <assunto/arquivo>: agente A → levanta os PRÓS agente B → levanta os CONTRAS agente C → levanta os RISCOS escondidos Depois um 4º agente FUNDE os três num parecer único, marcando onde eles concordam e onde se contradizem.
How to verify: you’ll see 3 agents running at the same time (the fan-out) and, at the end, a consolidated assessment (the fusion) — without having copied anything by hand. Switch <assunto/arquivo> for something real of yours. Note: you designed the plan; the machine just executed it.
Sub-agents (you direct them)
You provide the plan for each run; the tool launches the workers and combines their results. Flexible, but you decide again every time.
Workflow (fixed rule)
You write the recipe once, and it repeats on its own. More autonomy, less flexibility—the decision is frozen.
Intra-provider
Almost always, everything is in one model family / on one account. Simple to bill and operate, but it doesn’t cross vendors.
🐡 Far right: inside a model
At the far right, the decision is completely out of your hands. A Model trained to coordinate receives your request and decides on its own whether to handle it right away or assemble a team, who joins the team, and how to combine everything. You’re in charge one prompt and receives one answer — the entire orchestra runs hidden inside.
That's exactly what the Fugu does (you’ll study it in depth in Track 2). From the outside, it looks like “just another model”: 1 endpoint, 1 API key. Internally, there’s a conductor that distributes work to a pool of frontier models you never even see. Autonomy is at its maximum—and, like all automation, it trades control for convenience.
The dashed box is the “model” you see. Everything inside—the conductor, frontier specialists, synthesizer—runs without you. Maximum convenience, minimum control.
📊 What the far-right end hides
The same “1 API” abstraction from module 1.1 reappears here, now at the far end of the spectrum:
- You don't see how many models ran or which ones.
- You pay the tokens from the whole team, not just the response.
- You trust In its routing—no chance to correct things midway.
🚦 The conductor that chooses the path
The shift from the left to the right of the spectrum has a name: routing — the decision of "who does each part." And the one who makes that decision is the conductor (the “conductor”). The key question for any multi-LLM system is simple: who’s the conductor here?
By hand, you’re the conductor. In a workflow, it’s the rule you wrote. In Fugu, it’s a small, inexpensive model trained just for this — it reads the request and decides handle it alone (if it’s easy) or Assemble a team (if it’s difficult). This “deciding whether it’s worth calling in the team” is the heart of a good orchestrator: calling in the team every time would be pointlessly expensive and slow.
The conductor branches: easy → handles it alone (fast, cheap); difficult → assembles the team and fuses. Knowing No calling the team is half the intelligence.
🎯 Who is the conductor at each point
- ←By hand: The conductor is you. You decide everything, every time.
- •Workflow: The conductor is the fixed rule you wrote.
- →Fugu: The conductor is a small model trained to route.
⚖️ Trade-offs: control × effort × cost
There’s no "best" point on the spectrum — just the right point for your task. Moving to the right switches your control and effort per convenience, but generally increases cost (more models running) and latency. Moving left gives you back control and lowers the cost, at the expense of your time.
The practical rule: single, critical task → stay on the left (you’re in command). Repetitive, well-defined task → go to the middle (workflow). Volume and variety, without wanting to think about routing → consider the right side (conductor model), knowing you’ll pay more for it. Track 2 shows, with 38 real tests, when that “paying more” is worth it (and when it isn’t).
Moving right: control ↓ and your effort ↓, but cost ↑. There’s no winning point—just the right point for what’s at stake.
✓ Stay on the left when…
- ✓The task is unique, critical, high-risk
- ✓You want to see and correct every step
- ✓Every dollar and every token matters
→ Go right when…
- →The volume is high and the tasks vary widely
- →You don't want to think about routing
- →Convenience is worth the extra cost
⚠️ The spectrum trap
“More automatic = more advanced = better” is false. The right side of the spectrum isn’t a trophy; it’s a trade-off. You give up control and pay more so you don’t have to think about routing. Sometimes it’s worth it; sometimes the simpler approach wins. This course aims to give you an eye for choosing — not to push everyone to the right.
🧭 The yardstick, from start to finish
By hand (Codex + Claude)
You're the conductor and the merger. Maximum control, maximum effort.
Sub-agents
You provide the plan; the machine handles the fan-out + merge.
Workflow
The rule you wrote once fires automatically.
Maestro model (Fugu)
A model routes and merges on its own. Maximum convenience, maximum cost.
Quick recall (optional): moving right along the autonomy spectrum mainly changes what?
✅ Module summary
Next module:
Track 2 — Fugu Ultra: the maestro model at the far right, with 38 real tests to find out when it’s worth it.