ERP, CRM, HR and procurement platforms have brought enormous benefits in standardisation, consistency and control, but they have also embedded particular assumptions about how work should be organised. Processes, responsibilities and decisions have often been designed around the applications available to support them, with significant cost and disruption involved in changing the arrangements later.
Agentic AI is beginning to loosen some of these constraints. Recent developments from companies including Serval, SAP and Procol point towards an emerging architectural pattern in which three responsibilities that have traditionally been bundled together can evolve more independently:
systems of record that preserve authoritative information and transactions,
capability interfaces that expose what an organisation can do, and
execution systems that coordinate people, agents and software to achieve outcomes.
We have been exploring this opportunity from a practical direction in our recent work designing agentic workflows with large organisations. As Lee discussed in a previous edition, the starting point is to understand the organisational capability we want to create, the people it serves and the outcomes it should deliver. Following the actual work, rather than simply automating documented processes, often reveals a complicated landscape of applications, informal coordination, workarounds, decisions and knowledge that nobody has fully mapped.
One lesson emerging from this work is that the freedom to redesign a workflow does not necessarily come with control over everything it depends on: a team might own the experience and orchestration of a service, manage the agents and rules that support it, but have only limited influence over the systems, information and decisions maintained elsewhere in the organisation. And as agents begin to act across these boundaries, questions about shared context, authority, accountability and organisational learning become increasingly important.
This week’s leadership technique offers a way to examine those distinctions, using the emerging separation of records, capabilities and execution to identify new opportunities for redesign, alongside the responsibilities and dependencies that will determine whether they succeed.
Three layers, three different responsibilities
The idea of separating enterprise software into distinct layers is not entirely new. Service-oriented architectures, APIs and modular platforms have been moving us in this direction for years. What is changing is the potential for AI agents to coordinate work across these components, interpret context and handle some of the variation and complexity that previously required tightly integrated applications or considerable human effort.
Systems of record preserve what is authoritative. These are the applications and databases responsible for maintaining business information, transactions and operational state. They might include an ERP holding financial records, a CRM maintaining customer information, or a specialist platform managing contracts. Their value lies in reliability, integrity, consistency and control. Even when the way work is performed changes dramatically, the organisation still needs to know which information is authoritative and who is permitted to change it.
Capability interfaces expose what the organisation can do. They make specific functions available to other systems, applications and agents, such as checking a supplier’s status, calculating a price, validating a request or initiating an approval. Some may be existing services exposed through APIs, while others might involve agent skills, business rules or newly developed components.
Execution systems coordinate how work gets done. This is where people, agents and software come together to deliver outcomes. An execution system might interpret a request, determine which capabilities are needed, coordinate specialist agents, involve people where judgement or approval is required, and track progress towards completion. It can provide a more coherent experience across the organisation’s existing systems without necessarily taking over their underlying responsibilities.
Consider a relatively ordinary employee request that requires information and actions from HR, finance and IT. Today, completing it might involve several applications, forms, email exchanges and manual handoffs. In a more composable architecture, an execution system could coordinate the request through a single experience, drawing on reusable capabilities while the relevant enterprise applications continue to maintain their authoritative records.
These distinctions are also becoming visible in debates about the future of enterprise systems of record. Some argue that established enterprise applications will remain the authoritative home for business transactions, with a new layer of agentic middleware coordinating work across them. Others, including Databricks and its backers, envisage a broader role for data platforms that can combine operational records, shared business context, intelligence and agent execution. The question is whether the system of record itself evolves to accommodate agentic work, or whether new systems of action develop around existing records. Both approaches could support more flexible workflows, but they imply different choices about where information, authority and organisational knowledge should reside.
There is also a further complication. Authoritative records alone do not give agents everything they need to act reliably. They need to understand what information means, how business concepts relate to one another, which rules and permissions apply, and what has been learned from previous decisions. Shared context, authority and evidence therefore need attention across the architecture, regardless of which platforms ultimately provide them.
Leadership technique: Separate, Map, Reimagine
The emerging architecture offers a useful lens for leaders looking to redesign how work happens, even if their organisation is some way from implementing it. The starting point is to choose a workflow that matters, ideally one that crosses organisational or system boundaries, involves significant coordination, or creates friction for the people using it.
The technique has three stages: Separate the capability from its current implementation, Map the responsibilities and dependencies that support it, and Reimagine how the outcome could be delivered with greater flexibility.
1. Separate: Start with the capability
Begin by setting aside the applications, process steps and departmental boundaries that currently define the workflow. Ask what organisational capability you are trying to create or improve, who benefits from it, and most importantly what a successful outcome looks like.
For example, a team might describe its work as processing employee onboarding forms, managing approval queues or updating records across several systems. These activities may be necessary today, but the underlying capability is to help new employees become productive, connected and appropriately equipped to do their jobs.
That distinction opens up a different design conversation. What does a good onboarding experience require? Which activities genuinely contribute to that outcome? Which exist because of limitations in existing systems or historical organisational arrangements? It is important to follow the real work rather than rely exclusively on documented processes. Observe the handoffs, exceptions, informal decisions and workarounds that reveal how the organisation actually operates. Some of these may be unnecessary complications, while others contain valuable knowledge about what the capability needs to deliver.
2. Map: Understand the architecture and your sphere of control
With the capability defined, examine what is required to deliver it. Use the three architectural responsibilities as a starting point:
Records: What information and transactions must be maintained, and where does authority over them reside?
Capabilities: What functions, actions and decisions are needed? Which already exist, and which might be reusable across other workflows?
Execution: How is work coordinated today, including the roles played by people, applications and informal communication?
Then look beyond these layers to the shared context, permissions, business rules and accumulated knowledge that make the workflow dependable. Where are decisions recorded? How are exceptions handled? What evidence is retained, and how does the organisation learn from what happens?
At this point, introduce a second lens: what do you own, what do you manage, and what can you only influence?
Ownership means having the authority and accountability to make decisions about a component or capability. Management means responsibility for its day-to-day operation, performance or improvement, potentially within boundaries set by someone else. Influence means depending on something outside your direct control, where change requires cooperation, negotiation or agreement.
A team redesigning employee onboarding, for example, might own the overall employee experience and manage the workflow that coordinates it, while depending on HR, IT, security and finance teams for authoritative records, access permissions, equipment and approvals. It may be able to improve the coordination of these activities without having the authority to change every underlying system or policy.
3. Reimagine: Design for the outcome
Which functions could be exposed as reusable services or agent skills? Where could specialist agents gather information, interpret requests or coordinate actions? Which decisions need human judgement, and where could automation proceed safely within agreed boundaries? Could the organisation offer a single, coherent experience while retaining several existing systems of record?
For employee onboarding, this might mean replacing a collection of disconnected requests and manual follow-ups with a coordinated workflow that understands the employee’s role, initiates the necessary actions, tracks progress and brings people into the process when decisions or exceptions require attention.
The opportunity is also to reconsider whether every existing activity needs to happen at all. Removing unnecessary approvals, improving information quality or simplifying responsibilities may create more value than automating the current sequence of tasks.
Use the ownership map to distinguish between changes that can be made directly, those that require shared design with other teams, and those that depend on broader organisational decisions. This helps establish a realistic path forward without allowing existing constraints to determine the full extent of the ambition.
Finally, consider how the redesigned workflow will remain observable and capable of improvement. People need sufficient visibility to understand what agents are doing, intervene when necessary and retain the knowledge required to exercise meaningful judgement.
The new responsibilities of organisational design
When a workflow is largely contained within one enterprise application, many of its rules, permissions and dependencies are embedded in that system. As execution becomes more flexible and distributed, these arrangements need to be made more explicit.
There are several responsibilities that leaders need to consider as part of the design:
Preserving authoritative information. An execution system may provide a unified view of work, but that does not necessarily make it the authoritative source for everything it displays. Organisations need to establish which systems maintain particular records, who can change them, and how information remains consistent across different applications. New workflows may also create records of their own, such as requests, decisions and progress, which need clear ownership and retention arrangements.
Maintaining shared meaning. Reliable execution depends on more than access to data. People and agents need consistent definitions of customers, suppliers, products, responsibilities and business rules, together with an understanding of the relationships and exceptions that give this information meaning. Much of this context currently lives in documents, individual expertise or informal working practices. Making it available and maintaining its quality becomes an important organisational capability in its own right.
Defining authority and accountability. As agents take on more responsibility for coordinating and performing work, organisations need explicit boundaries around what they can do independently, what requires approval and who remains accountable for the outcome. These boundaries may differ across functions, risk levels and types of decision. They also need to be maintained as policies, systems and organisational responsibilities change.
Preserving evidence and learning. A workflow that successfully completes a transaction has produced an outcome, but it may also have generated valuable knowledge. Why was an exception escalated? What judgement did a human apply? Which information proved unreliable? What changed as a result? Capturing this evidence helps organisations evaluate agent performance, improve their capabilities and retain institutional knowledge as execution becomes increasingly automated.
Read on to learn more about the impact on those redesigning work.
