The Best Agent Is Not an Agent

I keep seeing new agent frameworks come around, and I get it. I see the value, I see where they’re coming from, and it’s genuinely great engineering. But I think they miss what’s great about AI.

Building Stakpak taught me one thing above everything else: give the agent the tools and the requirements, then let it do its work. What I see in these frameworks is the old idea. Design the workflow, define the pipeline. Even when it’s customizable at runtime, it’s still defined in advance by a developer, for every task the agent will ever see.

What I’d argue instead: give the agent the ability to build its own workflow, end to end, per task.

This post is my case for that, including the strongest argument against it. I know that argument well because I make it to myself every week.

Setup beats intelligence

Anyone who builds agents has run both versions of the same experiment.

The maxed-out agent has the best model and every tool mounted: GitHub, filesystem, browser, search, Slack, a stack of MCP servers you might need someday. Ask it to fix an auth bug and it greps the wrong files, “researches the error” in the browser, patches code that doesn’t compile, and declares victory.

The stripped-down agent gets three tools, the failing test pasted first, the two files the stack trace points at, and one instruction: make this test pass without breaking the others. Done in minutes.

Same model. The difference between those two runs is the setup, not intelligence.

I wrote about Min(Input) → Max(Output) as the equation behind agentic systems: make useful context reachable, then deliver the minimum sufficient context per step. This post is that equation chased to its end. If the setup decides whether an agent succeeds, then the real question is who builds the setup.

Today the answer is always a developer

Look at the two best frameworks I know.

Eve, from Vercel, makes an agent a directory. instructions.md, tools/ as TypeScript files, skills/ as markdown playbooks. Drop a file in a folder and it’s wired in. Next.js for agents. But notice who writes every file in that directory. The developer. Which tools, which skills, which model, all decided at build time for every task the agent will ever see. A fix-a-bug agent and a write-a-report agent need completely different setups, and you’re hand-building each one.

Flue 2.0 went further and admitted the problem openly. They dogfooded static agent definitions and found they break down on complex multi-step work. Their fix is Agent Hooks, which is basically React for agents. Now the setup can change at runtime:

if (step === 'diagnose') {
  useModel('anthropic/fable-5-0');   // big model for the hard part
  useSkill(debuggingGuide);
}

I love this API. I also think that if statement is the whole problem in four lines.

The runtime is dynamic now, but the authorship isn’t. A developer still decided that diagnosis needs the big model. A developer wrote the state machine, the escalation condition, the tool-per-step mapping. Eve has you writing architecture as files and Flue has you writing it as code. Better languages, same author.

But models can write code. So why can’t the agent build its own state machine upfront? Take the task, decide the steps, pick which step gets the big model, which gets a skill, which needs a review pass, then run it. Flue’s hooks are exactly the right API for this. They’re just being called by the wrong author.

The objection I make to myself

Here’s the pushback, and it’s real: I already know the problem.

When a task comes in, I can usually define the workflow in an afternoon. Pull the ticket, mount these three tools, run the tests, use the big model for the diagnosis step. It works today, and it’s fast, cheap, and predictable.

A setup agent doing the same job is worse at first. It explores, it over-gathers context, it makes mistakes, and it burns time and tokens deriving a state machine I could have typed from memory. Lower floor, slower start. Why would I ship that?

Because floors and ceilings behave differently.

My hand-written workflow’s ceiling is my own understanding of the task on the day I wrote it. It never gets smarter, it only decays, because every condition in it is a bet about model capabilities and those bets expire. One release later the small model handles diagnosis just fine, and my carefully tuned escalation logic is nothing but latency and cost. Workflow definitions are technical debt that rots with every model release.

The agent-built setup inverts both curves. Its ceiling is the model’s ceiling, and that rises every few months without me touching anything. Its maintenance cost is near zero, since there’s nothing to refactor when a release lands and no conditions to re-tune. Same requirements in, better state machine out. The models are evolving and your system evolves with them, for free.

We’ve seen this movie before. The Bitter Lesson says approaches that ride growing computation eventually beat approaches that encode human knowledge. It happened in chess, in Go, in speech, in vision. Hand-authored workflows are the human-knowledge approach for agents. They win the first year and lose every year after.

We already tried pieces of this at Stakpak

This isn’t all theory for me. We shipped some of these primitives in Stakpak, and the results are what convinced me the full version is worth building.

One was dynamic subagents. Instead of a fixed roster of workers defined by us, the agent defines its own subagents per task: what each one is for, what context it gets, what it should come back with. We didn’t decide the team structure, the agent did, and it built a different team for a Terraform migration than for a crashing pod.

Another was task boards. For each task the agent creates its own kanban board with custom tickets: the steps it planned, what’s in progress, what’s blocked, what’s done. Nobody hand-designed those workflows. The agent laid out its own, and you could watch it move its own tickets as it worked.

Both are small versions of the same idea: the agent authoring a piece of its own setup instead of executing ours. And both times the experience and the results were great. Users trusted the agent more because they could see how it structured the work, and the structure fit each task instead of being the one pipeline we happened to design. That’s what makes me confident about the step further: if the agent can define its workers and plan its board, it can build the whole setup.

So the job is tooling, not workflows

“Eventually” carries a lot of weight in that argument. A setup agent that starts from zero on every task stays slow, because it keeps re-deriving what I already know. The fix isn’t waiting for a smarter model. The fix is building the tooling that makes agent-authored setups fast.

Three pieces, and notice that the frameworks already built all of them:

• Primitives for the moves a setup makes. Mount a tool, load a skill, pick a model, add a review pass. Flue’s hooks are exactly this API.
• Serialization, so a good setup is an artifact instead of a lucky run. Cached, versioned, diffed, reusable. Eve’s agent-as-directory is exactly this format.
• Playbooks, so the tenth bug-fix task doesn’t start from scratch. It starts from the setup that worked the last nine times and re-plans only what’s different.

With those in place the floor rises fast, because the agent isn’t designing from zero anymore. It’s retrieving a known-good setup and adapting it. The frameworks built these pieces for us. They should hand them to the agent.

The research already points here

This isn’t just my read. The research has been circling the same idea from five directions:

• Darwin Gödel Machine (Sakana AI): an agent that rewrites its own harness, keeping only changes that pass a benchmark. SWE-bench went from 20% to 50% with the model never changing. Only the setup did.
• ADAS / Meta Agent Search (ICLR 2025): a meta agent that programs new agents in code and archives what works. The discovered designs beat hand-built agents, and kept winning when moved to new domains and new models.
• Alita: “minimal predefinition, maximal self-evolution.” One core capability, generating the tools each task needs on the fly. It beat frameworks shipping dozens of built-in tools on GAIA. That’s the stripped-down agent, as a research result.
• ACE, Agentic Context Engineering: contexts as evolving playbooks that accumulate strategies across tasks instead of static prompts.
• Anthropic’s harness engineering guide: their advice for long-running agents describes an initializer agent whose whole job is to prepare the environment that future worker agents will need. They built the thing and filed it under implementation details.

A meta agent. A minimal agent that grows tools. A harness that rewrites itself against a check. A playbook that compounds. An initializer that prepares the environment.

Five fragments, one idea: before an agent works, another agent sets up its workspace.

I call it the setup agent. Once you see it, you realize who’s been playing that role all along. The developer. Manually, slowly, with decisions that expire every release.

What the setup agent optimizes

“Best agent” is not an intelligence problem. The labs are winning that race without our help. It’s an optimization problem, and the search space is the setup. Three variables matter:

Least tools. Every mounted tool is noise: one more wrong option, one more description clogging the window. The maxed-out agent doesn’t fail because the model is dumb, it fails because the setup makes being smart hard. Alita winning GAIA nearly tool-less is the same proof at benchmark scale. Fewer tools isn’t austerity, it’s signal-to-noise.

Right context. Not all the context, the right context. Gather widely, hand over narrowly: read the repo, the ticket, the history, then pass on only what matters. The failing test pasted first beats the whole codebase attached, every time. This is the “minimum sufficient context” half of the equation from my last post, turned into an explicit job.

A clear check. Every setup needs a definition of done: the test suite, the schema, the reconciliation. This is the scarcest asset in the system. The DGM’s climb from 20 to 50 ran on nothing more exotic than having a check and keeping what passed it. No check, no loop. No loop, no improvement. If you can’t write the check, you haven’t understood the task yet, and neither will the agent.

The default setup is boring on purpose:

one model + few tools + right context + one check

No planner, no reviewer, no team of eight. Anthropic’s guidance says the same thing: start with the simplest pattern and add complexity only when it demonstrably pays. The setup agent explains why that’s the right default. Complexity should never be a design decision made up front. It should be a response to a failed check.

From there, two loops. The fast loop lives inside one task: run, check, adjust, run again. If the check fails, change the setup. More context, a different tool, split the work, add a review pass. The slow loop lives across tasks: every finished run leaves a note about what kind of task it was, what setup it got, and how it went, and those notes curate into the playbook that seeds the next task. The fast loop makes this task succeed. The slow loop makes every next task start closer to done. The intelligence compounds in the setup, not the weights.

Setups are software

ADAS found that discovered agent designs transfer across domains and across models. That means a working setup isn’t a lucky prompt. It’s a small portable program: this context strategy, this tool selection, this check, in this order.

Which means the playbook isn’t a diary. It’s a codebase.

Setups can be versioned, diffed, code-reviewed, shared on npm like Flue’s hooks or dropped in a folder like Eve’s skills. “Bug fixes get the failing test first.” “Refactors split by folder.” “Reports get a review pass.” That knowledge survives every model upgrade, because it encodes how to prepare work, not how to think. Models come and go. Preparation knowledge accrues.

Does this exist yet? In pieces. EvoAgentX is closest, building multi-agent workflows from a prompt and evolving them against automatic evaluators. The ADAS, DGM, AFlow, and Alita repos are all public. But nearly everything out there is an offline optimizer: search for a good workflow against a benchmark, then freeze it. The full loop, where a runtime setup agent prepares a minimal setup per task, adjusts live against a check, and feeds a versioned playbook, isn’t shipped anywhere I can find. That’s not a gap in the argument. That’s the opportunity.

Two things that will still bite you

Vague asks poison everything downstream. The setup agent’s first move has to be turning a fuzzy request into a clear one, sometimes by asking a question instead of guessing. A perfect setup for the wrong task is worthless, and no loop recovers from it.

No check, no loop. “Make the tests pass” is verifiable. “Write a good strategy” isn’t. Where there’s no check, the fast loop has nothing to feed on, so hand the judgment back to a human. A system grading its own homework learns to flatter itself. The hard boundary of this whole approach: the setup agent is exactly as powerful as the checks it can construct.

Where this leaves us

Stop asking how to make your agent smarter. The labs have that covered, and every release quietly deletes some of your scaffolding. Build the system that benefits from deletion instead of the one that rots.

Give the agent the tools and the requirements, and let it do its work, including the work of deciding how to work. Least tools, right context, a clear check, and a note for next time.

The best agent isn’t an agent. It’s a system that prepares, checks, adjusts, and remembers, so every task starts better than the last one ended.

If you’re building something like this, or think I’m wrong, find me on X or LinkedIn.