Pull Decisions Forward or Your AI Agents Will Guess

Teams hand their coding to an agent and come back with the same list every time. Spaghetti code. Database connections wired wrong. Classes mixed together. Files named nothing like the rest of the repo. Modular and adapter patterns ignored. Nomenclature invented on the spot. The list runs long and almost every item on it is true.

The conclusion people draw from that list is that the model is not good enough yet. That conclusion costs organizations a year of adoption, because the model did exactly what it was told. It was told to do a job that still had planning buried inside it, so it planned, badly, in the dark, at three in the morning, and never wrote the decision down.

Every complaint about AI output traces back to a decision nobody made before the agent started.

Every piece of work we do, from a two-line email to a system migration, runs the same loop. Plan -> Execute -> Validate, then back around until it passes. Moving execution to AI is where nearly all of the speed comes from. But execution only transfers cleanly when the decisions come out of it first.

The Loop You Run Without Noticing

Take an email. You do not just write an email.

You decide who it goes to. How you want it to land. What you want implied rather than stated. What action you want back. What questions they might ask, so you can answer them now and kill the reply. That is planning, and it can take four seconds or it can take four people across two weeks.

Then you write it. That is execution.

Then you read it back, out loud if it matters, and you check it against everything in the plan. Did it accomplish what you wanted? Is the tone right? How will this get read by someone having a bad day? That is validation, and it is either a two-second scan or a formal review, depending on whether the thing is an answer to a question or a proposal.

Planning Happens in Seconds

The macro version of this is visible. Strategy documents, architecture reviews, sprint plans. Nobody misses those.

The micro version is the one that breaks agentic work, because it is invisible. While you write a file you are constantly ducking back into planning and iterating, hundreds of times, without ever calling it planning. Those micro decisions never get written down anywhere, which means they do not exist as far as an agent is concerned.

👉 Tip: Take the last agent output you rejected and list every decision the agent had to make to produce it. Each item on that list is a planning artifact you owe the system, not a prompt you need to improve.

Residual Decisions

Here is what actually happens when you ask an agent to add a feature.

It has to decide where the file goes. What to name it. What classes it holds. Whether this belongs inside an existing class or needs a new abstraction. Whether your adapter pattern applies. Which of your three logging conventions to follow. Whether to write the test first. None of that is execution. Those are residual decisions, left inside the task because nobody pulled them out, and the agent has to resolve them before it can type a single line.

The Cost Is Inconsistency, Not Wrongness

This is worth sitting with, because it changes the fix. The agent is not producing broken code. It is producing reasonable code built on decisions it made alone, which means the next task gets a different set of reasonable decisions. Run that across forty tasks and you have forty local optima and no system.

You cannot prompt your way out of this. A better prompt is just a faster way to hand over the same undefined job.

👉 Tip: Keep architecture decisions in version-controlled files the agent loads on every run: CLAUDE.md, a decisions log, steering documents. A decision made in a chat window dies with the session and gets re-guessed tomorrow.

Pulling Decisions Forward

The fix is unglamorous and it is mostly a discipline problem. Take every decision still living inside execution, move it into planning, make it with a human, and write it down where the agent will read it.

Extract Before You Execute

Extraction is real work and it takes real time. For a feature that means naming the file path, the module boundary, the class or the abstraction, the pattern, the test approach, and the interfaces it touches, before anything gets written. In finance work it means specifying the source of truth, the reconciliation rule, the rounding convention, and what an exception looks like. In knowledge work it means the audience, the claim, the evidence, and the structure.

By the time the agent starts, there is nothing left to judge. It is writing.

👉 Tip: Run a decision-extraction pass on one feature and time it. An hour of naming file locations, naming rules, class boundaries, and pattern choices usually pays back across every task in that repo after it.

Validation Gets the Same Treatment

The validation phase has the same disease and it is worth its own article. Most teams write acceptance criteria after the output shows up, which turns validation into taste. Criteria written during planning turn it into a check that a human or a second agent can run consistently.

👉 Tip: Write the validation criteria during planning, before execution starts. If you cannot state what passing looks like ahead of time, the plan is not finished and the agent is about to find that out for you.

The Volume Comes After

The clean, consistent agentic output people want is not a model capability question. It is a factory design question, and the factories that work have almost nothing left to decide by the time the machine turns on. What to write, where it goes, how it connects, what done means. All of it settled upstream, by people, on purpose.

That is the trade. You spend more time planning than you used to, and you spend almost none executing. The 10x does not come from the agent being fast, it comes from the agent never stopping to think about something you already know the answer to.

Start with the last thing an agent got wrong for you and ask what decision it was forced to make. You will find it in about a minute, and it will not be a model problem.