Building an Agentic Workflow? Delegate the work. Keep control of what matters.

As organizations rush to deploy AI agents, much of the attention is on orchestration: which agent does what, which tools it uses, and how work gets handed from one agent to another.

But orchestration is only part of the problem.

A team of agents is easy to assemble. A system of work you can trust is considerably harder to design.

The distinction matters because an agentic workflow isn't simply a sequence of tasks. It is an operating system of people, AI agents, decisions, policies, evidence, authority, and consequential actions.

And once you introduce autonomous participants, you need to answer three fundamentally different questions.

I call this semantic completeness and fidelity.

Have we adequately described the Work System, including what is known, unknown, and assumed?

That means understanding more than the order in which activities occur.

What work must be performed? How does it progress? Who participates? What evidence grounds decisions? Who has the authority to act? And what makes the outcome official?

A Work System may contain sequential paths, tasks, and formations of humans and agents working together through different coordination arrangements.

For example, an accounts-payable process might combine a deterministic invoice-matching sequence, a lead directing specialist agents to investigate discrepancies, and a committee adjudicating exceptional cases.

These are different ways of coordinating work. Treating them all as generic workflow steps destroys important information about how decisions are made and accountability is maintained.

Before we automate work, we need a faithful model of the work itself.

I call this control responsibility and enforcement.

An AI agent proposing an action is not the same as deciding that the action is appropriate.

A decision is not necessarily authorization.

Authorization is not execution.

And execution does not automatically mean the business outcome has been verified or officially settled.

These distinctions suggest six control responsibilities:

1. 1

   Proposal

2. 2

   Adjudication

3. 3

   Authorization

4. 4

   Execution

5. 5

   Verification

6. 6

   Settlement

They are not necessarily six sequential runtime stages. They are distinct responsibilities that a Work System must account for.

Consider an AI agent investigating a supplier invoice.

It can propose releasing payment. A designated authority may adjudicate an exception. A policy service may verify the necessary approval. A payment system may execute the transfer. Another system may confirm the transaction and reconcile the financial records.

Collapsing these responsibilities into a single agent prompt is convenient, but it obscures who is accountable for what.

And that's where the sovereignty question becomes unavoidable.

I call this readiness — fitness for a purpose.

A Work System can be sufficiently described to simulate without being ready to execute.

We might understand its tasks, formations, participants, and policies well enough to estimate throughput, cost, and bottlenecks.

But that doesn't mean the relevant permissions have been granted, the required integrations exist, or the designated runtime can enforce its constraints.

Similarly, a workflow can execute successfully without having sufficient evidence to establish that its intended business outcome has been achieved.

We should therefore distinguish design completeness, simulation readiness, authorization readiness, and execution readiness rather than compressing them into a generic green checkmark.

Delegating execution is not the same as delegating control. And delegating control is not necessarily the same as surrendering sovereignty.

A third party can operate an externally hosted control plane under enterprise-defined rules.

The more important question is whether the enterprise retains the authoritative specification, can independently verify compliance, and can revoke, transfer, or replace that operator.

This is a familiar problem.

We faced variations of it with enterprise data, cloud infrastructure, and AI models. Now we're encountering it again with agentic systems, except the stakes increasingly involve operational decisions and real-world effects.

Imagine handing a complete Work Order to a third-party agent platform.

What exactly have we handed over?

Perhaps only the ability to conduct a multi-turn conversation and route work among specialist agents.

Or perhaps we've also delegated the right to determine the next workflow state, adjudicate exceptions, interpret policies, invoke consequential tools, and declare the work complete.

Those are very different arrangements.

And sovereignty isn't simply a decision to retain everything or outsource everything.

An organization might delegate:

• Conversation control, while retaining durable state and auditability.
• Work progression, while retaining mandatory deterministic gates.
• Adjudication support, while retaining binding decision rules and designated decision authority.
• Execution, while retaining authorization, tool limits, and revocation rights.
• Evidence collection, while retaining authoritative records and independent verification.
• Settlement operations, while retaining the rules defining what constitutes an official outcome.

The critical distinction is between who owns the authority, who operates the control, and who holds the authoritative state.

These do not have to be the same entity.

But they must be deliberately specified.

This leads to an architectural challenge that I believe deserves more attention.

We need a reliable way to move from a canonical model of a Work System to its runtime and authority-control system.

The canonical model describes the work:

Tasks · Paths · Formations · Participants · Requirements · Policies · Evidence · Effects

The runtime control system governs what happens when that design is instantiated:

Proposal · Adjudication · Authorization · Execution · Verification · Settlement

The two should be connected without being conflated.

A policy extracted during Work System design should not become a loosely worded instruction buried inside an agent's prompt.

It should retain its meaning, provenance, scope, and relationship to the control responsible for applying it.

Similarly, an external executor should receive a scoped Work Order containing the context, capabilities, constraints, and obligations needed to perform the assigned work—not automatically inherit authority over the entire business process.

This is where deterministic control, agentic flexibility, and enterprise sovereignty can coexist.

The model describes what the work is. The control system determines what may happen. The runtime performs the permitted work. The evidence establishes what actually happened.