我们对 Agentic AI 的偏好——面向企业架构师的框架

Enterprise Ai Engineering Rule Based System Enterprise Ai Strategy Agentic Ai Our Bias Toward Agentic AI — A Framework for Enterprise Architects When NOT to Use Agentic AI: A Decision Framework for Enterprise Architects Sandeep Chaudhary 7 min read · Just now -- Listen Share Press enter or click to view image in full size In most enterprise reviews, I see the same pattern. A workflow is presented. Someone asks: “Can we make this agentic?” Technically, the answer is almost always yes. But feasibility isn’t the same as correctness. Too often, we skip reviewing the other options — rules engines, deterministic logic, well‑structured automation — that are more feasible, more auditable, and often more effective. The better question — should we — rarely gets asked. And that gap is where a lot of enterprise AI complexity is being created right now. Agents built for processes that never needed them. Systems that are slower, harder to audit, and more expensive than the automation they replaced. So let me say the quiet part out loud. Not every workflow needs an agent. The Autonomy Trap Here is where I see the mistake — and it is more dangerous. The team identifies the right use case. They build the agent. Then they give it unlimited autonomy. The agent investigates the invoice discrepancy, determines the likely cause — and autonomously approves the payment. Or rejects it. Or raises a dispute with the supplier. Before any of that happens, the right question is: what is the cost of a wrong decision here, and can it be undone? I use four dimensions to set the autonomy boundary before writing a single line of agent code. Risk — what is the potential downside of a wrong decision? Reversibility — how easily can it be undone? An internal notification is reversible. A settled payment is not. Business impact — what is the financial, operational, or reputational consequence? Confidence — how certain is the agent’s reasoning? Clear evidence trail or multiple plausible interpretations? Map these before deciding: does the agent act, or does it recommend and wait for a human? Low risk. Reversible. Low value. High confidence → autonomous action. Medium risk. Medium reversibility. Low confidence → human approval. High risk. Irreversible. Any confidence → human approval. Always. The goal is not to maximize autonomy. The goal is to maximize useful autonomy within a controlled risk boundary. THE ARCHITECTURE This decision framework maps directly to how I structure the system. Press enter or click to view image in full size What We Are Blind To — We Ignore the options When we are biased toward agents, we stop seeing the options. Rules engines Most enterprise processes that are being converted to agents could be handled by a well-structured rules engine. Fixed inputs. Encoded logic. Predictable outputs. Cheaper to run, faster to execute, fully auditable, and provably correct for the cases they cover. The limitation is real — rules do not handle ambiguity. But the answer to “can a rules engine handle this?” should be the first question asked, not an afterthought once the agent is already half-built. Traditional automation and RPA Robotic Process Automation had a bad decade of unrealistic expectations and brittle implementations. But for structured, repetitive, high-volume workflows — it remains effective. An invoice that always arrives in a known format, from a known vendor, with a predictable structure, does not need an LLM to process it. The cost per transaction is a fraction of what you pay for inference. Fine-tuned or specialised models A general-purpose LLM with tools is not always the right answer. For specific, bounded tasks — classification, extraction, scoring, translation — a smaller fine-tuned model can outperform a general agent at a fraction of the cost and latency. The agent architecture’s flexibility is a liability when you do not need flexibility. Traditional ML For prediction tasks with structured data, gradient-boosted trees still outperform LLMs in many enterprise contexts. Credit scoring. Demand forecasting. Fraud detection on structured transaction data. The defaults matter here. Reaching for an LLM agent when XGBoost + a confidence threshold does the job is not innovation. It is over-engineering with extra steps. Simple APIs and integrations Some “AI” use cases are really just integration use cases in disguise. The information exists somewhere. It just needs to be queried and surfaced. You do not need an agent to query an ERP and return a purchase order status. You need an API call and a well-formatted response. None of these are inferior options. They are appropriate options for specific contexts. When we stop seeing them, we stop being architects. We become advocates for a particular tool. Start with Deterministic Automation Before I even think about an agent, I ask one question. *Can I write this as a rule?* Fixed input. Fixed logic. Fixed output. If the answer is yes — use traditional automation. Full stop. Invoice amount matches the PO → approve it. Stock drops below threshold → trigger replenishment. Get Sandeep Chaudhary’s stories in your inbox Join Medium for free to get updates from this writer. Subscribe Subscribe Remember me for faster sign in New employee created → provision standard access. These are deterministic processes. The input is known. The logic is encodable. The output is predictable. An RPA tool, a rules engine, a simple workflow — any of these handles it faster, cheaper, and more auditably than an LLM ever will. When you put an agent on a deterministic process, you are paying for LLM inference, token cost, probabilistic behaviour, and explainability overhead — and getting zero benefit in return. The first question before building any agent: could a well-written if-else tree handle this? If yes, write the if-else tree. When an Agent Actually Earns Its Place An agent starts making sense when the process has something a rule cannot encode. I look for six signals: Ambiguous input. The information arriving is unstructured or needs interpretation. A supplier email. A handwritten delivery note. A complaint referencing a clause without naming it. Multiple investigation paths. What you do next depends on what you find. The path forks based on evidence, not a fixed sequence. Unstructured information. The relevant context lives in documents, emails, contracts — not clean API responses. Dynamic tool selection. The agent decides which systems to query and in what order. No fixed sequence exists. Contextual reasoning. The right answer depends on history, patterns, relationships — things no rule can pre-encode. Exceptions that cannot be expressed as rules. The edge cases are too numerous, too varied. Every attempt to enumerate them creates more exceptions. Here is the difference in practice — and I have seen both sides of this in procurement. Scenario A — Invoice matches PO exactly Amount correct. Line items match. Vendor correct. Approve it. No agent required. This is a deterministic process. Scenario B — Invoice does not match PO Now things get interesting. Was the GRN raised? Does the contract allow price variation? Is this vendor historically reliable? Was there a change order nobody captured? Is the discrepancy within tolerance? Does policy require director approval above a certain value? Each answer changes the next step. You cannot encode this as a rule. You need something that can investigate, reason across multiple systems, accumulate evidence, and produce a recommendation with the reasoning visible. That is where an agent earns its place. The Agentic Tax When you build an agent where simpler automation would have worked, you pay a tax. Cost You pay it in cost. LLM inference is expensive per call. An agent that makes twelve tool calls to resolve a query that a rules engine would handle in one evaluation is paying twelve times the inference cost, plus orchestration overhead. Latency You pay it in latency. Agentic reasoning takes time. A deterministic rule executes in milliseconds. A multi-step agent reasoning through the same decision takes seconds, sometimes tens of seconds. For high-volume operational workflows, this adds up. Reliability You pay it in reliability. Rules are deterministic. Agents are probabilistic. The same input does not always produce the same output. For regulated industries — BFSI, healthcare, anything with audit requirements — probabilistic behaviour in operational decisions is a governance problem, not just a technical one. Explainability You pay it in explainability. When an agent approves or rejects a transaction, you need to explain why. An agent’s reasoning trace is better than a black-box model, but it is still harder to audit than a decision that was made by a rule you can read in a policy document. Operational complexity You pay it in operational complexity. Agents fail in ways that rules engines do not. Model drift. Context window pressure. Tool schema changes that break the agent’s ability to call a downstream system correctly. Retrieval quality degradation in RAG components. Each of these is a new class of failure that your operations team needs to learn to detect and remediate. This tax is worth paying — when you need what an agent provides. When you do not, it is waste that gets embedded into your system’s cost structure, and it compounds. How This Plays Out Across Domains Procurement Exact match invoices, standard tolerances, routine approvals under threshold → deterministic layer. Mismatches, missing GRNs, contract variance, supplier exception history → agent. Anything above threshold, confidence below 0.75, anything touching contract interpretation → human approval. Retail Customer Service Standard refunds under policy threshold, known fault codes, straightforward resolutions → deterministic. Complex complaints across multiple interactions, ambiguous fault attribution, cross-system investigation → agent. Compensation above policy limit, any legal or regulatory language → human approval. BFSI Credit Clear approvals (high score, complete data) and clear declines (very low score, obvious default pattern) → deterministic. Boundary cases, incomplete data, conflicting signals → agent. All declines → mandatory human review, every time. Denials carry the highest ethical and regulatory stakes. THE POINT The question I want enterprise architects to ask is not: how do we make this workflow agentic? It is: at which point in this workflow does agentic reasoning add value that deterministic automation cannot — and what is the right level of autonomy at that point? The answer, in my experience, is almost always: later in the workflow than you initially thought, and with less autonomy than you originally planned. The goal is not to maximize autonomy. The goal is to maximize useful autonomy within a controlled risk boundary. That boundary is not a constraint on what AI can do. It is the mechanism by which your organization stays in control of what AI is allowed to do — until the evidence justifies giving it more.