Orchestration in the wild: what one line of input actually triggered

It's easy to have 1 agent that works great solo. The wall comes when you try to make them work as a team. You run one agent, copy the output, open another window, paste it in, run the next one. You're the integration layer. You're the thing holding the handoffs together, by hand, every time.

I want to walk through one session where the system did the stitching instead of me, and show you the mechanics — what each step actually loaded and did — because that's the part you can build, not the part you feel.

The setup was ordinary. We're scoping a project for a nonprofit prospect. Just got off a call, I had the transcript, and they were owed a follow-up with a ballpark on cost. I typed one line into the chat: "ingest this transcript and update the folder on this prospect." Then I watched what the orchestrator did with it.

First, what "Duke routed it" actually means. Duke is my orchestrator. He doesn't do the work. He reads the request, decides which specialist owns it, and loads that specialist's instruction set before handing off — the role file, the voice doc, the guardrails, and whatever skills the task calls for. The routing IS the framing. When Duke "passes it to Pike," that's really Duke loading Pike's instructions into the context so the next thing that runs is a framed researcher, not a blank model with a prompt taped to it.

So the transcript went to Pike, my research specialist. Pike ran the ingest skill against the raw transcript — pulled what changed since the last call, which open questions got answered, the next step, a couple of risk flags — then loaded the existing prospect folder so it added to what was already there instead of rebuilding from zero. Output: an updated folder and a clean read on where the deal stands.

That updated read made the actual next step obvious — the prospect was owed a pricing email. Duke loaded Cash, my copywriter: my voice doc, the guardrails, the prospect context Pike had just refreshed. Cash drafted the email. Notice the handoff structure — Pike's output became the framed input for Cash. The folder Pike updated is what Cash read to write.

Then Duke ran Pike a second time, in a different mode. Cognitive-profile mode — a separate instruction set that reads decision-style signals out of the raw transcript against a framework. Not "what did they say," but "how does this person decide." Fast mover or careful, logic-driven or relationship-driven, what they need to see before yes. That profile got written to the prospect folder too, so the framing for the offer matched how this specific person decides.

Then the email went to Buck, my sales coach, before it ever reached me. Buck isn't a cold proofreader. He ran a Sandler diagnostic — pain, budget, decision process, who controls the call — against his own prior brief on this exact deal that was already in his folder. So he's reading the draft against what he already knew about the deal, not reacting to it fresh. He caught that the way the email was framed quietly positioned us as the cheap option. Named it, gave the fixes. Then back to Cash to revise with Buck's notes and Pike's profile baked in.

That's the verify principle doing real work: a second specialist reviewed the first one's output before it got to me. No agent graded its own homework.

So one line of input ran a framed researcher, a framed copywriter, a framed profiler, and a framed sales coach — each loading its own instructions, reading the previous step's output, writing back to a shared folder. That's orchestration as plumbing, not as a smarter prompt.

The one thing worth pulling out: Pike and Buck reached the same conclusion about how to position the offer. Pike got there reading the person's decision style. Buck got there reading the sales mechanics. Different frameworks, same source transcript, no contact between them. That's not magic and it's not two experts having a moment — it's a mechanical property of the setup. Run two independently-framed specialists against the same input and you get a cross-check you didn't have to engineer. The agreement is information. The disagreement would have been too.

If you want to build toward this, don't stand up the whole team. Take one task you run every week — a follow-up email, a recap, a profile — and route it through two framed specialists instead of one: one that produces, one that reviews against its own prior context before it reaches you. Make the second one read the first one's output from a shared file, not from your clipboard. That's where I'd start, and it's the smallest version that still shows you the property.

One thing I don't do: let it send. The orchestration could. It has the MCP to push that email into Gmail and hit send on its own. I don't run it that way. It writes a markdown file to my outbox, I open it, proof it, make my own adjustments, and send it by hand. On a deal this size I'm not handing the last move to a machine.

The loop runs the other way too. When something's off — the read on the deal, a line that doesn't sound like me, a profile that missed — I come back to the orchestrator and tell it, and that correction turns into an agent update or a memory if it's worth keeping. So I'm not just the gate at the end. My judgment flows back into the system and changes what it does next time.

That's the part I'd want a builder to take from this. Orchestration done right doesn't remove you. It hands you the work framed, reviewed by a second specialist, ready for your call — and on a deal that matters, that's the whole point, not a limitation. I'm not handing a big prospect to full automation, and I built it that way on purpose.

17 comments