Start a conversation

Govern how work gets done.

Suggested Operating Model Architecture separates what your business must be able to do from who or what performs the work—so execution can change while purpose and accountability endure.

Explore the architecture
Interlocking blue and pearl portals surrounding a clear central opening

Keep the purpose.
Reconsider the performer.

AI changes who can do the work. The enterprise still needs to decide who may do it, on what terms and with what evidence.

SOMA is a logical architecture for making those choices explicit, governed and revisable. It connects business capability to the selection of people, AI agents, conventional software and external platforms, without tying the business to today’s teams or technology.

Developed by Workforce 2040 co-founder Andrew Stallwood-Keegan in The Last Architecture, SOMA is a proposition to test and adapt. “Suggested” is deliberate: the architecture can support many operating models.

From business purpose
to accountable action.

Define the capability. Understand the work. Select an eligible execution pattern. Observe the outcome and use the evidence to revise future choices.

Policy, identity and delegated authority constrain the whole flow. Governance and control use the evidence to change what is designed, permitted or selected. The institution remains accountable for delegated work.

AI-native does not mean AI-first. The right choice depends on the work.

Constraints throughout

Policy · Identity · Delegated authority

  1. Capability & purpose
  2. Work class & work item
  3. Work Allocator
  4. Explicit execution pattern
  5. Outcome & evidence

Governance & controlEvidence informs changes across the loop.

A logical architecture, adaptable to your enterprise.
01

Capability & purpose

Define what the enterprise must be able to achieve, the standards it must meet and who owns the outcome. Connect capabilities through their information, dependencies and controls, independently of today’s teams and systems.

What must the business be able to do?

02

Work class & work item

Distinguish the kinds of work within a capability, then consider the actual case. Complexity, sensitivity, jurisdiction and consequence can change who is eligible to act—even when the business outcome is the same.

What does this particular case require?

03

Work Allocator

Establish eligibility before choosing an execution pattern. Assess competence, permission, data restrictions and current availability; then consider capacity, full cost and resilience. If no legitimate route exists, defer, escalate or refuse the work.

Which permitted choice fits this work now?

04

Explicit execution pattern

Make clear who or what prepares, recommends, decides, acts and verifies. A pattern may combine people, AI agents, conventional software and external platforms. Every role has defined authority; human oversight needs the evidence, time and power to intervene.

Who does what, under whose authority?

05

Outcome & evidence

Follow the work through to its business outcome. Retain evidence of the allocation, actors, authority, actions and result, proportionate to the consequences. Use it to revise the design, permissions or future allocation—including narrowing or stopping execution.

What happened, and what should change?

One capability.
Different execution choices.

Resolve a post-trade exception accurately, on time and with a defensible record. The route depends on the case.

Known operational mismatch

A bounded, approved route.

An eligible AI agent gathers and compares evidence. A conventional service may apply a narrowly authorised correction, with independent checks on authority and business state.

Commercial or policy ambiguity

Judgement with authority.

The work goes to an authorised person for interpretation and decision. Clear evidence and decision rights make that intervention meaningful.

Missing evidence or authority

Pause before proceeding.

If there is no legitimate execution route, defer or escalate. Reassess the case and the permitted options before work resumes.

A constructed example adapted from The Last Architecture, not a client case study. In every route, assess the business outcome—not simply whether a tool ran or a case closed.

Start with one
live capability.

Make the current work visible before changing who performs it.

Define the outcome, name an owner with real decision rights and understand the work classes, current actors and dependencies. Make existing allocation choices explicit; start with the systems and controls already in place.

Test a bounded change with clear permissions, useful evidence and a credible fallback. Assess the whole execution pattern—including human review, rework, recovery and cost. Use the results to extend, revise or withdraw the change, then consider connected capabilities.

Explore work and capability assessments

Make your next execution choice a governed one.

Discuss SOMA