Eidren was first built around a familiar pattern: plan, execute, check. Given a request, a planner produced a structured sequence of steps, including the tool each step would use and the arguments it would receive. An executor ran those steps, in parallel when their dependencies allowed. A critic then checked the result against the request.
For many bounded information-gathering tasks, this worked well. A useful plan might contain a search query, a URL to inspect, or a question whose answer another step depended on. The arguments were small, and the structure was the valuable part: what needed to be learned, what could happen concurrently, and what depended on what.
Then, during development, we applied the same architecture to building things – and testing showed exactly where a plan's job should end.
The plan became the work
Ask an agent to build a landing page. Under our original architecture, the planner could not simply say create the landing page. It had to produce the arguments for the tool that would create it – which meant generating the page itself, inside the structured plan.
As the artifact grew, the plan stopped being a compact description of future work and became a serialized copy of the work. In testing, generation was cut off inside the file payload, the structured output no longer parsed, and retries ran into the same limit. Eventually the system produced something small enough to fit: effectively a placeholder.
From the outside, it looked as if the model could not build the page. That was the wrong diagnosis. When the same content was generated during execution rather than inside the plan, the model produced it. The limit was in where the content was generated, not in the model: the page was being bound too early.
Bind intent early. Bind payloads late.
The problem was not planning. It was asking a plan written before execution to materialize values that belonged to execution.
Some things are available before work starts: the objective, the constraints, the definition of done, known dependencies, relevant context, and sometimes a useful decomposition of the problem. Other things only become knowable by doing the work – the contents of a generated file, an edit chosen in response to a failing test, a follow-up query prompted by an unexpected search result, an action whose parameters depend on what the previous tool call returned. Putting those into an up-front plan guesses the future and then encodes the guess as execution state.
Our design rule became: bind intent as early as possible; bind execution-dependent payloads as late as possible.
Plan size should follow decision complexity, not output size
The rule gives a useful diagnostic. Suppose two tasks have the same structure, but one produces a ten-page artifact and the other a hundred-page one. The second may need more execution. It should not need a plan ten times larger merely because its output is ten times larger.
If the planning representation grows in proportion to the artifact, content is being generated at the wrong layer. A plan is useful because it compresses the shape of the work. Once it expands into the work itself, that advantage is gone.
What changed in Eidren
Our first response was to separate two execution styles. Tasks whose structure could be established ahead of time kept explicit planning; artifact-producing work moved to a tool-calling loop – choose an action, observe the result, decide what to do next.
We later made the distinction simpler. Action-oriented work in Eidren now runs through an iterative loop. Planning still exists, but its contract changed. Instead of predicting the complete trajectory, the preparation stage establishes the state that execution starts from: the objective, the constraints that govern it, the context that matters, and what earlier attempts learned. What a successful result must satisfy is drawn from the request and checked against the outcome. The loop chooses each action from the state that actually exists when the action is taken, so a building task does not need an exhaustive list of future tool calls before the first one runs.
The important difference is not planning versus no planning. It is planning as control state, rather than planning as a serialized future.
Feedback belongs inside execution
This matters for more than large payloads. Suppose the agent changes a file and a test fails. The failure is new information. A fully materialized plan either continues despite it or needs a mechanism to rewrite itself. An execution loop has a simpler contract: the failed test becomes part of the state used to choose the next action.
The same holds outside software. A search shows an assumption was wrong. A website looks different from what was expected. A credential has expired. A document changes the next question. The more a task depends on intermediate observations, the less useful it is to bind its exact future actions before those observations exist.
Adaptability is not authority
Moving decisions into the loop raises an obvious concern. A static plan can be inspected before it runs; a dynamic loop decides as it goes. We did not want adaptability to mean unbounded authority, so the execution model separates choosing an action from being permitted to perform it.
The model proposes what should happen next. Policy enforced outside the model decides whether it is allowed. Configured permissions and approval requirements stay binding throughout execution, and routing works within those boundaries rather than widening them.
External changes also need different failure semantics from reads. If a write fails ambiguously, the absence of a successful response does not prove that nothing happened, and a blind retry can duplicate the effect. A failed write is retried only when repeating it is known to be safe; otherwise the outcome is reported as uncertain rather than risk doing it twice. And the loop runs within explicit budgets of actions and time.
The model chooses the next move. The system defines the legal moves.
Checking the outcome, not the script
Changing planning also changed what it means to review a run. The original critic could compare execution with the plan, but following the plan was never the property we cared about – producing the right result was. So validation moved from plan conformance to outcome conformance. For building work, that means structural checks, the project's tests, and a review of the resulting changes against the request. When a result fails those checks, execution continues with the failure as new evidence.
That replaces predict every action, execute the prediction, check the prediction was followed with act, observe, evaluate, repair. A good autonomous system should be free to find a better route than the one it imagined before seeing the environment. It should not be free to quietly change what counts as success. The route is adaptive; the objective and constraints remain the reference point.
It is also why we think the useful place to check autonomous work is around consequential actions and observable results rather than every step in advance – the argument of The cost of checking.
Where an explicit plan still helps
None of this makes explicit plans obsolete. They help when the structure of a problem is knowable ahead of time: a research task with several independent questions that can be investigated at once, a migration whose dependencies are worth identifying first, a workflow with expensive operations that benefits from exposing its structure before anything begins.
The mistake is treating the plan as the place where every future action and argument must already exist. A plan can describe dependencies without fabricating observations, establish constraints without generating artifacts, and identify work without performing it in advance. That is the boundary worth drawing clearly.
The principle
The lesson is about where information should become concrete. A plan should carry the task's intent, constraints, success conditions, and useful structure. It should not be forced to contain execution-time payloads that can only be produced – or correctly chosen – while doing the work.
Bind what is stable early. Bind what depends on observation late. Let execution discover the route, keep authority outside the model, and judge the work by the result rather than by whether reality followed a script written before it began.
