AI Agents Are Systems, Not Colleagues

One of the more difficult questions I encountered while thinking through enterprise agents came from a supplier invoice discrepancy.

The task we had in mind appeared straightforward. An agent would examine the discrepancy, contact the supplier when clarification was needed, evaluate the response and return its findings to the business workflow.

Then we considered a slightly different response. Suppose the supplier acknowledges the discrepancy and proposes a revised amount. The agent can evaluate that amount. But should it also be allowed to accept it?

The agent has been asked to investigate the discrepancy. Accepting a revised amount might appear to be a reasonable way to complete that goal. It may even produce the right commercial outcome. Yet it also creates a commitment that the enterprise may never have intended the agent to make.

The problem is not simply whether the agent is intelligent enough to respond. It is whether the words investigate the discrepancy have silently given it more responsibility than the surrounding system was designed to surrender.

That question led me to a broader conclusion. We often describe agents as if they were digital colleagues who can be assigned a goal and trusted to work out what the assignment means. Enterprise agents need to be treated differently.

They are software systems. Their responsibilities, authority, interfaces and failure behaviour have to be engineered.

What Makes the Component an Agent?

Before deciding where an agent's authority should end, we need to be clear about what makes the component an agent in the first place.

Consider a conventional application that follows a prescribed sequence. It retrieves an invoice, sends a standard request for supporting documents, receives the supplier's response, summarises it and sends the material for review. AI may help compose the message or interpret the response. That makes the application AI-assisted, but not necessarily agentic.

Now change the behaviour.

The component examines the supplier's response and notices that it does not explain the additional charge. It decides what clarification is still needed, requests further evidence, evaluates what comes back and adjusts its investigation. The next action depends on what it discovers during execution.

That is the distinction I find useful:

An AI agent is a software component that uses AI to select and adapt actions toward a goal, based on information encountered during execution.

The important part is not merely that AI is present. It is that AI participates in selecting and adapting the actions that move the task forward.

An LLM that classifies an invoice may be an AI-enabled capability. An LLM that drafts a supplier email may be assisting a person or a workflow. A component that decides what evidence to retrieve, discovers a gap, asks a follow-up question and changes its approach is behaving agentically.

The distinction is about how the work progresses, not whether the software has been given a human-sounding role.

Agency Is Not Autonomy

The supplier example exposed a second distinction that I believe is even more important.

Agency describes how a component pursues a goal. Autonomy describes the authority delegated to it while doing so.

The investigation component is an agent because it selects and adapts actions based on the evidence it encounters. Whether it may accept a revised amount is a separate decision about autonomy.

One enterprise may allow the agent to gather evidence, evaluate the revised amount and return a recommendation. The workflow then routes the case for human validation. Another enterprise may eventually permit the agent to accept certain revisions under defined conditions.

The component is agentic in both arrangements. What changes is what it may decide and cause.

This also explains why a bounded agent is not simply a copilot with the human removed. In a copilot arrangement, AI may analyse the situation and propose a next action, while the human continues to choose how the task progresses. In an agentic arrangement, the component itself selects and adapts at least some of the actions that progress its assigned task.

Human involvement can exist in either design. A human may approve the agent's final recommendation without selecting every investigative action the agent took to reach it.

The deeper question is therefore not whether a human appears somewhere in the process. It is who selects and adapts the actions that progress the task, and what authority accompanies that responsibility.

The Workflow and the Agent Own Different Progress

This distinction helped resolve another source of confusion: the word orchestration.

At the enterprise-process layer, a workflow may own the lifecycle of the invoice. It records that a discrepancy has been identified, invokes an investigation, waits for its result, routes the evidence for validation and determines whether the invoice proceeds, remains blocked or is escalated.

Inside one step of that workflow, an agent may own the investigation. It decides what evidence is missing, which permitted capability to use, whether the supplier's response answers the question and whether another follow-up is justified.

Both are orchestrating work, but they are not orchestrating the same thing.

The workflow owns progression of the business process. The agent owns adaptive execution toward a bounded goal inside that process.

This separation allows the agent to be genuinely agentic without quietly inheriting the surrounding business process. It may choose its investigative path, consult governed specialist agents and revise its approach. When it reaches a conclusion, an uncertainty or an execution limit, it returns control to the workflow.

The result from the agent may still influence what the workflow does next. That does not require the agent to own the transition. The workflow can evaluate the returned result through explicit business rules, policy checks, approval thresholds or human validation.

The two layers also own different state. The agent needs working context for the investigation: the supplier's responses, evidence gathered, questions already asked and conclusions reached. The workflow owns business state: whether the invoice is under investigation, awaiting validation, approved, rejected or escalated.

Those states may be stored together or separately. The architectural issue is who is entitled to change them and what each change means.

The Boundary Must Be Engineered

Once we separate these responsibilities, the phrase investigate the discrepancy is no longer sufficient.

The invoking workflow should tell the agent what work has been entrusted to it, what actions it may take, what outcome it must return and when it must give control back.

For the supplier discrepancy, the agent may be permitted to identify missing evidence, request clarification through an approved communication mechanism, evaluate the response and return its findings. It may be explicitly prohibited from negotiating commercial terms, accepting a supplier proposal, approving the invoice or posting payment.

The return contract matters just as much. A response saying the discrepancy is resolved tells the workflow too little. What evidence was obtained? What did the agent conclude from it? What remains uncertain? Was the investigation completed, or did it stop because a time or retry limit was reached?

These are not documentation details added after the agent is built. They give the assignment its concrete meaning.

The agent can choose how to pursue the investigation within that contract. It cannot redefine successful completion to include authority it was never given.

This resembles the discipline we already apply when designing services. A service has a cohesive responsibility, an explicit interface, managed dependencies, defined outcomes and known failure behaviour. I find that analogy useful for agents as well.

It does not mean every agent must be deployed as a separate microservice. Related agents may be co-located, and an agent service may expose them through common infrastructure. The useful part of the analogy is the engineering discipline: the component's responsibility should be explainable, its contract should be precise and its failure should be contained.

A precise contract gives us something to enforce. The surrounding system must still enforce it.

We could tell the investigation agent: You may request evidence, but you must not negotiate. That instruction communicates the intended boundary. Yet if the agent has access to a general-purpose email tool, it can still compose and send a message that crosses it.

A request for supporting documents and an offer to accept a lower amount both use email. Checking whether the agent is allowed to send email does not distinguish between them.

This is where prompts and lists of dos and don'ts reach their limit. Natural-language instructions are interpreted by the same probabilistic system whose behaviour we are trying to constrain. They can guide the agent, but they should not be the only control protecting a consequential boundary.

For this task, the system could expose a narrower capability: request supplier evidence. The agent determines what clarification is needed and selects an approved request type. The application constructs the communication from controlled templates and validated fields. If the required communication falls outside those supported operations, the agent returns the case to the workflow.

Even the template needs care. An unrestricted comments field can quietly recreate the freedom that the controlled interface was intended to remove.

The general principle is simple. The capabilities available to an agent should reflect the authority it has actually received. Tool access answers whether the agent can reach a capability. The operation exposed through that capability determines what it can cause.

Delegation Must Preserve the Boundary

The same principle applies when one agent invokes another.

Suppose the investigation agent asks a supplier-communication specialist to obtain clarification. That specialist may conduct several permitted exchanges, examine the replies and determine whether more evidence is needed. The investigation agent then evaluates the material alongside the rest of the case.

This is still bounded agentic execution. But access to specialist agents must be governed, and delegation cannot expand the original authority.

If the investigation agent has no authority to negotiate, it cannot create that authority by delegating to a specialist that happens to know how to negotiate. The invoked agent's available goal, actions and tools must remain within both its predefined responsibility and the authority carried by the specific assignment.

The contract between the agents also needs to be concrete. If the specialist is expected to return two supporting documents, a reassuring summary is not an adequate result. It should return the documents, the findings, unresolved gaps and the status of the attempt.

Retries and timeouts belong in that contract as well. An agent should not keep contacting the supplier indefinitely. If it reaches the permitted number of attempts or the response deadline passes, it returns an incomplete outcome for escalation.

Restarting the same task for the same invoice without new information should not silently reset those limits. Fresh information may justify another attempt, but the decision to reopen execution belongs to the surrounding control logic—the workflow or invoking application that owns the case—not to the invoked agent that exhausted its assignment.

Delegation is therefore not simply agent-to-agent communication. It is the transfer of a specific task under inherited constraints, with an expected result and a defined return of control.

Engineering the Autonomy

Authority is not the only boundary an agent needs. The execution itself also needs to be contained.

Suppose several agents are drawn as separate components but run inside the same unrestricted runtime. One of them enters a loop, repeatedly calls tools, accumulates context or launches more work than expected. It can consume the memory, processing capacity or external-service quota needed by every other agent in that service.

If the same runtime also hosts the business application, the failure can spread further. An investigation agent that goes rogue should not create a denial of service for invoice processing.

This is why I prefer agent execution to have its own managed runtime space and to be invoked through explicit interfaces. An agent gateway may govern discovery, identity, access and routing. An agent service may host the execution environment and expose stable APIs to workflows, user interfaces, scheduled jobs and business applications.

Again, this does not require one deployment for every agent. Co-location can be entirely reasonable. But logical separation is not resource isolation. Separate instructions and separate conversation histories do not impose limits on duration, concurrency, memory consumption or downstream calls.

Those limits need runtime enforcement. The architecture should be able to cancel work, contain failure, prevent uncontrolled spawning, preserve an execution record and protect neighbouring workloads.

These concerns are familiar because the fundamentals of software engineering have not disappeared. New AI capabilities change what a component can do and how its path unfolds. They do not remove the need to define interfaces, manage state, control resources, observe execution and design for failure.

The supplier example began with a seemingly small question: may the agent accept a revised amount?

Following that question exposes most of the architecture around an enterprise agent.

We need to know what makes the component agentic. We need to separate its agency from the autonomy delegated to it. We need to distinguish progress inside the assigned goal from progression of the surrounding business process. We need a contract that defines the responsibility and a runtime that can enforce the boundary. If the agent delegates, that boundary must survive the handoff.

None of this requires us to make the agent less intelligent or prescribe every step in advance.

The investigation agent can still interpret ambiguous evidence, choose among permitted capabilities, change its approach, ask follow-up questions and coordinate governed specialist agents. That adaptive behaviour is why we introduced an agent in the first place.

But the freedom to choose a path does not establish autonomy to take every action along it.

An enterprise may increase that autonomy over time. It might begin with human validation of every recommendation, observe the system's behaviour and later permit specific actions under defined conditions. That is a governance decision. The architecture's job is to make each decision explicit and enforceable.

Some permissions may expand. Others—especially authority over consequential business-process progression—may remain with the surrounding system.

This is what it means to treat agents as systems rather than colleagues. We define the responsibility, the contract, the available actions, the state ownership, the execution limits, the escalation path and the conditions under which control returns.

The autonomy we see is the behaviour. The predictability we need has to be engineered.

© 2025-2026 Anand Saranath - All rights reserved

Follow my writing on Whatsapp →

Connect with me on LinkedIn →