In the previous article, I described Cross-System Automation as the most transformative pattern of Process Automation AI. Unlike SaaS-native AI or AI-enabled strategic applications, cross-system automation requires AI to coordinate work across applications, documents, workflows, APIs, and people. This is where Agentic Architecture begins.
Much of the current discussion around Agentic Architecture focuses on technology. Teams debate MCP, LangGraph, Semantic Kernel, orchestration engines, and multi-agent systems. Vendors promote competing visions of how agents should be built and deployed.
These technologies matter, but they are implementation choices.
The more important architectural question is:
How should an enterprise realize Agentic Architecture?
In practice, the answer has less to do with frameworks and protocols and more to do with ownership.
Who owns the experience?
Who builds the capability?
Who provides the platform?
Who owns the business outcome?
These decisions ultimately shape the architecture far more than any individual technology selection.
Agentic Architecture Is an Operating Model Decision
Most enterprise architecture discussions begin with technology. Agentic Architecture is different.
The moment AI starts coordinating work across systems, architecture and operating model become tightly coupled.
A customer service agent may access CRM data, knowledge articles, ticketing systems, workflow engines, and enterprise APIs. A procurement agent may coordinate contracts, approvals, supplier information, ERP transactions, and email communications.
At this point, the challenge is no longer connecting systems.
The challenge is determining how responsibilities are divided across the enterprise.
Organizations that approach Agentic Architecture purely as a technology initiative often find themselves debating frameworks before they have defined ownership.
The organizations that move fastest typically establish an operating model first and then select technologies that support it.
Decision 1: Who Owns the Experience?
One of the first architectural decisions is determining where users interact with agents.
The natural temptation is to build a centralized AI experience. An enterprise assistant. A unified portal. A single destination for every automation initiative.
Most business processes already have a natural home.
Sales teams operate within Salesforce.
Customer service teams operate within ServiceNow.
Finance teams work inside ERP systems.
Operational teams often have their own industry-specific platforms.
Even when a workflow spans multiple systems, users typically interact through a single anchor application.
This creates an important principle for Agentic Architecture.
The agent may operate across systems.
The experience should remain close to the process owner.
A procurement agent may coordinate activities across contracts, supplier systems, approvals, and ERP platforms. The procurement professional should continue working within the procurement experience they already understand.
The recommendation is straightforward:
Domain teams should own experiences.
Platform teams should provide the capabilities that enable those experiences.
This approach allows AI adoption to scale without requiring a centralized team to build every interaction model across the enterprise.
Decision 2: Who Builds Agentic Capabilities?
The next decision is determining how agentic capabilities will be realized.
Most enterprises will adopt a combination of three approaches.
The first is leveraging agentic capabilities already embedded within enterprise platforms. Salesforce, ServiceNow, SAP, Workday, Microsoft, and other vendors are increasingly providing agentic functionality as part of their products. When a process largely resides within a platform, vendor-provided capabilities are often the most pragmatic option.
The second approach is adopting an automation platform. Solutions such as UiPath, Automation Anywhere, Camunda, Microsoft Power Platform, and Pega are evolving into agent-enabled orchestration platforms capable of coordinating work across multiple systems. These platforms are increasingly becoming the default choice for common cross-system workflows.
The third approach is building custom agentic capabilities.
This is where most architectural decisions emerge.
The first question is whether the workflow actually requires an agent. Some processes are largely deterministic and benefit from workflow orchestration with AI embedded at specific steps. Others require dynamic reasoning, planning, tool selection, and adaptation to changing conditions.
The second question is whether a single agent is sufficient or whether multiple specialized agents are required.
Most enterprise implementations begin with a single orchestrating agent responsible for coordinating tools and workflows. Multi-agent architectures become relevant when responsibilities need to be separated across planning, research, execution, compliance review, or quality assurance.
The third question is selecting a runtime.
Organizations building custom capabilities are increasingly standardizing on frameworks such as LangGraph, Semantic Kernel, OpenAI SDKs, and similar orchestration technologies.
The framework itself is rarely the most important decision.
The more important decision is establishing runtime standards that domain teams can build upon.
This includes:
- Deployment patterns
- Security controls
- Evaluation frameworks
- Observability standards
- Runtime lifecycle management
The objective is not creating one team that builds every agent.
The objective is creating a platform that enables many teams to build safely and consistently.
Decision 3: How Do Agents Access Enterprise Capabilities?
No topic generates more discussion today than MCP.
Many organizations encounter MCP and immediately begin asking how enterprise applications should be exposed to agents.
A more useful question is:
What capabilities should agents consume?
Most enterprise applications expose technical operations.
Agents require business operations.
A customer service agent should retrieve customer information, create service cases, and update accounts.
A procurement agent should approve invoices, retrieve contracts, validate suppliers, and create purchase orders.
These capabilities eventually become enterprise tools.
Over time, organizations discover that the same capabilities are used repeatedly across multiple workflows and domains.
Customer lookup.
Contract retrieval.
Policy interpretation.
Document classification.
Inventory validation.
Invoice approval.
This is where capability catalogs become important.
Once capabilities have been defined, they can be exposed through APIs, integration platforms, tool registries, and eventually MCP.
The sequence matters.
Capabilities first.
Standardization mechanisms second.
Decision 4: How Should Enterprise Information Be Exposed?
As agents become more capable, access to information becomes increasingly important.
The key architectural decision is determining how information is exposed.
Not every agent requires access to enterprise-wide knowledge.
Most agents require information specific to the business process they support.
An invoice approval agent may need contracts, purchase orders, supplier information, and approval policies.
A customer service agent may need customer history, knowledge articles, service policies, and open tickets.
Organizations generally have three architectural options.
The first is application-centric access, where agents retrieve information directly from the systems that own the process.
The second is domain-centric access, where information is assembled into reusable domain data products that support multiple workflows and applications.
The third is an enterprise knowledge layer, where information from across the organization is unified and exposed through a common access layer.
For most Agentic Architecture initiatives, application-centric and domain-centric approaches are sufficient.
Enterprise knowledge layers become increasingly important as organizations move toward decision intelligence, enterprise search, and enterprise-wide reasoning.
The architectural objective is simple:
Provide agents with the information required to perform a business task.
Not every piece of information available across the enterprise.
Decision 5: How Will the Enterprise Scale?
This is ultimately the most important decision.
Most organizations focus on building the first agent.
The more important question is:
How will the fiftieth agent be built?
This is where operating model becomes more important than technology.
The responsibility of the platform team is not to build agents.
The responsibility of the platform team is to create the paved road.
That paved road includes:
- Model access
- Runtime standards
- Governance
- Guardrails
- Tool catalogs
- Evaluation frameworks
- Identity and authorization
- Observability
These capabilities should be built once and reused many times.
Business domains then build outcomes on top of those capabilities.
This creates a scalable model where multiple teams can innovate simultaneously without competing for the same central delivery organization.
Over time, organizations may introduce additional capabilities such as reusable services, agent registries, agent templates, and low-code development experiences.
These investments become valuable because the underlying platform standards already exist.
The result is a clear separation of responsibilities.
Platform teams provide capabilities.
Business domains provide outcomes.
A Final Thought
Agentic Architecture is often described as a collection of frameworks, protocols, orchestration engines, and AI runtimes.
In practice, it is a set of architectural decisions about ownership.
Who owns the experience?
Who builds the capability?
Who exposes enterprise services?
Who provides information access?
Who owns the outcome?
The answers to these questions shape the architecture far more than any individual technology selection.
The organizations that realize the most value from Agentic Architecture will not necessarily be the ones with the most sophisticated agent framework.
They will be the ones that establish a scalable operating model that allows business domains to innovate while relying on a common set of enterprise capabilities.
The principle is simple:
Centralize capabilities. Decentralize outcomes.
Platform teams provide the foundation.
Business domains provide the innovation.
That operating model, more than any framework or protocol, is what ultimately enables Agentic Architecture to scale across the enterprise.
Tech Canvas 