AI agents can now choose how to approach a task instead of following every step of a predefined process. That flexibility is useful, but it changes how enterprise applications must control what happens next.
When a familiar process takes an unfamiliar turn
A manufacturing company is preparing for an important production run when a supplier announces that a critical component will arrive three weeks late. The purchasing manager needs an alternative quickly, but finding one involves more than checking prices. Delivery schedules, existing contracts, supplier approvals, and inventory availability must all be considered.
In a conventional enterprise application, the manager might work through several systems to gather this information. Some steps may already be automated, such as checking approved suppliers or routing a purchase request for approval. The process can be sophisticated, but its main activities and decision paths are generally defined during development.
Now imagine the manager asks an AI agent to find an alternative supplier who can deliver within two weeks, compare the options, and recommend a solution. The agent checks the supplier database, examines inventory, and reviews delivery schedules. When none of the approved suppliers can meet the deadline, it searches for alternatives and identifies information that needs further investigation.
The important difference is not that software has suddenly learned to make decisions. Enterprise applications have been doing that for decades. What changes is that an AI agent can determine some of its next steps while the task is underway, rather than relying entirely on a predefined sequence.
This creates an architectural question: how much freedom should an agent have to decide what happens next, and where should the enterprise system retain control?
From predefined workflows to AI-directed execution
Traditional workflow automation is built around processes that developers design in advance. An invoice-processing system, for example, may verify a supplier, match an invoice to a purchase order, check approval limits, and initiate payment. Different conditions can lead to different paths, and the process may continue over several days while waiting for approvals.
These systems are neither simple nor outdated. Workflow engines already support complex coordination, retries, and recovery from interruptions. Temporal’s documentation, for example, describes how workflows can preserve execution progress across failures.
AI agents introduce flexibility at a different point in the process. Instead of defining every investigative step, developers can provide an agent with an objective, a set of permitted tools, and boundaries for using them. The agent can then select an appropriate tool, examine its result, and decide what information to gather next.
In the supplier example, the agent might discover that an alternative component is available from an existing supplier. It could then check whether the component meets the required specifications before continuing its search. That investigative path may not have been explicitly programmed.
This does not mean agents operate without restrictions. Developers can limit their tools, validate requests, and require approval for particular operations. An agent can also work inside an established workflow, handling the flexible investigation while the surrounding application manages the business process.
That combination is particularly relevant to enterprise architecture. The organization gains flexibility in how information is gathered and recommendations are developed without having to surrender control over how business operations are executed.
When a recommendation becomes a business action
The purchasing agent eventually identifies a supplier who can deliver within ten days. The price is higher than the existing agreement, but the additional expense appears reasonable compared with the cost of delaying production.
The agent recommends placing the order.
At this point, the nature of the task changes. Finding a suitable supplier is an investigative activity. Placing an order creates a financial commitment. The agent may have enough information to recommend the purchase without having the authority to execute it.
The company’s purchasing system must still verify the supplier’s eligibility, check spending limits, and determine whether additional approval is required. These controls should not depend solely on the agent’s interpretation of company policy.
This distinction becomes more important when agents can access multiple enterprise systems. An agent may have permission to read supplier contracts but not modify them. It may be allowed to prepare an order but not submit it. Even when it operates under a dedicated identity, that identity does not automatically provide authority for every action.
NIST’s guidance on agent identity reinforces the importance of established identity and authorization principles as agents begin acting on behalf of users and organizations.
The same boundaries must hold when agents delegate work. If the purchasing agent asks another agent to review a contract, the second agent should receive only the access needed for that review. Discovering that a contract could be terminated does not give it permission to terminate the agreement.
These requirements build on familiar enterprise security practices, particularly least-privilege access and controlled delegation. The additional challenge is applying them when the sequence of tool calls and delegated tasks may be determined during execution.
The resulting design principle is straightforward: an agent can determine which action to propose, but the systems responsible for carrying it out must independently establish whether it is permitted.
When the action succeeds but the agent loses track
Once the supplier is approved, the purchasing manager authorizes the order. The agent submits the request, and the purchasing system creates the purchase order successfully.
Before the confirmation reaches the agent, however, the connection fails.
When the agent resumes, it sees an incomplete task. If it submits the order again without checking what happened, the company could end up with two purchase orders.
This is not a new problem created by AI. Distributed applications have long faced situations where an operation succeeds but its confirmation is lost. What makes the problem relevant here is that an agent may resume work and determine its next action from incomplete information.
A reliable application cannot treat the agent’s uncertainty as evidence that the operation failed. It must check the authoritative business system before deciding whether another attempt is necessary.
One established safeguard is an idempotency key, a stable identifier that allows a supporting service to recognize repeated requests for the same operation. When correctly implemented, this can prevent a retry from creating a duplicate transaction. Other safeguards include checking transaction status and reconciling the result with the system that performed the operation.
Modern agent platforms provide features for preserving sessions and recovering interrupted work. But recovering an agent’s execution environment is different from confirming that its external actions completed correctly. Microsoft’s long-running agent resilience documentation makes this distinction explicit, leaving important responsibilities for progress preservation and duplicate-effect prevention with the application.
The lesson from the purchase order is therefore broader than recovery. An agent may remember what it attempted, but the enterprise system must establish what actually happened.
What changes in enterprise architecture
The supplier example brings the architectural difference into focus. The agent investigated an unfamiliar problem, selected tools, examined alternatives, and recommended an action. The purchasing system then applied the organization’s rules, executed the approved operation, and provided the record needed to verify its outcome.
The distinction is between flexible decision-making and controlled execution. The agent can help determine what should happen next, while established enterprise services enforce permissions, business rules, and transaction safeguards.
This does not require every organization to replace its existing architecture. Identity management, workflow engines, application interfaces, and transaction controls remain essential. What changes is how these components interact with software that can select parts of its execution path dynamically.
That also changes what architects need to evaluate. Testing whether an agent can complete a successful task is no longer sufficient. Teams must understand what happens when the agent selects an unsuitable tool, encounters incomplete information, delegates work, loses access, or resumes after an interrupted transaction. The appropriate controls depend on the consequences of the actions the agent is permitted to perform.
For some applications, such as searching public documentation, those controls may be relatively simple. For applications that modify financial records, customer accounts, or production infrastructure, the execution boundaries need considerably more attention.
AI agents are therefore changing an important part of enterprise software: how applications decide which actions to request. They are not removing the engineering responsibilities associated with carrying out those actions.
The opportunity is to combine the flexibility of AI-directed investigation with the reliability of established enterprise systems. The architectural challenge is making those two capabilities work together without confusing an agent’s recommendation with permission to act.
Next in this series
After You Close the Laptop: What Infrastructure AI Agents Actually Need. Closing the laptop should not lose the assignment. What must enterprise infrastructure preserve when an AI agent waits, fails, or reaches its budget?
Go deeper
Each source was opened and checked on 9 October 2026. The Microsoft page describes features marked as preview, and the Google Cloud page is a vendor announcement.
- NIST: Why Agentic AI Needs a Strong Identity Foundation. Published August 27, 2026. Explains identity and authorization principles relevant to AI agents acting on behalf of users and organizations.
- Temporal: Workflow Execution. Explains durable workflow execution and recovery, providing useful context for understanding what conventional workflow systems already support.
- Microsoft: Long-Running Agent Resilience. Describes recovery capabilities and the responsibilities applications retain when executing external operations.
- Google Cloud: Gemini at Work 2026. Published October 8, 2026. Provides context on enterprise-agent capabilities, including tool use, delegation, and persistent work. This is a vendor announcement rather than an independent evaluation.