Execution Architecture: Deciding Who or What Does the Work

A customer asks for a refund. The payment system confirms the purchase, the returns policy describes the conditions, and a customer service adviser decides what should happen. Introduce an AI agent capable of reading the request, checking the records and preparing a response, and a familiar question follows: can we automate this?

That question brings several decisions together. Understanding a complaint, checking eligibility, authorising a refund and transferring money are different responsibilities. An agent might perform one well without being suitable, or authorised, to perform the others. Demonstrating that it can complete a straightforward case tells us relatively little about how responsibility should be distributed across the whole service.

In the previous article, we argued that work needs an architectural description independent of its current executor. Once that description exists, the next question becomes more precise: who or what should perform the work, under which conditions, and what should happen when those conditions are not met?

Capability does not confer authority

Organisations already understand this distinction when assigning work to people. An experienced adviser may know exactly how to resolve a complaint but still need approval for a refund above a certain amount. A colleague with access to payment records does not automatically have permission to change them. Knowledge, access and authority serve different purposes.

The same reasoning should apply when software or AI participates. An agent’s ability to recommend a refund is not a reason to give it unrestricted payment access. Authority needs explicit boundaries, enforced by the systems through which actions occur. A written instruction asking an agent to respect a limit is not equivalent to a payment service that refuses transactions outside it.

This is where Execution Architecture becomes useful. It describes how work is assigned to people, applications, services and AI, together with the information, permissions and controls each requires. It also describes how their contributions connect. A workflow shows the route through the work; Execution Architecture makes explicit the conditions under which a particular executor may take responsibility for part of that route.

The right arrangement depends on the case

Consider a retailer designing its refund service. Conventional software could check whether an order exists, calculate the amount paid and apply clearly defined return conditions. An AI component could interpret an unstructured customer message and identify missing information. An adviser could consider circumstances that the standard policy does not adequately address.

There is little reason to ask a language model to calculate a refund that existing software can calculate reliably. Equally, forcing a distressed customer’s explanation into a rigid form may create avoidable friction. The choice should follow the requirements of the work, including the consequences of getting it wrong, rather than a preference for one technology.

Even within that arrangement, different cases may need different treatment. A low-value return supported by complete records might qualify for automatic approval. Conflicting evidence or a disputed decision could require review. These routes need defined entry conditions. An agent sounding confident is not sufficient evidence that a case is safe to automate.

The practical unit of change may therefore be smaller than “automate refunds”. It could be preparing the evidence for a decision, removing a redundant check or changing who can approve a particular category of request. Sometimes examining these responsibilities reveals that the task itself needs redesigning.

Handoffs and failures belong in the design

It is tempting to draw a box labelled “human review” and consider the difficult cases covered. That box represents a real operational commitment. Someone must be available, have enough time to investigate and possess the authority to act. They also need access to the original evidence, not just the agent’s summary of it.

Suppose a customer says that an item was returned, while the warehouse record says otherwise. Passing the case to an adviser without the delivery history merely moves the problem. A useful handoff preserves the relevant information, explains what remains unresolved and identifies any actions already taken. Otherwise, the customer repeats the story and the organisation pays twice for the investigation.

Failures between systems need similar attention. If a payment request times out, the service must establish whether the refund occurred before trying again. Redirecting the case to another executor does not undo a payment already made. Execution Architecture must account for incomplete work and recovery, as well as the successful path.

Human involvement is not automatically a guarantee of quality either. An overloaded reviewer may approve recommendations without examining them. The arrangement needs to be evaluated as a whole, including whether its supervision is workable at the expected volume.

Execution choices should remain open to revision

A credible decision compares more than the cost of running an agent with the cost of an employee’s time. Integration, supervision and the effort of correcting mistakes all contribute to the cost of delivering an acceptable outcome. A faster initial response offers limited value if customers repeatedly return because their problem remains unresolved.

An organisation could begin by using AI to prepare refund assessments while advisers retain decision authority. It could then compare results across different kinds of cases, examining errors and customer outcomes alongside handling time. Evidence might justify greater automation in a bounded area. It might also show that the existing arrangement works better.

This is the role Execution Architecture plays within NativeWork. Making work explicit provides a basis for evaluating and changing its execution while keeping purpose, authority and required evidence visible. It does not remove the need for integration, management decisions or judgement about which risks are acceptable.

Over time, such changes may alter team responsibilities and the wider process. Continuous Enterprise Evolution requires room for those changes, rather than permanently preserving today’s organisation beneath new technology.

For the customer waiting for a refund, the important outcome is a fair resolution without unnecessary effort. Choosing the executor is part of delivering that outcome. Good architecture makes that choice deliberate, gives it enforceable boundaries and provides a way to recognise when it should change.

About NativeWork

NativeWork™ is an AI-native Enterprise Architecture standard and method developed by Centipod. It places work at the centre of enterprise design and provides an architectural foundation for Continuous Enterprise Evolution.

WorkML™ is the accompanying language for expressing NativeWork architectures in a form designed for both people and intelligent systems.

Learn more at nativework.org.

NativeWork™ and WorkML™ are trademarks of Centipod. Trademark applications are pending.

This article was created by people. We have used artificial intelligence (AI) to help articulate our message and refine the text. AI was employed as a tool to assist with structuring, identifying grammatical and spelling errors, and improving readability. The final document has been carefully reviewed and approved by our team.