Most enterprise processes are not designed. They are inherited.
They begin as a clean workflow in a slide deck, then accumulate exceptions, approvals, spreadsheets, local workarounds, system gaps, and people who know how to get things done because they have been around long enough to remember why the process broke in the first place.
That model can survive in a human-routed organisation. It will not survive multi-agent systems.
As AI agents move from single-purpose assistants to coordinated teams, business processes will need to become more modular. Not because modularity is fashionable, but because agents need work to be decomposed into clear tasks with defined inputs, outputs, permissions, owners, controls, and recovery paths. A messy end-to-end process that relies on tacit knowledge is difficult for humans. For agents, it is a failure machine.
The modular enterprise is the organisation that learns to break monolithic workflows into agent-executable building blocks.
From Workflow Diagrams to Work Contracts
Traditional process design often starts with a diagram. Boxes, arrows, swim lanes, decision diamonds. Useful, but not enough.
Agents need something closer to a contract.
A process module should say what it accepts, what it produces, who owns it, which systems it can touch, which policies constrain it, when it must escalate, what evidence it must retain, and how success is measured. That sounds like engineering language because it is. The next generation of operating-model design will borrow heavily from software architecture.
I once worked with a logistics client whose shipment exception process looked simple on paper: detect delay, notify customer, adjust route, update billing, close exception. In practice, every step depended on somebody knowing which port authority, carrier, customer-service team, and finance contact mattered for that route. The workflow was not a process. It was folklore with a dashboard.
Multi-agent systems expose that weakness quickly. A delay-detection agent can flag the issue. A routing agent can find alternatives. A customer-communication agent can draft a message. A billing agent can check commercial impact. But unless the handoffs are explicit, the agents will either duplicate work, miss context, or escalate everything back to humans.
The answer is not one giant agent. It is modular process design.
Why Multi-Agent Systems Change the Architecture
Deloitte’s 2026 technology predictions argue that agent orchestration will be essential as enterprises move from single-purpose agents to multiagent systems. The report describes orchestration as the coordination of role-specific agents that can interpret requests, design workflows, delegate tasks, coordinate work, and validate outcomes.
That is a different architectural model from traditional automation.
Robotic process automation copied human clicks. Workflow engines moved tickets between queues. Copilots helped individuals draft, summarise, and analyse. Multi-agent systems coordinate pieces of work across domains. They need a process architecture that behaves less like a conveyor belt and more like a set of interoperable services.
Gartner made a similar point when it predicted that 40% of enterprise applications would include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Gartner also described a progression from task-specific agents to collaborative agents inside applications, and then agent ecosystems across applications.
That progression matters. Once agents collaborate, the process boundary shifts. The unit of design is no longer the application screen. It is the business outcome.
Frankly, this is where many enterprise architects should feel both excited and uncomfortable. We spent years modernising applications, APIs, data platforms, and cloud estates. Now the work itself needs the same treatment.
The Process Module
The practical building block is the process module.
Think of a module as a small business capability that can be executed, inspected, reused, and improved. It is not a department. It is not a system. It is a unit of work.
Examples include:
- enrich a supplier profile;
- verify a customer identity document;
- classify a support request;
- reconcile an invoice exception;
- generate a risk summary;
- route an approval;
- prepare a regulatory evidence pack.
Each module should have a clear contract.
The input contract defines what data the module needs, where it comes from, how fresh it must be, and which quality checks apply. The output contract defines what the module returns, in what format, and how downstream agents or humans can use it. The authority contract defines whether the agent can only recommend, can update records, can trigger workflow, or can approve within limits. The control contract defines logging, testing, bias checks, policy rules, human review, and exception handling.
That may sound heavy, but it is lighter than debugging a chain of agents that nobody can explain.
Context Is the New Middleware
Deloitte’s architecture for scalable multiagent systems includes a context layer, an agent layer, and an experience layer. The context layer is especially important because it turns raw and diverse data into structured, governed knowledge that agents can use.
In plain English: agents need a shared understanding of the world.
Without that, each agent builds its own partial reality. The supplier agent sees contract terms. The finance agent sees payment history. The risk agent sees sanctions screening. The operations agent sees delivery performance. If those views are not reconciled, the enterprise gets speed without coherence.
The modular enterprise therefore needs more than APIs. It needs business context that agents can safely retrieve and interpret: taxonomies, policies, knowledge graphs, role definitions, product hierarchies, customer segments, risk tiers, and process states.
This is why data governance becomes operating-model governance. A bad customer master record is no longer just a reporting problem. It can trigger poor agent decisions across sales, service, credit, and compliance. A vague policy document is no longer just legal clutter. It becomes an execution risk if agents cannot apply it consistently.
The bottom line is simple: agents do not remove the need for clean architecture. They punish the absence of it.
Human Roles Move to the Boundaries
In monolithic processes, humans sit everywhere. They check, chase, copy, approve, interpret, reformat, and rescue.
In modular agentic processes, humans should sit at the right boundaries.
Some boundaries are risk boundaries: a high-value payment, a hiring decision, a customer complaint, a regulatory filing, a medical recommendation, or a cyber containment action. Some are ambiguity boundaries: conflicting data, low confidence, missing context, new policy interpretation, or unusual commercial exposure. Some are accountability boundaries: decisions that require a named business owner, not a probabilistic recommendation.
McKinsey’s work on the agentic organisation argues that operating models will evolve toward AI-first workflows and outcome-aligned teams, with humans steering outcomes and selectively remaining in the loop where human contact matters. That is the right direction, but it requires design discipline.
I have seen companies make the opposite mistake. They automate the easy middle and leave humans to stitch together the unclear edges without better tools. That creates a new kind of operational debt: faster fragments, slower outcomes.
The modular enterprise should instead define where humans intervene by design. A human may approve a module’s authority limit. Review exceptions above a threshold. Tune policies. Validate outputs. Investigate incidents. Own the end-to-end outcome. The human role becomes less about manually moving work and more about governing how work moves.
Audit Trails Become Process Telemetry
Multi-agent systems will fail without observability.
Microsoft’s Agent 365 announcement framed this as a control-plane problem: enterprises need registries, access control, visualisation, interoperability, and security for agents. That language matters because multi-agent workflows create many small actions across many systems. If those actions are not visible, the organisation cannot govern them.
For modular processes, audit trails should become process telemetry.
Each module should record the inputs used, the agent or human that acted, the policy applied, the confidence level, the system touched, the output produced, the exception raised, and the evidence retained. That telemetry should be useful to operations, risk, audit, security, and product owners.
This is not only about compliance. It is about improvement.
If a supplier-enrichment module keeps failing because company names are inconsistent, fix the data source. If a routing module escalates too often, tune the thresholds. If a contract-review module performs well for standard contracts but fails on non-English documents, narrow its scope or improve context. Process telemetry turns agentic workflows into something leaders can manage rather than merely admire.
Where to Start
Do not start by mapping the entire enterprise.
Start with one monolithic process that is painful, cross-functional, and measurable. Good candidates include customer onboarding, supplier onboarding, claims handling, month-end close, sales-to-cash, employee onboarding, access provisioning, and incident response.
Then decompose it into modules.
For each module, ask five questions.
- What is the exact outcome?
- What input does it need?
- Who owns the result?
- What can the agent do without approval?
- What evidence must it leave behind?
Once those answers are clear, decide which modules should be automated, which should be agent-assisted, and which should remain human-owned. The goal is not maximum autonomy. The goal is a process that is faster, clearer, easier to control, and easier to change.
Zapier’s enterprise survey found that 72% of enterprises were using or testing AI agents, and 84% of leaders expected to increase AI agent investment over the next 12 months. That investment will not pay off if agents are dropped into broken workflows. It will pay off when workflows are refactored into modules that agents and humans can execute together.
The New Modernisation Agenda
For years, application modernisation meant breaking monoliths into services, exposing APIs, cleaning data, and moving workloads to cloud platforms.
The same logic now applies to business processes.
The monolithic process is the next legacy system. It may not sit in a data centre. It may sit in a shared mailbox, a policy binder, a regional spreadsheet, or the memory of a long-serving operations manager. But it constrains the enterprise just as surely as old code.
The modular enterprise does not mean a company with no humans, no judgement, and no accountability. It means a company where work is decomposed clearly enough that agents can execute the routine, humans can govern the important, and leaders can see how outcomes are produced.
That is the real shift. Multi-agent systems will not reward firms with the most pilots. They will reward firms that can redesign work into clear, governable units. The winners will not simply automate their processes. They will refactor the enterprise itself.