Why Specialist Agents With Audit Trails Beat Opaque Conductor Models
Sakana Fugu hides routing in a 7B conductor model. AskCodi shows you which specialist did what. For production debugging, the difference is everything.
Sakana Fugu shipped GA two days ago. A 7B Conductor model that decides which LLM handles each subtask. Single API call, fully opaque to the caller.
It's smart. It's fast. It's a black box.
That's fine for prototyping. It's a problem in production.
We built AskCodi's CTO orchestrator on the opposite bet: specialist agents, one job each, with a visible audit trail of which model handled which task. This post is about why that bet wins for production work.
The day-2 question
Every multi-agent demo looks great on day 1. Click run, get output, ship it.
Day 2 is when an agent does something weird. A change you didn't expect. A model swap you can't explain. A subtask that took twice as long as the others. An obvious mistake you can't trace back to anything specific.
Day 2 is when you discover whether your tool was designed for production.
The question that matters: when something goes wrong, can you trace WHICH agent made WHICH decision?
For opaque orchestrators, the answer is no. The routing decision is a model output. You see the final answer. The intermediate choices are inside a black box.
For bounded specialist agents with explicit task assignment, the answer is yes. The task assignments are logged. The model choice per task is logged. Every tool call, every git operation, every diff is logged.
That difference is the whole post.
What "bounded" means
A specialist agent has one job. Not "do whatever the orchestrator says." Specifically: "handle backend changes in this worktree" or "fix type errors in this file."
The job is declared, not inferred. The CTO orchestrator picks the job and assigns it. The specialist accepts only that scope.
Side effects are constrained. A frontend specialist can't push backend changes. The git worktree boundary makes this physical, not just policy.
This sounds like overhead. In practice it's the thing that lets you sleep at night when the agent is doing 6 things in parallel on your repo.
What "audit trail" means
Three logs, all visible:
- Every model call. Which subtask. Which model. Which agent. What the request looked like. What it returned.
- Every git operation. Which specialist made which commit on which worktree. With the full diff.
- Every tool call. MCP, shell, filesystem. With arguments and results.
The audit trail isn't an afterthought you bolt on for compliance. It's how you trust the system enough to give it more work. Trust scales with visibility.
Sakana Fugu's design, the contrast
Sakana's design is internally consistent and good for what it's optimized for. It's also the opposite of audit-trail-friendly.
One Conductor model picks routing. The routing decision is a model output, not a logged choice. You can read the model's logprobs if you really care, but that's not auditing, that's archaeology.
Sub-agents communicate in natural language (per the Conductor paper). Great for capability, opaque for debugging. You can't grep a natural-language exchange the way you can grep a logged task assignment.
The single API call returns the final answer. You don't see the intermediate routing. By design.
This is great for hosted apps where the consumer just wants the answer. It's not great for engineering work where you need to know which model rewrote your auth middleware.
The contrast isn't capability. Sakana's Conductor is probably smarter at routing than my heuristics. The contrast is what you can do when something is wrong.
AskCodi's architecture, the specifics
Here's what bounded-specialists-plus-audit-trail looks like concretely.
The CTO orchestrator runs locally on your machine. It accepts a feature request and breaks it into subtasks.
Each subtask gets:
- An explicit model choice (visible in the task log: "FrontendSpecialist using Claude Sonnet")
- A specialist agent (backend, frontend, testing, security)
- Its own isolated git worktree (so parallel work doesn't collide)
- Full filesystem + shell + MCP access INSIDE that worktree (real execution, not just text)
After execution, each specialist returns a diff. The CTO reviews the diffs, resolves any conflicts, and either merges or kicks back to the specialist for revisions.
Everything is logged. Every model call. Every git operation. Every tool call. Re-runnable. Auditable.
Real scenarios where the audit trail saves you
The abstract argument is easy to make. Here are four cases where the audit trail does specific work.
1. A specialist agent rewrites something it shouldn't have.
You ask the CTO to "fix the login form validation." The frontend specialist correctly fixes the validation but also rewrites the auth middleware on its way out. You look at the diff and ask: why?
With an audit trail, the log shows the specialist's task assignment (frontend changes only), the model it used (Sonnet), the file it touched outside scope (the auth middleware), and the chain of tool calls that led there. You scope the prompt tighter, you re-run, problem fixed.
With an opaque orchestrator, you guess. You add a system-prompt hint and hope.
2. A model hits a limit mid-task.
You're using Claude Opus heavily this week. A complex subtask kicks in and Opus is rate-limited. The CTO falls back to Sonnet to finish. The work ships, but quality is slightly worse than usual.
Audit trail shows exactly where the fallback kicked in. You learn your task mix. You adjust the per-task model preference. Next week, fewer fallbacks.
With opaque orchestration, you see "the answer was slightly worse." You don't know why.
3. A PR has a subtle bug.
The agent shipped a fix. Two days later you find the fix broke a related edge case. You need to know whether the bug was introduced by the model's reasoning, the task definition, or the tool call.
Audit trail shows the specific subtask, the model's reasoning step, the tool calls, and the final diff. You fix the prompt or the task spec. Not the code.
Without the trail, you fix the code and the underlying issue stays.
4. A new team member asks "why did the agent do this?"
You can show them. Task assignment, model choice, reasoning, diff. They learn the system in an afternoon.
In the opaque case, you can't answer. You shrug and they learn to mistrust the tool.
The deeper pattern (this is the brand)
"Specialist agents, one job each, with audit trail" isn't just AskCodi's design. It's a positioning bet about where multi-agent goes in 2027.
Conductor-style orchestration wins for hosted apps that consume AI as a service. Sakana Fugu is the first credible product in that space. There will be more.
Bounded-specialist-plus-audit-trail wins for teams that ship code in their own repos and have to live with the consequences. That's a different market. We picked that one.
Both designs are correct. They just optimize for different priorities. If you're a team shipping production features, the priorities you actually feel on day 2 are visibility, debuggability, and trust. Not raw routing intelligence.
Close
Sakana Fugu is impressive engineering. Use it where it fits.
For shipping code in your own repo, with traceable decisions you can defend in a PR review, the bounded-specialist pattern wins. That's what we built AskCodi for.
Get the desktop app: https://www.askcodi.com/get-app (macOS Apple Silicon is live; Windows and Linux are in progress. Launch offer: $5 in Claude credits free, valid 30 days, usable on any Anthropic model.)
If you want the full comparison with Sakana, Sakana Fugu vs AskCodi CTO walks through it. If you want the research underneath Sakana's design, Multi-Agent System as a Model breaks down the TRINITY and Conductor papers.
Day 2 always comes. Build for it.
