When Your Agent Runs Out of Tools

Every agent architecture starts the same way. List the workflows. Design a tool for each one. Let the LLM orchestrate.

It’s the right starting point. It’s also where most architectures quietly stop — and that’s the gap this post is about.

This is the story of a production deployment at a Fortune-100 enterprise, where an AI assistant built on carefully designed tools hit a wall, and why the answer was to embed a headless coding harness — OpenCode — inside the system.

The Setup

We built the assistant the conventional way. A multi-agent system with a curated tool registry: load the data, compare two versions, check values against thresholds, generate the standard report.

The LLM’s job was orchestration — pick the right tool, pass the right arguments, sequence the steps.

For every workflow we could name at design time, it worked beautifully.

And that’s the problem statement, hiding in plain sight: for every workflow we could name.

The Two Kinds of Requests

Once real users arrived, the requests split into two populations.

The enumerable ones. Compare these two datasets. Flag anything out of range. Produce the usual report. About 80% of volume. Fully covered by the tools. Fast, cheap, predictable.

The open-ended ones. They sounded like this:

“This behavior shows up in version X but not version Y, under these specific conditions. Figure out what could explain it.”

No predefined tool answers that. No predefined tool can — because the analysis doesn’t exist until the question is asked. Answering it means pulling data from multiple sources, slicing it in a way nobody anticipated, testing a hypothesis, watching it fail, and trying another. The analysis is code. Code that has never been written before and will probably never be needed in exactly that form again.

Here’s the part that changed how I think about agent design: these open-ended requests were only ~20% of volume, but they carried most of the pain. The enumerable work was already cheap before AI showed up — scripts and dashboards absorbed that cost years ago. The expensive requests were exactly the ones no tool registry could anticipate.

The Trap Everyone Falls Into

Our first instinct was the obvious one: add a run_python(code) tool to the existing agent. One more tool, and now it can do anything. Problem solved.

We prototyped it. The lesson arrived fast.

The moment you add arbitrary code execution, you inherit a pile of hard problems that have nothing to do with your domain:

1. 1.The model writes code, the code fails, and the error has to flow back in a form the model can act on — again and again, without blowing up the context window.
2. 2.Moving files between the model’s workspace and your data.
3. 3.Handling large outputs that can’t just be pasted into a prompt.
4. 4.Sandboxing, isolation, cleanup.
5. 5.Controlling what the generated code is allowed to touch.

None of these are unsolvable. All of them are already solved — by coding harnesses. Tools like OpenCode and Claude Code solve exactly these problems, productized and hardened by massive real-world use. We were about to build a worse version of something that already existed as open source.

That reframed the whole decision. It was never “custom agent vs. coding agent.” It was build vs. buy — on the code-execution loop.

Why a Headless Harness

OpenCode’s terminal UI is just a client. Underneath is a server — run opencode serve and you get a headless agent runtime with an API: sessions, streaming events, and a full loop that writes code, runs it, reads the errors, and iterates.

Three properties made it deployable in an enterprise.

It runs entirely inside your walls. Self-hosted, in a disposable container per task, with model traffic routed through the company’s approved gateway. No data leaves the environment.

Permissions live in config, not prompts. What the agent may read, run, and edit is declared in a reviewable file. Ours runs read-only on the data, no network access, write access only to its own scratch space. A security team can inspect that. You can’t inspect a prompt’s good intentions.

Every action is logged. Every script written, every command run, every file read streams out as events. We store the full trace. “How did the agent reach this conclusion?” has a replayable answer.

What We Deployed

The final system is layered — not either/or.

The original agent with its fixed tools stays in front, handling the enumerable 80% exactly as before: cheaper, faster, deterministic.

The coding harness sits behind it as one tool among the others — an escape hatch. When a request doesn’t match any known workflow, the orchestrator hands it off. A sandbox spins up, the harness writes and runs the analysis using the full ecosystem of libraries the domain already relies on, iterates until it has an answer, and returns the findings plus the code it wrote. Then the sandbox is destroyed. The trace stays.

And then the side effect I didn’t see coming — the most valuable part of the whole design:

The escape hatch became our tool factory. When the harness writes essentially the same analysis three, four, five times, that’s a signal. We review the generated script, harden it, and promote it into a proper fixed tool. The open-ended layer continuously converts unknown workflows into known ones. The 80/20 line isn’t static — the system moves it.

What It Costs

Being honest: code-writing loops burn more tokens and more time than a fixed tool call. You never want the harness re-deriving an analysis it has effectively written five hundred times — which is exactly why the promotion path matters. The sandbox-per-task pattern adds infrastructure to run. And open-ended output needs a human review gate: the agent drafts conclusions, a person owns them.

Edge Case, or the Whole Point?

Almost every agent architecture I see published assumes the task space can be enumerated. Define the tools, orchestrate the tools. The open-ended tail gets a shrug, or a run_python bolted on at the end.

But in our deployment, the tail was where the value lived.

If that pattern generalizes — and I suspect it does, across domains — then a governed coding sandbox isn’t an exotic add-on. It’s a default component of serious agent architecture, paired with a promotion path that turns its discoveries into fixed tools.

I’d genuinely like to be argued with on this. If you’re running agents in production: how big is your unenumerable tail — and what are you doing about it?