The Three Constraining Forces for Agentic AI Design

Most enterprise AI deployments today are assistants. They respond, summarise, and classify. A human asks, the AI answers, and a human decides what to do with the answer.

Agentic AI is different. Agents do not just respond — they act. They plan sequences of steps, call tools, read systems, write records, send communications, and trigger downstream processes, sometimes without a human approving each individual decision.

This makes three things — which were already true of AI — significantly more consequential. These are not new discoveries. Probabilistic output, consumption-based cost, and evolving models are all familiar properties of modern AI systems. What changes in an agentic context is the consequence of each one, and the design discipline each one requires.

Force 1: Probabilistic output, amplified by action

AI systems produce probabilistic output. The same input can yield different outputs, and fluent language is not a dependable indicator of correctness. Models do not reliably know when they are wrong.

In a response-only workflow, a wrong answer is often contained. A human sees it, catches it, and nothing has happened yet.

In an agentic workflow, a wrong answer can become the beginning of an action chain.

Consider a representative enterprise scenario. A logistics company deploys an AI agent to handle incoming customer complaints. The agent reads each complaint, classifies it, sends an acknowledgment, and routes it to the appropriate team automatically.

A customer writes in about a shipment that arrived damaged. The message is brief and does not explicitly use the word “damaged.” The agent interprets it as a standard delay complaint and acts: it logs the case as a delay, sends an acknowledgment promising resolution within five days, and routes it to the general queue.

By the time a human looks at the case, three things may already have happened in the wrong direction. The customer has a written commitment that does not match the situation, the case is in the wrong queue, and the SLA clock is running on the wrong terms.

The agent was not broken. It was wrong. And because it acted rather than responded, the error entered the workflow before anyone could catch it.

This is a plausible and well-understood failure pattern in agentic customer service workflows. The risk is not theoretical.

What to do about it. The answer is not to slow the agent down across the board. It is to design consequence-aware gates. In this logistics example, the agent should classify and propose an action, but any case where the classification is uncertain — or where the action has an external, customer-facing effect — should route to a brief human review before the acknowledgment goes out. The agent can handle a high share of routine cases automatically, while edge cases with real consequence get a checkpoint. The design question: if this agent’s reasoning is wrong, how many actions will it have taken before a human can intervene?

Force 2: Consumption-based cost, multiplied by steps

AI usage is typically billed per token processed — input and output — for each model call. Most teams understand this for simple LLM workflows.

Fewer have thought it through for agentic ones.

An agent completing a multi-step task does not make one model call. It often makes many: planning, calling a tool, reviewing the result, deciding the next step, calling another tool, evaluating progress, and finalising output. Each of those reasoning steps can trigger another billed interaction.

Consider another representative scenario. A finance team deploys an AI agent to prepare monthly supplier payment summaries. In testing, using clean structured data, the agent produces each summary in three steps. The test cost is small. The business case looks strong.

In production, the data is messier. Invoices arrive in different formats. Some have missing fields. Some contain inconsistencies that require the agent to re-read source data and reconcile before proceeding. The agent does exactly what you want a careful agent to do: it checks its work. What took three steps in testing may take nine or ten in production.

The cost increase may be far higher than the test estimate — not because the agent failed, but because it had to work through imperfect data in a realistic operating environment.

The consumption model for agentic AI does not just scale with data volume. It also scales with data quality, task complexity, and the number of reasoning steps the agent takes to reach a usable output. In agentic workflows, all three variables are often higher than they appear in a pilot.

What to do about it. Build the cost model from production-realistic conditions, not clean test data. During the pilot, measure actual step counts per task on real data, not sample data. In this finance example, a practical fix is a two-stage design: use a lightweight extraction step to structure and clean invoice data first, then pass structured inputs to the main agent. The agent spends fewer steps managing data quality and more steps on actual analysis. Track step count per task as a production metric, because a rising average can signal data quality degradation before the cost impact becomes obvious.

The design question: how many model calls does this agent actually make per task completion in production conditions, not in testing?

Force 3: Evolutionary models, now controlling behaviour

Model providers update, improve, and deprecate their models continuously. Those changes can alter how a model behaves on your specific data and prompts, even when your own application code has not changed.

For a response-only workflow, this is mainly a quality problem. The answers shift, users notice, and trust erodes gradually.

For an agentic workflow, this becomes a behaviour problem — and it is harder to detect.

In a response system, the model produces output and a human decides what to do with it. If the model’s output changes, the human is still in the decision loop.

In an agentic system, the model helps determine which tools to call, in what sequence, under what conditions, and when to stop. A model update can change how the agent interprets situations, weighs information, or decides that a signal is significant enough to act on. The agent may start routing differently, escalating less frequently, or treating certain signals as less important than it did before.

None of this necessarily produces an error. None of it necessarily triggers an alert. The system may appear healthy while the workflow is behaving differently from how it was originally designed and tested.

Consider a representative scenario. A professional services firm deploys an AI agent to draft client project status updates. The agent reads task logs, identifies progress and risks, and produces a structured update for the project manager to review.

Months after deployment, the model provider issues a routine update described as an improvement. The firm’s code is unchanged. What changes is how the model interprets and weighs language in project logs. Under the updated model, the agent reads the same signals differently and flags fewer situations as risks. The updates look cleaner, and project managers may not notice immediately.

Weeks later, a client escalates an issue that had been visible in the underlying data earlier. The agent had seen the data, but under the updated model behaviour it no longer surfaced it in the same way. Nobody realized the agent’s behaviour had shifted, because nobody had a mechanism to check.

What to do about it. Build a fixed evaluation set using historical examples where the correct flags are already known. Run this evaluation set against the live agent on a regular schedule and after meaningful model changes. Compare the results to the baseline captured when the workflow was first approved. That gives you a way to detect behavioural drift before it turns into an operational issue.

The design question: if your model provider issued an update last month, do you have a mechanism to know whether your agent is still behaving the way you designed it to?

Why these three forces demand a new design discipline

The solutions above — consequence-aware gates, production-realistic cost modelling, and evaluation baselines — are not ad hoc fixes. They are answers to specific design questions that every agentic workflow needs to address before deployment.

And they are not the only questions.

Agentic AI workflows require a set of design questions that traditional software delivery did not have to ask in the same way. Questions about what the agent is permitted to access and do. Questions about whether human review is meaningful or merely ceremonial. Questions about whether behaviour is being continuously measured or simply assumed to remain stable.

These six questions form the design delta for enterprise agentic AI:

1. Is this the right workflow for AI, given what happens when it is wrong?
2. What does this workflow truly cost to run at production scale, with real data and realistic step counts?
3. How is the agent’s behaviour designed so that its outputs are reliable, grounded, and correctly routed when uncertain?
4. What is the agent permitted to access and do — and what requires explicit human approval before it acts?
5. Is the human oversight in this workflow genuine, or is it a signature on something already done?
6. How will you know, six months from now, whether the agent is still behaving the way you designed it to?

These are the questions being addressed systematically through a framework called BEACON, built specifically for enterprise AI workflow design.

Sai Krupa Sagar is an Advisor on Enterprise AI Systems focusing on successful use of AI in enterprise scenarios