Does Your Workflow Actually Need an AI Agent?
Arinze
August 23, 2026
On the old road between Athens and Eleusis, a man named Procrustes kept an iron bed and a reputation for hospitality. He would invite travellers to rest for the night, and while they slept, he would measure them against the frame. The short ones he stretched on a rack until they fit. The tall ones he cut down until they fit. Every guest left the house exactly the length of the bed, which was the only thing about the arrangement that Procrustes had ever cared about.
I think about that story more than is probably healthy, because it is a precise description of how a great deal of software gets built. A founder reads that agents are the future, or that everything is RAG now, or that the entire support function can be replaced by a reasoning loop, and the technology arrives before the problem does. What follows is the stretching and the cutting. A task that was always going to be six lines of conditional logic gets wrapped in an expensive, non-deterministic loop that fails in ways nobody can reproduce. Or the genuinely messy part of the business, the part with the exceptions and the judgment calls and the angry two-year customer, gets sawn off at the ankles so it will fit inside a rigid pipeline someone built in a weekend.
Either way the product comes out shaped like the tool rather than like the work.
I have taken enough products from an idea to production traffic to have watched this from the inside more times than I would like. It is rarely stupidity. It is usually that the vendor's marketing arrived first, promising to replace a department with autonomous reasoning, and nobody mentioned the prompt that shatters the moment real users touch it, or the inference bill that quietly outruns the unit economics somewhere around month four.
Before you write a line of code, you have to understand the shape of the work. Not the shape of the demo. The shape of the work.
Start with the step, not the workflow
The most expensive mistake I see in AI product architecture is treating an entire business process as though it were a single automation problem. A workflow is almost never one decision. It is a chain of small ones, threaded through lookups, transformations, actions, and the exceptions that nobody documented because everyone already knew about them. Each of those links has its own requirements, and they are not the same requirements.
Take something as ordinary as a refund. A customer writes in asking for their money back, and the system has to read the email and pull out an order number, look up the payment and shipping status, check the request against the refund policy, decide what to do when the case falls outside that policy, write back to the customer, and finally execute the refund itself.
Six steps, and six different architectures.
Pulling an order number out of unstructured prose is a bounded cognitive task, which is exactly what a small model call is for. Looking up payment and shipping status is a database query and should never be anything else. Writing the reply benefits from a language model, because tone matters and templates read like templates. Executing the refund belongs to deterministic authorization and transaction logic, and I would fight anyone who wanted it otherwise.
Checking the request against the policy is more interesting than it looks. If the policy has been encoded into rules, it is deterministic code, and the matter is closed. If the policy exists only as three paragraphs of prose on a Notion page saying refunds are offered at the company's discretion for damaged goods, then it is not yet a rule at all, and you have a choice: do the work of encoding it, or hand the ambiguity to a model that will interpret it slightly differently on Tuesday than it did on Monday. Founders skip past this distinction constantly, because a written policy feels like a specification. It usually is not one.
Then there is the fifth step, which is where the real design problem lives. What do you do about the customer who falls outside the policy on a technicality, has been paying you for two years, and is furious? That decision may need a person. Not because software could not produce an answer, but because someone has to own the answer.
The useful question was never whether the refund workflow is human, AI, or agentic. The workflow is all three, in a particular order, and the job is to decompose it far enough that each step can be given the least autonomy that will reliably do the job.
Don't use an agent where a few lines of code will do.
The architectural spectrum
It helps to keep three architectures clearly separated in your head, because founders and vendors routinely use one word for all of them.
A deterministic workflow is a predefined code path. Every step, branch, validation, and outcome is specified at design time by a person who thought about it. Nothing is discovered at runtime.
An AI-enhanced workflow keeps that same code-controlled skeleton and drops a model into one or two specific joints, wherever unstructured data or a bounded cognitive task appears. The model never decides what happens next. It does its assigned piece of thinking and hands control straight back to the application.
An autonomous agent receives a goal, a set of tools, some context, and a loop. At runtime, it decides which tools to call, in what order, and how to recover when the world turns out differently than expected. That runtime freedom is the entire point of an agent, and it is also the entire cost of one.
These three are not rival camps, which is the part most of the discourse gets wrong. A production agent calls deterministic tools all day long. A multi-agent system can contain deterministic sub-workflows the way a company contains departments. An agent can decide to run a database query while the query itself stays as boring and predictable as it was the day it was written. One agent can delegate to another while both lean on ordinary application code for authorization, validation, calculation, and transactions.
So the question is not agents versus deterministic software. The question is where the autonomy lives. Agency belongs to the parts of the system that genuinely require dynamic reasoning and runtime path selection. Deterministic code keeps everything else, and everything else is a much larger share of a production system than the demos suggest. In the systems I have shipped, the reasoning is a minority of the execution graph rather than its substrate, and that ratio is a symptom of a healthy architecture rather than a target to aim at.
The ten dimensions
Once you have the workflow broken into steps, you can put each step through the following audit, not as a scoring rubric, but as ten questions that tend to expose where the autonomy actually belongs.
1. Path determinism: can the next step be known in advance?
Does every execution follow a path you could draw, or does the correct next action depend on something the system will only discover along the way? If the process can be expressed as rules, branches, state transitions, or a finite execution graph, deterministic code is almost certainly enough.
There is a trap here worth naming. Variability is not the same as non-determinism. A workflow can have hundreds of branches and still be entirely deterministic, as long as all of its meaningful paths are known to you. What separates the two is whether the system needs runtime path planning, and most workflows that feel unpredictable are simply large.
2. Decision density: how much judgment does the step require?
If a decision is binary, or maps cleanly onto conditional rules, keep it in ordinary code. "If transaction value exceeds $10k, flag for review" is not an agent problem. It is an if statement, and dressing it up as anything else is how inference bills start to look strange.
Some decisions genuinely require synthesizing loose context, interpreting unstructured language, resolving ambiguity, or weighing exceptions that would take thousands of rules to encode and would still be wrong. That is where a model earns its place.
But judgment does not automatically imply AI. Some decisions are too consequential, too relational, or too ambiguous to hand to software at all, and those stay with a human regardless of how capable the model gets. The question to ask is narrower than "does this need judgment?" It is: does this judgment need to be performed by software, and if it does, does it actually require probabilistic reasoning? If a single bounded model call can handle it, you do not need an agent. If deterministic logic can handle it, you do not need the model.
3. Context constructability: can the system assemble what it needs to decide?
Single-pass prompt calls work beautifully right up until the moment the decision depends on relationships. Relationships across users, organizations, permissions, histories, transactions, and systems that were never designed to know about each other. This is where context engineering stops being a buzzword and starts being the whole job.
Complex context does not automatically mean GraphRAG, whatever the current conference circuit suggests. Depending on the problem, the right answer might be relational queries and joins, metadata filtering, hierarchical retrieval, hybrid search, graph traversal, or some ugly and effective combination of them. What matters is whether the structural connections the decision depends on can be reliably recovered at all. If simple retrieval cannot recover them, you need a context layer that can represent them.
So the question is not "do I need GraphRAG?" It is "can this system reliably construct the context required to make this decision?" When the answer is no, a more capable model does not help you. It just produces a more fluent version of the same wrong answer.
4. Actionability: does the system recommend, or can it act?
There is an enormous difference between an AI that drafts an email and an AI that can send money. When the output is text or a recommendation, you have room to be flexible, because a human reads it before anything happens. The moment an agent can trigger payments, mutate databases, alter customer accounts, or fire requests at external systems, that flexibility has to be traded for control.
Tool schemas and parameter validation stop being nice engineering practice at that point. So do authorization, permission boundaries, rate limits, idempotency, and transaction validation. The model must never be the security boundary. An agent may decide which tool to call; the tool decides what that call is permitted to do. That separation matters most in multi-agent systems, where several agents share the same underlying tools and each one is a new way to reach them.
5. Error cost: what does a wrong answer cost you?
A tagging system that miscategorises a support ticket and a system that leaks one tenant's documents into another tenant's context are not on the same page of the risk register, and they should not be built with the same tolerances. This is the dimension where founders most often reason by vibes, because failure rates in an AI system feel abstract until the first one is expensive.
The practical move is to work out the cost of being wrong before choosing the architecture, and then push the critical properties outside the model wherever you possibly can. On an enterprise knowledge layer where I owned the technical build, multi-tenant privacy was existential rather than a compliance checkbox, so we rejected prompt-based access rules outright. A system prompt asking a model politely not to reveal documents is not an access control system. It is a suggestion with good manners.
What I architected instead was a deterministic query-isolation layer. Role-based access checks ran at the database query layer, before retrieval, so an unauthorized document was excluded from the result set before it could ever enter the model's context window. The model could not leak what it never received, which is a much stronger guarantee than any amount of prompt engineering can offer.
The failure mode that architecture removes is worth being precise about, because it is not the one founders usually picture. Prompt-based access rules do not fail loudly at audit time. They fail quietly in production, on some unusual phrasing nobody tested, and the answer that comes back looks completely normal. Nobody notices until a customer sees a document belonging to another company. For a product whose entire proposition is that enterprises can put their internal knowledge into it, that is not a bug to be patched in the next sprint. It is the end of the contract, and probably of the reference.
The commercial consequence was that the founder could demo the live product to 25 enterprise leads by week three and answer any question they asked of it, because no phrasing existed that could pull a document the viewer was not entitled to see.
Enforce your critical safety properties outside the model whenever you can. Models are probabilistic by construction, and you cannot make a probabilistic component into a guarantee by asking it nicely.
6. Reversibility: can the action be undone?
Drafting an email is reversible. Tagging a database row is reversible. Sending an invoice to a customer, deleting records, or moving money frequently is not.
The less reversible an action is, the less autonomous authority the system should hold over it. For genuinely irreversible actions the pattern that works is to let the agent plan, prepare, and validate, while deterministic controls and, where the stakes justify it, a human approval gate own the execution. This is not an argument for putting a person in front of every tool call, which would defeat the purpose of building the thing. It is an argument for drawing a control boundary around the small number of actions where a mistake cannot be walked back.
7. Observability: can you reconstruct what happened and why?
Every production system needs observability. The real question is how much traceability this particular workflow demands. If an outcome is easy to verify on its own, execution logs may be plenty. If an auditor is going to ask why a specific loan was declined or why a particular customer account was modified eight months ago, you need something considerably richer.
That means being able to reconstruct which tools were called, what inputs they received, what data was retrieved, what actions were executed, which authorization and policy checks passed, and what the final outcome was. This is agent observability, and it is not the same thing as logging chain-of-thought. You do not need to persist a model's private reasoning to make a system auditable, and treating that reasoning as an explanation of behaviour is its own mistake. What you need is a structured record of inputs, actions, decisions, and outcomes.
8. Evaluation: can you tell when it is wrong?
Before you give a system more autonomy, you need a reliable way to detect that it has started misbehaving. For some problems this is easy. Code passes its tests, or it does not. Retrieval results can be scored against a curated dataset. A calculation can be validated, a tool call checked against a schema, a handoff compared to an expected outcome. For others, success is genuinely hard to define, and that difficulty is itself a signal about how much autonomy the step should be granted. Autonomy without evaluation is guesswork wearing a lab coat.
On a support platform where retrieval and answer precision were core business metrics rather than engineering vanity, I built a CI-gated evaluation harness. Every commit ran against a curated golden dataset scoring retrieval precision, recall, and handoff correctness. When a vector database migration quietly degraded search accuracy, the harness caught it before the change could merge. The regression never reached production, and the founder got the incident and the fix in the same message from me.
The more autonomy a system has, the more it needs an evaluation loop capable of telling you it has changed. Otherwise you find out from a customer, which is the most expensive possible monitoring system.
9. Human intervention: where does a person need to stay in control?
Some decisions should not be automated merely because they can be. People will happily let software decide almost anything until the decision becomes personal or high-stakes, at which point they want a name attached to it. A refund exception, a sensitive employment decision, a consequential legal judgment: these want a person who can actually own the outcome.
Human-in-the-loop does not have to mean someone reviewing every successful execution, which is how these systems die of process. The pattern that works is selective escalation. On the same support system, we avoided what I call the God Agent trap, where one model is handed every query and starts confidently improvising on the ambiguous ones. Instead, we built the handoff around retrieval confidence. If confidence dropped below a validated threshold, the ticket went to a human in the same inbox, and the user never had to receive a broken guess dressed up as an answer before they could reach a person.
The objective is not to eliminate human intervention. It is to keep humans where judgment and accountability genuinely live, and out of the places where they are just doing a computer's job slowly.
10. Economics: does the autonomy pay for itself?
Agentic systems bring additional inference calls, latency, infrastructure, monitoring, evaluation, and failure handling. All of that is straightforwardly worth it when the system displaces hours of expensive manual work. It is much harder to justify on a high-frequency operation that deterministic code could finish in milliseconds. If you are triaging millions of events, an open-ended reasoning loop on every event is the wrong architecture, and the bill will tell you so eventually.
On a natural-language strategy extraction project for a financial backtesting engine, we rejected an open-ended agent entirely and kept the in-sample and out-of-sample datasets physically separated. What we built instead was a structured parser validated by a 73-case regression suite, checking every output against trailing stop-loss logic, crossing-entry bugs, and look-ahead bias. It produced zero false encodes across every live trader strategy we classified.
That was not a failure to use AI. It was a decision to use less autonomy because less autonomy was the better engineering answer, and the founder got a system whose failure modes were enumerable.
The diagnostic sheet
Dimension | Prefer deterministic / AI-enhanced | More autonomy may be justified
-----------------------------|---------------------------------------------------|-----------------------------------------------------------
1. Path determinism | The process follows a known execution graph | The next action depends on runtime discovery
2. Decision density | Decisions are binary, rule-based, or bounded | Requires dynamic reasoning across uncertain conditions
3. Context constructability | Required context is easily queried or retrieved | Requires traversing connected information dynamically
4. Actionability | Read-only or tightly bounded actions | The agent must select and execute multiple actions
5. Error cost | Mistakes have limited commercial impact | Mistakes carry financial, legal, or security consequences
6. Reversibility | Actions are easily undone | Actions are difficult or impossible to reverse
7. Observability | Basic execution visibility is sufficient | Detailed decision and execution traces are required
8. Evaluation | Success can be reliably measured | Autonomy is viable only if failure is still detectable
9. Human oversight | No meaningful human judgment is required | Judgment or accountability requires escalation
10. Economics | High volume, low margin, low latency | High-value work where extra inference cost is justified Nothing here is a scoring system where four items on the right entitle you to build an agent. It is a diagnostic. The more a step depends on dynamic reasoning, runtime discovery, and autonomous action, the stronger the case for agency. The more it is predictable, high-volume, security-sensitive, or expressible as a rule, the stronger the case for code. And often enough the honest answer is that the step belongs to a person, which is a legitimate architectural decision rather than an admission of defeat.
Build the workflow
Somewhere in the middle of all this is the founder I keep meeting, who has already chosen the framework and is now quietly reshaping the business to suit it. The support process gets simplified because the agent cannot handle the exception. The pricing logic gets flattened because the tool struggles with the edge case. Nobody decides to do this. It happens one small concession at a time, and by the end the product is exactly the length of the bed.
Start instead with workflow decomposition. Break the process into its meaningful steps and work out which decisions are deterministic, which want a bounded model call, which genuinely need dynamic agentic reasoning, and which should stay with a person who can be accountable for them.
A multi-agent system follows the same principle rather than escaping it. You can have an orchestrator coordinating several agents, those agents dynamically selecting tools, and those tools executing deterministic database queries, API calls, calculations, authorization checks, validations, and transactions. The agents supply the autonomy. The tools supply the control. That is not a contradiction; it is what good architecture looks like when it is doing its job: agency where dynamic reasoning creates value, determinism where predictability protects you.
Procrustes never once asked whether a traveller needed a longer bed or a shorter one. He had the bed he had, and everyone got fitted to it. Do not build your product that way. Pull the workflow apart and let each step earn its own architecture.
This is the kind of engineering ownership I bring to a product as a technical partner to founders: the business first, the constraints second, and the technology third, with unnecessary MVP scope cut before it hardens into engineering debt. If you are a funded founder building an AI product and you want someone who will take real ownership of making the technology work in production, let's talk.
Written by
Arinze
arinze@arinze.dev