Agent–Extension Boundary Model
A responsibility model for SAP agents, extensions, workflows, and core business systems.
SAP enterprise AI will not fail only because agents hallucinate.
It will fail when no one can clearly say what belongs to an agent, what belongs to an extension, what belongs to a workflow, what must remain in S/4HANA, and who owns the final business action.
The demo can look perfect: a user describes intent, an agent plans, a workflow starts, an extension API is called, S/4HANA is updated, and a confirmation appears. Architecturally, that seamless action may hide unresolved responsibility.
Why this model exists
SAP enterprise AI increasingly combines agents, apps, workflows, extensions, integrations, and business data. Platform unification is necessary, but product unification is not responsibility clarity.
A platform can provide common tooling, runtime, governance controls, discovery, observability, and business context. It cannot automatically decide which responsibility belongs to an agent, an extension, a workflow, an assistant, or a core system.
The architecture question is not only whether an agent can produce a good answer. The question is whether the enterprise can prove who owns truth, action, state, lifecycle, identity, and accountability after the agent acts.
The responsibility model
Core systems own business truth.
Extensions define governed enterprise capabilities.
Workflows define repeatable and accountable execution paths.
Agents select and coordinate action under policy.
Assistants provide the interaction surface.
The dangerous model
Business intent
→ Agent
→ EverythingThis looks autonomous, but it collapses responsibility boundaries. Business truth, reusable logic, process evidence, execution authority, and accountability all disappear into the same layer.
The governable model
Business intent
→ Assistant
→ Agent
→ Governed tool or skill
→ Workflow or extension API
→ Core systemThis model preserves truth, lifecycle, authorization, and accountability. Agents coordinate action, but governed capabilities and core systems keep their authority.
Collaboration rules
The future SAP landscape will not be made of isolated artifacts. Extensions, agents, workflows, assistants, integrations, MCP servers, skills, and core systems will collaborate. Collaboration is not the problem. Unbounded collaboration is the problem.
Extensions collaborate through contracts
Extensions may collaborate, but through APIs, events, released contracts, or governed tools. They should not depend on each other’s internal state or private implementation shortcuts.
Agents invoke extensions; they do not bypass them
Agents should call governed capabilities. They should not receive broader authority than a properly governed application just because the interface is conversational.
Workflows contain accountable execution
Agents may enrich, select, or prepare workflow input. They should not replace workflow when the enterprise needs process evidence, approvals, SLA handling, or auditability.
Multi-agent work keeps singular accountability
Agent-agent collaboration is acceptable only when delegation is explicit, roles are bounded, and accountability remains singular. A chain of agents must not dissolve final responsibility.
The seven boundaries
Truth Boundary
Who owns canonical business truth?
Core systems own core business truth. Extensions may own extension-specific truth. Workflows own process state. Agents do not own canonical truth by default. Agent memory is not business truth. RAG output and generated recommendations are not business truth until validated.
Capability Boundary
What should become a stable enterprise capability?
Stable reusable business logic should be modeled as an extension, API, service, or governed tool. Agents should invoke capabilities, not hide stable business logic inside prompts. If a business rule must be tested, versioned, reused, audited, secured, and evolved, it belongs in a governed capability.
Process Boundary
What must be governed as repeatable workflow?
Repeatable, auditable, approval-based, SLA-driven execution belongs in workflow. Agents may participate in workflow, enrich it, select it, or prepare input, but should not replace it when process evidence matters.
Execution Boundary
What is the agent allowed to do?
Each agent needs an explicit action class: read-only, summarize, recommend, draft, prepare, trigger workflow, execute low-risk action, execute high-risk action with approval, or never execute certain actions.
Context Boundary
What can the agent see, retrieve, remember, or infer?
Tenant-specific and role-specific context must remain scoped. Sensitive business context must be governed. Memory must be scoped. RAG sources must be versioned. MCP servers and semantic context must not become uncontrolled context bridges. Context must not silently become truth.
Lifecycle Boundary
How do agents, extensions, workflows, tools, policies, and context evolve together?
Agent behavior changes when prompts, model versions, tools, policies, memory, RAG sources, workflows, or extension APIs change. Agent upgrade is behavior migration. The enterprise must be able to reconstruct what changed, which tool version ran, which policy applied, which context was retrieved, which model executed, and which evaluation was passed.
Accountability Boundary
Who is responsible for the final business action?
Every agent action needs an accountable owner, every tool call needs traceability, every business write needs an actor and authorization chain, every autonomous path needs escalation, and multi-agent collaboration must not dissolve responsibility.
Use this before the build decision
Use this model before deciding whether something should become an agent, an extension, a workflow, or a lightweight automation.