01 A capability needs a complete operating contract
Koko’s proposed unit of design is the capability, supported by a clearly owned outcome. A workflow is a sequence of activities; a function is a professional home; an agent is a means of execution. None is interchangeable with the capability itself.
For a capability such as “fulfill a profitable customer promise,” specify:
| Element | The question leadership must resolve |
|---|---|
| Outcome and owner | What customer or enterprise result matters, and who is answerable for it? |
| Economics | What is the baseline, full cost, capital commitment and measure of realized value? |
| People and expertise | Which skills, judgment and relationships are required? How will people develop them? |
| Data products and knowledge | Which definitions, evidence, policies and context must remain current? |
| Execution | Which work belongs to people, deterministic software, agents or physical systems? |
| Delegated authority | Who may do what, using which data and budget, under what conditions? |
| Feedback and assurance | How are outcomes verified, exceptions resolved and independent challenge provided? |
| Portability | Can the enterprise move the capability or change a supplier without losing control or meaning? |
BCG’s enterprise-as-code perspective supports making operating logic explicit. Koko’s additional test is whether that specification joins economics, authority and verified outcomes in a usable management practice. BCG ↗
02 A working example: From demand signal to cash
Imagine an industrial business with volatile demand. A customer requests an accelerated delivery. Today, commercial, planning, operations, procurement and finance teams may each optimize a different part of the response.
In Koko’s illustrative 2030 design, a customer promise capability combines the relevant people and services. An agent assembles demand, inventory, supplier and credit evidence. Deterministic calculations estimate contribution and cash consequences. A planner tests production feasibility. A commercial owner proposes the offer. Credit and pricing authority remain subject to their established limits. Execution updates the systems of record, and finance reconciles what was promised with what occurred.
The outcome owner can compare margin after expediting, delivery reliability, cash conversion and customer retention. The CIO sees integration failures and recovery time. The CDO sees stale or conflicting definitions. Procurement sees concentration and supplier performance. The CISO sees denied actions and identity exceptions. The CHRO sees the expertise needed to supervise and improve the work.
This is a hypothetical design, not a reported case. The important change is that the customer outcome has a single operating view while professional responsibilities remain visible.
A successful demonstration must include a difficult case: conflicting inventory, a late supplier, an invalid credit instruction or an unavailable system. A capability that works only when every input is clean is not ready for broader delegation.
03 The architecture and the organization must fit each other
Headless SaaS means software capabilities can be used through APIs or other interfaces without relying on the supplier’s screens. An orchestration layer coordinates those capabilities and agents. Knowledge engineering makes business definitions, relationships, policies and decision context explicit enough to maintain and reuse.
These changes could reduce the friction between functional applications. They can also create a new concentration of dependency in whoever owns the orchestration environment or enterprise context.
EY describes an emerging knowledge and orchestration infrastructure. Foundation Capital argues that decision records could become important software assets; a16z provides a countercase in which incumbent systems retain power through their data and permitted actions. These are competing views of where value may accumulate. EY ↗ Foundation Capital ↗ Andreessen Horowitz ↗
Koko’s implication: own the meaning, authority and outcome evidence that make a capability dependable; choose deliberately which execution components to buy, build or partner for.
Keep deterministic calculations and authoritative records where they belong. Require versioned policies, data lineage, scoped permissions, budget limits, recovery and exportable evidence. Open protocols can simplify connections; they do not automatically align semantics, contracts or risk obligations. NIST ↗ NIST ↗ BCG ↗
04 The funding model must change with the work
If every function funds its own agents, the enterprise can pay repeatedly for the same context, integration and control. If everything becomes a centralized platform project, teams can wait too long for usable outcomes.
Koko proposes three connected investment categories:
- Shared foundations: identity, trusted data, reusable knowledge, integration, evaluation, security and recovery. Name the capability consumers and measure adoption and service quality.
- Outcome delivery: a bounded customer or enterprise capability with a business owner, baseline and measurable decision gate. Include transition, supervision and maintenance costs.
- Strategic options: smaller commitments that buy learning about physical AI, quantum, new service models or changing customer behavior. State what evidence would justify the next commitment.
Do not impose a universal spending percentage. Start from obligations, bottlenecks, enterprise economics and risk appetite. Oliver Wyman’s research highlights the danger of increasing AI spending without adequately funding the conditions for productive use. PwC’s GBS perspective broadens the cost comparison beyond labor rates. Oliver Wyman ↗ PwC ↗
05 What would weaken the capability-based hypothesis?
Capability organization may add a matrix without removing old handoffs. Shared platforms may become bottlenecks. Local context may be too specific to justify extensive reuse. Some customers may value a named expert and stable relationship more than faster automated service. Regional obligations can make a globally uniform capability inappropriate.
The test is practical: does the redesigned capability improve outcomes after coordination, control, transition and run costs? Does it preserve professional quality and develop future expertise? Can leaders resolve conflicts more effectively?
Compare with a credible alternative, such as a well-run functional model with better integration. If the capability model does not improve the result, narrow the change. The hypothesis is about better enterprise performance, not a preferred organization chart.