Agentic Workflows in the Enterprise: Open-Ended vs. Bounded Autonomy

One of the more useful lessons I learned while designing an agentic workflow came from something that initially looked perfectly reasonable. We had a business workflow containing a mix of deterministic processing and AI-driven reasoning, and at one point we allowed the outcome produced by an LLM-driven agent to determine what the workflow should do next.

The thinking was straightforward. The agent had the context, could analyse the available information and arrive at a conclusion, so why not use that conclusion to determine the next step?

The problem became visible when we tested the workflow repeatedly. Given substantially the same context, the agent did not always arrive at exactly the same decision. There was nothing particularly surprising about this behaviour. LLMs are probabilistic systems, and some variation in their responses is inherent to how they operate. The architectural mistake was not in expecting the LLM to reason; it was in allowing probabilistic reasoning to become part of the control logic of a business workflow that expected predictable behaviour.

That experience changed the way I started thinking about autonomy. Instead of asking how much an agent could do, I started asking a different question: what should an agent actually be allowed to control?

Autonomy Is About Decision Authority

We often associate autonomy with the freedom available to an agent. Can it call tools, decide which tool to use, invoke several tools in sequence, or change its approach based on what it discovers? These are useful measures of capability, but from an enterprise architecture perspective, they do not tell us enough.

A more useful way to think about autonomy is in terms of decision authority. Who decides what happens next? Who owns the transition from one business state to another? At what point does the agent's authority end and control return to the surrounding system?

Consider an invoice that has entered an exception workflow because the invoiced amount does not match the purchase order. We could give an agent a broad objective such as resolve this invoice exception. The agent might retrieve the purchase order, inspect goods-receipt information, analyse supplier correspondence, examine previous transactions and gather whatever supporting evidence it believes is necessary. After analysing the information, it might conclude that the discrepancy is legitimate and decide that the invoice should continue processing.

There is considerable power in this model. The agent can adapt its investigation to the situation, reason over unstructured information and follow paths that were not explicitly modelled in advance. But there is also an important architectural consequence: the LLM is no longer merely providing intelligence to the process. Its probabilistic reasoning is now influencing the business transition itself.

That is where open-ended autonomy becomes an enterprise architecture concern.

Bounded Does Not Mean Predetermined

Now consider the same invoice and the same agent, with access to exactly the same tools and information. It can still decide how to investigate the exception. It might retrieve the purchase order first, examine the goods receipt, read supplier correspondence, discover that additional evidence is required and revise its initial hypothesis. There is no reason for the workflow to prescribe that investigative sequence in advance.

What changes is the responsibility given to the agent. Instead of asking it to resolve the exception, we ask it to investigate the exception and return its findings. It might conclude that the purchase-order variance is 3.2 percent, that the goods receipt has been confirmed and that the available evidence supports treating the case as a tolerance exception. Control then returns to the workflow, where explicit business policy determines what happens next.

The intelligence has not disappeared, nor has the autonomy. The agent still has considerable freedom in how it performs the work entrusted to it. What has changed is where its authority ends.

This distinction matters because bounded autonomy can easily be mistaken for rigid, predetermined execution. An agent may have twenty tools and dynamically determine which ones it needs and in what sequence to use them, while still operating within a carefully designed boundary. Conversely, an agent may have only two possible actions—approve and reject—but if its probabilistic reasoning directly determines a consequential business outcome, it may have been given much greater authority.

The boundary, therefore, is not necessarily around the reasoning path. It is around the authority delegated to the agent.

Use LLMs Where Intelligence Adds Value

There is another aspect of this design that I believe is equally important. Suppose our invoice policy is explicit: if the variance is within 5 percent and the goods receipt is confirmed, continue processing; otherwise, escalate for review.

We could put that rule into the agent's prompt and ask the LLM to return CONTINUE or ESCALATE. The agent would still be bounded because the enterprise has defined both the rule and the permitted outcomes. But that raises a different question: why use an LLM to perform work that is already deterministic?

A rule such as “variance is less than or equal to 5 percent and goods receipt is confirmed” does not require intelligence. Traditional software can evaluate it reliably, quickly and inexpensively. Moving that rule into an LLM prompt does not make the system smarter; it introduces probabilistic execution into something that was deterministic to begin with.

The value of an LLM lies elsewhere. It can read a supplier's explanation for the invoice discrepancy, interpret the context, correlate it with supporting documents, identify inconsistencies and determine whether the evidence supports the supplier's claim. Those are problems involving ambiguity and reasoning, and they are exactly where LLMs can add significant value. Once the reasoning produces structured findings, conventional software can evaluate explicit thresholds and control the next business transition.

There is an efficiency argument here as well. Every unnecessary LLM invocation consumes tokens, adds inference latency and introduces another failure surface into the process. At enterprise scale, repeatedly using an LLM for deterministic operations can become both an architectural and an operating-cost problem.

The objective is not to minimize the role of the LLM. It is to use its intelligence for the problems that actually require intelligence.

What Happens If the Agent Is Wrong?

There is one more question that becomes particularly useful when deciding where to draw the boundary: what happens if the agent is wrong?

An agent conducting market research may miss an emerging competitor or produce a weak recommendation. That matters, but the immediate consequence is primarily the quality of the research. The same degree of autonomy looks very different when an agent's decision can release a large payment, reject a customer, make a contractual commitment, change a production system or expose sensitive information.

The greater the material consequence of a decision, the more deliberately its authority needs to be designed. This does not mean excluding LLMs from important decisions. An LLM may perform much of the difficult intellectual work by analysing complex evidence, connecting information and recommending a course of action. However, recommending an action and having the authority to make that action happen are not the same thing.

An agent may conclude that a large payment appears legitimate. Whether that conclusion should itself cause the payment to be released is a different architectural decision. Depending on the context, execution may still need to pass through explicit business rules, approval thresholds, policy checks or human authorization.

I find three questions useful when thinking about this boundary: What is the agent allowed to reason about? What is it allowed to decide? And what is it allowed to cause? The last question often reveals where the real enterprise boundary lies.

Designing for Predictable Autonomy

None of this means that open-ended autonomy is inherently wrong. For research, exploration and discovery, we may actively want an agent to decide what to investigate, which sources to pursue, which hypotheses to abandon and when it has gathered enough evidence to form a view. Trying to make such work deterministic could remove much of the value of using an LLM in the first place.

The difference is not simply whether the agent chooses its own path. It is what authority comes with that freedom and what happens when its reasoning is wrong. Producing a research recommendation is different from releasing a payment; recommending that an exception be approved is different from approving it.

This is why I do not see bounded autonomy as an attempt to make agents less capable. We should allow LLMs to reason freely where reasoning creates value, while being deliberate about the authority that accompanies that intelligence. We do not need to constrain the intelligence of the LLM unnecessarily; we need to constrain its authority deliberately.

That, to me, is the foundation of predictable autonomy. It does not require deterministic intelligence. It requires deliberate control over where probabilistic intelligence is allowed to influence business execution.

For an architect, the more useful question may therefore not be how autonomous should this agent be? It may be: what decisions should this agent own, and what decisions must the surrounding system continue to own?

Once that boundary becomes explicit, autonomy stops being something that simply emerges from a prompt, a model and a collection of tools. It becomes something we deliberately design into the enterprise system.

© 2025-2026 Anand Saranath - All rights reserved

Follow my writing on Whatsapp →

Connect with me on LinkedIn →