Illustrations generated using ChatGPT (OpenAI)
Over the past four decades, enterprise technology has gone through several major architectural shifts. We moved from monolithic applications to TP monitors, object-oriented programming, component architectures, SOA, microservices, APIs, cloud-native platforms, and now AI agents.
Each wave promised the same outcome – more modular, reusable, and composable business capabilities that enable greater automation. The technology itself was rarely the reason these initiatives succeeded or failed.
The organizations that were successful didn’t simply adopt the latest technology. They invested the effort to identify the right business abstractions – the procedures, functions, services, APIs, and reusable capabilities that represented how work should actually be performed. Those abstractions allowed technology to evolve while the business capabilities remained stable.
AI agents represent the next evolution in that journey. The abstraction has always been the business capability; only the implementation has changed. An AI agent is not the abstraction – it is simply another way of executing that capability.
From functions to objects, from services to APIs, and now to AI agents, the implementation has continued to evolve. The business capability remains the constant.
Which brings us to the questions I hear every week – Which LLM should we use? Which agent framework should we choose? How should we engineer the prompts?
Those are all important engineering decisions. But they aren’t the only design decisions that matter. If we focus only on models, prompts, and frameworks without taking the time to defining the business capability we want the agent to perform, we will simply create another generation of technical debt – this time powered by AI.
Before choosing a model or framework, every enterprise AI agent needs three things: Context, Authority, and Tools.
A capable model does not create capable enterprise agent
A capable model does not automatically create a capable agent. For an AI agent to perform meaningful work inside an enterprise, it needs three things:
- Context – Without context, the agent does not understand the situation.
- Authority – Without authority, it cannot act.
- Tools – Without tools, it cannot complete the work.
1. Context: What does the agent need to understand?
An agent needs more than a prompt.
It needs the information required to interpret the situation, make an appropriate decision, and understand the consequences of that decision. Depending on the task, context may include –
- The customer’s history and current request
- The state of a transaction or case
- Relevant policies and operating procedures
- Product and service information
- Previous decisions and communications
- Business rules and regulatory requirements
- Exceptions, dependencies, and deadlines
- The objective the agent is expected to achieve
Consider a claims agent asked to evaluate the next action on a claim. A prompt may tell it to “review the claim and recommend the next step.” But the agent cannot do that reliably without understanding the policy, coverage, claim history, supporting documents, prior communications, jurisdiction, and applicable business rules.
The model may be intelligent, but intelligence without context becomes inference. And in an enterprise process, unsupported inference creates risk. The challenge is not simply giving the agent more information. Too much irrelevant information can be as problematic as too little.
The agent needs the right context, at the right time, for the specific decision it is making.
2. Authority: What is the agent allowed to do?
Understanding the work does not mean the agent should be allowed to perform every action associated with it.
Authority defines the agent’s decision rights and boundaries.
Can the agent – Read customer information? Update a record? Approve a transaction? Issue a payment? Communicate directly with a customer? Override a business rule? Escalate an exception? Delegate work to another agent or employee?
These permissions should not be treated as a single yes-or-no decision.
Authority should be specific to the task, the level of risk, and the confidence of the decision.
For example, an agent may be allowed to approve refunds below a defined amount when all policy conditions are satisfied. A higher-value refund may require human approval. A transaction with missing information or conflicting signals may need to be escalated automatically.
Authority also requires accountability.
Every meaningful action should have a clear record –
- What did the agent decide?
- What evidence did it use?
- Which policy or rule supported the decision?
- What action did it take?
- When did it escalate to a person?
- Who is accountable for the outcome?
An enterprise agent should not have unlimited freedom. It should have bounded authority that is proportional to the risk of the action.
3. Tools: How will the agent perform the work?
An agent cannot complete enterprise work by generating text alone.
It needs tools that allow it to interact with the systems where work happens. Those tools may allow the agent to –
- Retrieve customer or transaction data
- Search enterprise knowledge
- Initiate workflows
- Send approved communications
- Schedule follow-up activities
- Escalate work to an employee …
The quality of an agent depends partly on the quality of these tools. If a tool is unreliable, poorly defined, or exposes more capability than necessary, the agent becomes unreliable as well. Each tool should have a clear purpose, structured inputs and outputs, appropriate access controls, and predictable failure behavior.
The agent also needs to know when not to use a tool.
It should understand which actions are reversible, which create financial or customer consequences, and which require confirmation or human approval.
Giving an agent access to a system is not the same as designing a safe way for it to use that system.
All three must work together
Context, authority, and tools are not independent design decisions. They must align around the work the agent is expected to perform. An agent may have the context to identify that a payment should be issued, but not the authority to approve it. It may have the authority to update a customer record, but not the tools required to access the system. It may have both authority and tools, but insufficient context to know whether the action is appropriate.
In each case, the agent fails – not because the model is incapable, but because the operating environment is incomplete. A useful way to think about agent readiness is – Context determines what the agent understands. Authority determines what the agent may decide and do. Tools determine what the agent can execute.
The model provides reasoning across all three. But the enterprise must design the conditions in which that reasoning operates.
Start with the work, not the agent
Before creating an AI agent, organizations should understand the process in which it will operate.
- What outcome is the process trying to achieve?
- Which decisions are deterministic?
- Which require judgment?
- What information is needed for each decision?
- Which actions can be delegated safely?
- Where must accountability remain with a person?
- Which systems are required to complete the work?
Only then can the organization define the agent’s context, authority, and tools. The most important question is not – Which model should power this agent? It is – What must this agent understand, what should it be allowed to do, and what capabilities does it need to complete the work safely?
One lesson we have learned
As we have evolved KognitiveWorks from an intelligent document processing platform into an enterprise agentic platform, one lesson has become clear – building enterprise agents is not primarily about selecting the best LLM. Most of the engineering effort goes into assembling the right context, defining authority boundaries, and exposing enterprise capabilities through secure APIs and MCP-enabled integrations. The model provides the reasoning. The enterprise provides the operating environment. That’s why enterprise AI is ultimately an engineering problem – not simply a model selection problem.
Enterprise AI won’t be won by organizations with the smartest models. It will be won by organizations that build the best business capabilities. Prompts will change. Models will improve. Agent frameworks will evolve. But every enterprise AI agent will still need three things – the context to understand, the authority to act, and the tools to execute. Which of these is the biggest constraint in your organization today?
