Problem Solving and Agentic Systems
Agentic architecture should emerge from requirements, the way any architecture should. Do not start with a multi-agent system; start with one deterministic workflow and ask, at each step, why it is insufficient. The answer names the one place an agent is needed — or finds that none is.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Someone wants the store's support assistant to be "agentic". How does the loop get from that word to a workflow with a reason for every non-deterministic step, and what does it hand to the agentic-engineering domain?
The founder wants an assistant that handles support: answers questions about orders, processes returns, escalates when needed. The diagrams for this have a planner agent, a retrieval agent, a tools agent and a supervisor, and a framework that provides all four. You could stand it up this week. You cannot say which step in "handle a return" actually needs a model to decide anything.
Start from the multi-agent architecture. It is what "agentic" looks like, the framework makes it a configuration file, and a supervisor coordinating specialists is how the problem would be organised if it were a team. Standing it up produces something that demonstrably talks.
Every step is non-deterministic, including the ones that were never in doubt. Looking up an order by number is a database query; in the multi-agent version it is a model deciding to call a tool, sometimes with the wrong number. The determinism the problem had was thrown away (Deterministic Evaluators in the agentic domain is where it comes back).
- Every step is non-deterministic, including the ones that were never in doubt. Looking up an order by number is a database query; in the multi-agent version it is a model deciding to call a tool, sometimes with the wrong number. The determinism the problem had was thrown away (Deterministic Evaluators in the agentic domain is where it comes back).
- Failures cannot be attributed. When a return is processed wrongly, four agents and a supervisor were involved, each with a prompt, and the trace shows a plausible conversation with a wrong outcome somewhere in it.
- The requirements — never refund more than was paid, never process a return outside the window, always escalate a complaint about a charge — were never written as rules, so they are enforced by prompts, which is to say by hope (Invariants: Name It Before You Lock It belong in code).
- Cost and latency are what a multi-step model conversation costs, for every request, including the ones a query would have answered in milliseconds and for free.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Start from one deterministic workflow: the steps a human support agent follows, written as a flowchart with decisions. Look up the order; check the return window; check the item is returnable; create the return; issue the refund; confirm. Every step is code or a query, and every decision is a rule. This is the baseline, the same way a rule is the ML chain's baseline, and most of the workflow stays this way.
- At each step, ask why the deterministic version is insufficient. The honest answers are few: the input is natural language and must be understood; a decision genuinely requires judgment the rules cannot express; the next step depends on information only available by reading unstructured content. Where none applies, the step stays deterministic. Where one does, that step — and only that step — gets a model, with a contract around it (The Why Ladder).
- Let the architecture emerge from the count. One step that needs a model is a workflow with an LLM call in it. Several independent ones is a workflow with several calls. A loop of observe-decide-act with tools is a single agent. Multiple agents are justified when there are genuinely separate loops with separate contexts and a reason they cannot share one — and that reason has to be written down (Architecture From Requirements).
- Hand off at the emerged shape. The agentic domain teaches the agent loop, tool contracts, workflow state graphs, guardrails and evaluation; each is the depth behind one shape, and the chain says which shape the requirements produced.
From workflow to shape
The pipeline is the move as steps. It starts from a workflow with no models in it and ends with a shape named by the count of steps that needed one. The agentic domain owns every shape's internals; this domain owns the count.
- 1Human workflow
Steps and decisions in plain English; every decision a rule where a rule can be stated.
fails by Starting from the agent diagram.
- 2Deterministic implementation per step
One line each: a query, a comparison, an API call. Steps with a line are done.
fails by Every step given to a model "for flexibility".
- 3Why insufficient?
One honest sentence per step that has no line: free text in, judgment the rules cannot express, unstructured content to read.
fails by Sentences written to fit the diagram.
- 4Invariants in code
Rules that run regardless of any model's output — refund bounds, windows, mandatory escalation.
fails by Invariants in prompts.
- 5Count → shape
One step: a call in a workflow. A loop with tools: one agent. Separate contexts with a written reason: routed agents.
fails by The supervisor drawn before the count.
On the returns workflow the count is one, and the shape is a workflow with a call at the front. That is the usual result on a store, and it is the honest half of the lesson.
"We need a multi-agent system", down the ladder
The claim, walked down to its requirement. The ladder ends with the simpler thing that meets it, and with the case where the claim was right after all — because the device exists to distinguish the two, not to rule against the claim.
“We need a planner, a retrieval agent, a tools agent and a supervisor for the support assistant.”
- ↓Why multiple agents? So each can specialise — one understands the request, one finds the order, one acts.
- ↓Why does finding the order need an agent? Because the customer's message has to be understood first to know which order — the finding itself is a query once the number is known.
- ↓Why does acting need an agent? It does not, once the intent and order are known: the return window, the item flag, the refund are rules and calls. The only judgment is at the front, understanding the message.
the claim was right when When the assistant handles several domains whose tools carry different permissions and whose contexts must not mix — a complaint handler that must never see refund tools — and the reason is written down. Then a deterministic router in front of separate bounded agents is the shape the requirements produced, and the multi-agent claim was right for a reason nobody drew (When Not to Use Multi-Agent is the reading before that decision).
The order of building, and the other order
Once the shape is named, the order below builds the returns assistant so that the deterministic majority is proven before the model step is trusted. The alternative is for the case the contested scope describes, where the workflow cannot be enumerated.
- 1The deterministic workflow, driven by a structured request with no model
because Proves the rules, the invariants and the API calls with attributable failures, before any non-determinism is added (The Walking Skeleton).
- 2The invariants, as code with tests
because They must hold regardless of what the model later produces; testing them now means the model step cannot break them later.
- 3The model step, with its contract and an "unclear" path
because One bounded piece of non-determinism, evaluated on a set of real messages against the structured output it must produce.
- 4The human fallback for "unclear"
because The model step will fail on some messages; the fallback is what makes that a routing outcome instead of a wrong refund.
- 5Evaluation on real traffic, then the next model step only if a why-sentence appears
because The shape grows by count, and the count grows only with a written reason (Add Complexity Only When Required).
How to do it
Most important first.
- Write the workflow a human would follow, as steps and decisions, in plain English. Mark each decision as a rule if a rule can express it (Finding the State Machine).
- For each step, write the deterministic implementation in one line — a query, a comparison, an API call. If you can, that step is done.
- For each step you could not write deterministically, write why in one sentence. If the sentence is "it would be more flexible", the step stays deterministic. If it is "the input is free text" or "the rule cannot be stated", it gets a model.
- Write the invariants as code that runs regardless of what any model decides: refund never exceeds payment; return never outside the window; charge complaints always escalate (What Must Never Break).
- Count the model steps and name the shape. Then read the agentic domain's lesson for that shape — and its "when not multi-agent" lesson before any supervisor is drawn.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Returns, run through the move. Human workflow: read the message; find the order; check the window; check the item; create the return; refund; confirm. Deterministic check per step: find the order — a query, given an order number; check the window — a date comparison; check the item — a flag on the product; create, refund, confirm — API calls. Insufficient where? Only the first step: the customer's message is free text, and the order number and intent have to be extracted from it. One model step, with a contract: input the message, output a structured intent and order reference or "unclear". Invariants in code around everything after. Shape: a deterministic workflow with one LLM call at the front. No agents, no supervisor, and the framework is not needed (Option 0: No Framework).
- The documentation assistant, where the shape is an agent. Human workflow: understand the question; find relevant passages; compose an answer; cite. Deterministic check: finding passages is retrieval — deterministic given a query; composing an answer from passages is generation — a model; but the question often needs a follow-up search after reading the first results, which is a loop of retrieve-read-decide. Insufficient where? The loop's decision — "do I have enough to answer?" — is judgment on unstructured content. Shape: a single agent with one tool, bounded by a step limit and a budget. Still no supervisor (Single Agent).
- Where multiple agents emerged. The support assistant grows to handle returns, order questions and complaints, each with its own tools, context and invariants, and the contexts cannot share a window without confusing each other. The why for separation is written: different tool sets with different permissions, and a complaint context that must never see refund tools. Shape: a deterministic router in front of three single agents, each bounded. The supervisor pattern arrived last, from a requirement about permissions, not first, from a diagram (Supervisor Pattern is then the reading).
How you know it worked
What now exists that did not before, and what question you can now ask.
- A deterministic workflow exists on paper, and most of its steps have a one-line implementation that is not a model.
- Every model step has a written sentence saying why the deterministic version was insufficient, and none of the sentences is "flexibility".
- The invariants are code that runs regardless of model output.
- The architecture has a name that came from counting model steps, and the count is small.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What is the workflow a human would follow, as steps and decisions, and which decisions are rules?
- ?For each step, what is the one-line deterministic implementation — and where I cannot write one, why exactly not?
- ?Which invariants must hold regardless of what any model decides, and are they code?
- ?How many steps need a model, and what shape does that count produce — a call, a workflow, one agent, or a routed set with a written reason?
What can go wrong
- Determinism is enforced where the input really is free text, and the "workflow" is a form the customer has to fill in. The chain removes unjustified model steps; it does not remove justified ones.
- The why-sentences are written to justify the diagram: "understanding the return window requires judgment" for a date comparison. Honest sentences or none.
- The single model step is given the whole workflow "since it is there". The step has a contract — input, output, failure — and the workflow around it stays code.
- Multiple agents are refused on principle when the permissions requirement genuinely separates contexts. The chain reaches multiple agents sometimes; the point is the written reason.
- The deterministic workflow is less impressive in a demo than the multi-agent one; it handles a return correctly and quietly, which is what the founder asked for and not what they pictured.
- Writing the why-sentences forces disagreement with whoever drew the diagram, and the disagreement is about their design, not about a requirement.
- A workflow with one model step needs the contract around that step built and tested — structured output, an "unclear" path, a fallback — which the multi-agent version hid inside prompts.
- "So never build multi-agent systems." Build them when the count and the written reasons produce them; the support assistant reached three agents for a permissions reason. The chain forbids starting there, not arriving there.
- "Deterministic means no model anywhere." It means every model step has a reason and a contract; the returns workflow has one, at the front, and is still deterministic everywhere else.
- "This is agentic engineering." It is the step before: deciding which shape the requirements produce. The loop, the tools, the guardrails and the evals are the agentic domain's and are linked, not restated.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALArchitecture emerging from requirements is the same rule as in system design; agentic systems are the case where the reflex has a framework and a diagram ready before the requirement exists, and where each unjustified step costs money per request.
- CONTESTEDA credible opposing view: for genuinely open-ended tasks — research, multi-step troubleshooting, anything where the steps cannot be enumerated in advance — starting from a deterministic workflow is a category error, because the workflow cannot be written, and the honest baseline is a single capable agent with tools. Proponents argue that the "start deterministic" rule quietly assumes the task is a process, that many valuable tasks are not, and that for those the right first move is a bounded agent with good evals rather than a flowchart that will never be finished. The view is strongest where the human workflow itself is exploratory.
- ILLUSTRATIVEThe returns workflow, the documentation assistant's loop and the three-agent support system are invented to show the shape emerging from a count; no real product is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The agentic domain's "when not multi-agent" and "no framework first" lessons are the depth behind this chain; arrive with the workflow and the count, and the shape has a reason.