AI agents in business: build on your data and cloud platform, not around it

AI agents can plan and execute multi-step work across enterprise data, applications, and APIs. But the agent itself is only one component. At Webellian, we believe the harder problem is creating the data, identity, integration, security, observability, and cloud architecture that allows agents to act reliably without creating another isolated AI platform.

What are AI agents in business?

An enterprise AI agent is a goal-directed software system that uses models, data, context, and tools to decide and execute a sequence of actions within defined boundaries.

The term “agent” is now used for everything from chat interfaces to autonomous workflows, so the distinction matters.

A conventional generative AI application responds to an input and produces an output. An agent can go further: interpret a goal, identify what information or tools it needs, perform actions, observe the result, and decide what should happen next.

A procurement agent, for example, might retrieve a contract, query historical spend, check supplier performance, compare alternatives, prepare a recommendation, and route the result for approval.

That does not mean every agent should be fully autonomous. In enterprise architecture, autonomy is a design choice. Some agents should only retrieve information and recommend actions. Others may update records or trigger workflows, while high-impact actions involving money, customers, security, or legal decisions may still require human approval.

For a broader view of generative AI in enterprise systems, see our guide to generative AI in the enterprise.

AI agents vs RPA, chatbots, and copilots

RPA remains useful for stable, predictable workflows. Agents become more relevant when the system must interpret changing context, choose between tools, and adapt the next step.

A conversational model such as ChatGPT or Claude is therefore not automatically an enterprise agent. It becomes part of an agentic system when it is given tools, permissions, workflow state, enterprise context, and authority to perform actions.

Why enterprises are adopting agentic AI now

Enterprise adoption is growing, but current research still shows a substantial gap between experimenting with agents and operating them reliably at scale.

McKinsey’s 2026 global AI survey gathered 1,719 responses across 97 countries. Among organizations with more than $1 billion in annual revenue, 40% of respondents reported scaling AI agents in at least one function, compared with 27% the previous year. Among smaller organizations, the figure was 22%. (mckinsey.com)

Forrester’s 2026 analysis points in the same direction but emphasizes maturity: many enterprises are adopting or piloting agentic AI, while scaled multi-agent deployments remain far less common. (forrester.com)

The important shift is that the problem quickly stops being “Can the model reason?” and becomes an architecture question:

Can the agent access the right enterprise context? Which actions can it perform? How is it authenticated? How do we evaluate a multi-step workflow? Who approves high-impact actions? How much does one successful task cost?

Those questions determine whether a promising pilot can become a production system.

How AI agents work

An enterprise agent typically combines context, model-based decision logic, optional memory, tools, and feedback from the environment until the task is completed or a defined boundary is reached.

Context may include user requests, policies, account data, application state, documents, database records, or outputs from previous actions.

Planning and decision logic determine the next step. Some decisions can be model-driven, while others should remain explicit application logic.

Memory can preserve context within one workflow or across multiple interactions. Persistent memory should be introduced carefully because it adds privacy, retention, security, and data-quality concerns.

Tools allow the agent to interact with enterprise systems, for example by querying Snowflake, updating Salesforce, creating a ServiceNow ticket, or triggering a deployment workflow.

Feedback closes the loop. The agent observes whether an action succeeded and determines the next permitted step.

Production reliability therefore depends on much more than model quality. A strong model connected to an unreliable API, poorly governed data source, or overprivileged identity is still an unreliable system.

Single-agent vs multi-agent architecture

We recommend starting with the simplest architecture that can solve the workflow reliably and adding multiple agents only when specialization or independent responsibilities justify the additional complexity.

Architecture and human oversight should be treated as separate design decisions. Any of these architectures can operate with different levels of human involvement, from human approval before critical actions to continuous monitoring or fully automated execution where appropriate.

In enterprise environments, the required level of human oversight usually depends on the business impact, regulatory requirements, risk tolerance, and the type of action the agent can perform.

MCP and A2A

Model Context Protocol, or MCP, primarily connects AI applications and agents to tools, services, and external context. It should not be described as an agent-to-agent protocol. MCP was donated to the Linux Foundation’s Agentic AI Foundation in late 2025, and its 2026 specification introduced further production-oriented changes. (anthropic.com, modelcontextprotocol.io)

Agent2Agent, or A2A, addresses communication and collaboration between agents across frameworks and vendors. In April 2026, the Linux Foundation reported support from more than 150 organizations. (linuxfoundation.org)

For enterprise architects, the distinction is straightforward: MCP connects agents to capabilities and context, while A2A supports interoperability between agents.

Architecting AI agents on your existing enterprise platform

We would build an enterprise agent layer on top of existing cloud, data, identity, integration, and observability foundations rather than create a parallel AI estate.

Large organizations already have many of the services agentic AI requires: identity, cloud infrastructure, data warehouses or lakehouses, APIs, event systems, secrets management, observability, governance, and CI/CD.

An agent architecture should reuse those capabilities.

Business and application layer

The workflow should begin where work already happens, such as customer service, procurement, finance, IT operations, or an internal product.

Where possible, agents should appear inside existing applications rather than forcing employees into another isolated AI interface.

Agent and orchestration layer

This layer manages goals, workflow state, agent selection, retries, approvals, and tool coordination.

It should also define boundaries: how many steps an agent may take, which tools it can use, what happens when confidence is low, and when control must return to a human.

Model access layer

Model choice should remain sufficiently abstract to allow different models where there is a real business reason, such as quality, latency, region, privacy, or cost.

That does not mean creating unnecessary multi-model complexity. It means avoiding business workflows that are inseparably coupled to one model provider.

Our multi-cloud strategy guide discusses the same principle at infrastructure level.

Tool and integration layer

This is what turns a model into an operational agent.

Agents should interact with enterprise systems through controlled APIs, service interfaces, MCP servers, queues, or purpose-built adapters. We would not give a model unrestricted database credentials simply because that is convenient during a PoC.

Agent security and permissions

AI agents should inherit enterprise security principles rather than introduce a separate permission model. The difference is that agents can combine access to data, tools, and actions, which makes identity, authorization, and validation even more important.

Unlike traditional software components, agents may decide which tools to call and how to sequence actions. That means security controls should apply not only to the systems they access, but also to the agent’s ability to select and execute actions.

Key controls include:

• least-privilege tool permissions so agents only access the systems and actions required for a specific workflow;
• credential isolation so models never receive unrestricted secrets or direct administrative access;
• tool-action validation to verify that requested actions match approved workflows and policies;
• approval gates for irreversible, financial, security-sensitive, or high-impact actions;
• monitoring and audit trails that record what the agent accessed, which tools it called, and what actions it performed.

Data and knowledge layer

Agents should use the same governed data foundations already used by enterprise analytics and operational systems.

Depending on the workflow, this may combine relational databases, warehouses, lakehouses, documents, vector retrieval, graph relationships, and APIs.

RAG can help ground model outputs in enterprise information, but a vector database is not automatically the entire AI data layer. Structured business facts may remain better represented in relational systems, semantic models, or operational applications.

The important requirement is preserving ownership, lineage, permissions, freshness, and data quality across the sources an agent uses.

Cloud and operational foundation

Agents still run on conventional infrastructure. Compute, networking, model endpoints, secrets, event systems, databases, logging, and policy enforcement require the same cloud engineering discipline as other production systems.

Our cloud migration strategy framework applies the same principle: new capabilities should fit the target architecture rather than create another disconnected environment.

Observability, evaluation, and cost management

An agent should not enter production unless we can reconstruct what it did, evaluate whether the outcome was acceptable, and understand what the workflow cost.

Traditional uptime monitoring is not enough. A successful request does not tell us whether the agent selected the right tool, used the right context, repeated unnecessary actions, or achieved an acceptable business outcome.

Agent observability should capture workflow paths, model and version, tool calls, latency, retries, approvals, cost, and final outcome.

Evaluation should also use representative workflow scenarios, including normal cases, edge cases, unavailable tools, policy conflicts, adversarial inputs, and situations where the correct action is to stop or escalate.

LangChain’s 2026 survey of more than 1,300 professionals found that 57% had agents in production, nearly 89% had implemented some form of observability, while 52% reported running offline evaluations and 37% online evaluations. The sample reflects the agent-engineering community rather than the entire enterprise market, but it illustrates how uneven production maturity remains. (langchain.com)

FinOps for agentic AI

Agentic systems also change the cost model because one business task can trigger multiple retrievals, model calls, tool actions, retries, and delegated subtasks.

That makes cost per completed workflow more useful than token price alone.

McKinsey’s 2026 survey found that around one in five respondents said AI operating costs constrained AI use in their organization. (mckinsey.com)

We would extend FinOps practices to agents by attributing costs to workflows, monitoring cost per completed task, limiting unnecessary loops, selecting appropriate models, caching reusable context where suitable, and setting budgets and anomaly alerts.

The goal is not minimum token consumption. It is understanding whether the workflow produces enough value for its fully loaded operating cost.

A phased roadmap for enterprise AI agents

We would scale agentic AI in three phases: foundation, controlled orchestration, and scale.

Phase 1: foundation

Start with one workflow that has a measurable business outcome and clearly defined action boundaries.

The initial implementation should already include bounded identity and permissions, controlled tool access, basic logging, and human approval where actions could create business impact.

That gives the team a controlled way to validate data, tools, security, reasoning quality, and economics.

Phase 2: controlled orchestration

Once the workflow proves its value, introduce production-grade controls and operational maturity: durable identities, expanded audit trails, formal evaluation processes, approval policies, operational monitoring, error handling, cost telemetry, and version management.

This is also where teams should decide whether multi-agent architecture is genuinely necessary and whether the workflow can be scaled across additional business processes.

Phase 3: scale

Only then would we create reusable capabilities such as shared tool catalogues, enterprise agent identities, policy services, MCP infrastructure, model gateways, common evaluation tooling, and A2A interoperability where required.

The objective is to turn agent architecture into a platform capability rather than create a collection of unrelated pilots.

Where AI agents deliver value

The strongest enterprise use cases are processes where employees repeatedly move between data, systems, rules, and decisions to complete a measurable outcome.

In finance, agents can gather reconciliation evidence, investigate exceptions, and prepare cases for approval.

In procurement, they can retrieve contracts, analyze supplier data, monitor renewals, and prepare sourcing recommendations.

In customer service, agents can combine CRM context, policies, product data, and historical cases to resolve routine requests or prepare a structured escalation.

In IT operations, they can collect telemetry, correlate incidents, search runbooks, recommend remediation, or execute pre-approved recovery steps. 

In software engineering, agents can support coding, testing, modernization, documentation, and migration work.

What these use cases share is not one platform. They require trusted context, controlled tools, clear business rules, and integration with real enterprise systems.

FAQ: AI agents in business

What is an AI agent in business?

An AI agent is a software system that interprets a goal, uses context and tools, performs actions, observes results, and continues a workflow within defined boundaries.

Is ChatGPT an AI agent?

Not necessarily. A conversational model can be part of an agentic system, but an enterprise agent typically also needs tools, permissions, state, enterprise context, and authority to act.

What is the difference between generative AI and agentic AI?

Generative AI primarily creates outputs such as text, code, or summaries. Agentic AI uses models inside a wider system that can decide and execute actions toward a goal.

For the broader technology hierarchy, see our AI vs machine learning vs deep learning guide.

What is the difference between AI agents and RPA?

RPA follows predefined workflows and rules. Agents become useful when the system must interpret context and choose which action or tool should be used next.

What is MCP?

The Model Context Protocol is an open protocol for connecting AI applications and agents to external tools, services, and context.

What is A2A?

Agent2Agent is an open protocol for communication and collaboration between agents built on different frameworks or platforms.

Do enterprises need multi-agent systems?

Not always. A single agent is preferable when it can solve the workflow reliably. Multi-agent systems add orchestration, identity, evaluation, and cost complexity.

How much does it cost to run an AI agent?

There is no universal figure because workflows vary in models, inference calls, retrieval, tools, retries, and infrastructure. We recommend measuring cost per completed business workflow.

Do AI agents replace employees?

They can automate parts of existing work, but many enterprise designs retain humans for exceptions, approvals, high-impact actions, and decisions requiring judgment or accountability.

What does an enterprise need before deploying agents?

At minimum: a defined business outcome, governed data access, tool interfaces, identity and permissions, evaluation, observability, security controls, escalation points, operational ownership, and a cost model.