The Delegated Action Architecture

An agentic system exists to produce an outcome. The outcome gives work design, authority, execution, assurance, and economics a shared reference point.

The outcome must be concrete enough for the enterprise to recognize success.

Examples include:

• ·Resolve a customer delivery exception within a defined service window.
• ·Produce an approved technical change plan with complete evidence.
• ·Reconcile a financial discrepancy and prepare an authorized correction.
• ·Identify a production incident, coordinate response, and restore service within an agreed recovery objective.

The outcome architecture establishes five elements:

The acceptance boundary is central.

An agent may generate useful activity, summaries, drafts, recommendations, decisions, or actions. The enterprise receives value when the output enters the operating system as accepted work and contributes to an observable business outcome.

Agentic capability becomes operational when the enterprise determines what a system may do, under whose delegation, and within which boundaries.

Authority includes more than system access.

It includes recommendation rights, decision rights, approval rights, execution rights, override rights, escalation rights, and termination rights.

Each workflow requires an authority map.

Authority creates an operating envelope.

This authority map applies the delegation dimensions in Agentic Execution, Chapter 06. The Computational Coordination Architecture (FW 20) specifies delegation for coordination commitments.

A customer service agent may resolve a routine delivery problem within a defined commercial threshold. An engineering agent may prepare and validate a change plan, then enter a controlled approval path for deployment. A finance agent may investigate a variance and prepare a correction package for an authorized owner.

Each example has a different operating envelope because each creates a different consequence.

Execution architecture defines how work moves from an initiating signal to an accepted outcome.

A complete execution path includes:

• ·An event, request, schedule, or signal creates a task.
• ·The system assembles relevant context.
• ·The agent interprets the situation and selects an available next action.
• ·Tools carry the action into enterprise systems.
• ·The system records state, evidence, and resulting conditions.
• ·The workflow proceeds, escalates, pauses, or concludes.
• ·Assurance validates the final outcome.

The execution architecture must account for the realities of distributed enterprise work.

Calls can time out. Systems can return conflicting records. An external service can complete an action before the agent receives confirmation. A workflow can require approval, rework, cancellation, or compensation.

The system therefore needs durable state, clear transaction boundaries, recovery paths, idempotent actions, escalation points, and outcome verification.

The agent provides adaptive reasoning inside this execution environment. The environment provides continuity, resilience, and accountable action.

Agentic systems act through the information available at the moment of execution. Context can include enterprise records, documents, policies, workflow history, customer interactions, tool results, semantic models, and external information.

Context quality shapes action quality.

The context architecture establishes how information enters the execution environment and how the enterprise manages its relevance, freshness, permissions, provenance, and correction.

The architecture distinguishes between state, memory, and provenance.

State records the current condition of a task.

Memory carries information forward for future use.

Evidence establishes the basis for a decision or outcome.

Each has a different operating purpose and lifecycle.

A useful system can surface conflicting claims from Finance, Operations, Customer Service, or Engineering. It can preserve the source, owner, and timing of each claim. It can direct the conflict toward the appropriate authority.

This produces an enterprise execution environment grounded in accountable information.

Assurance connects agentic activity to operational confidence.

The enterprise needs to observe what the system did, evaluate the quality of its work, validate the resulting condition, and intervene when evidence indicates a material risk or opportunity.

Assurance operates across the full lifecycle of agentic execution.

A fluent response demonstrates language capability.

An accepted outcome demonstrates operating capability.

The distinction is central.

A support agent may prepare an excellent resolution summary while the customer issue remains active. An engineering agent may generate a strong remediation plan while production risk remains unresolved. A finance agent may identify a variance while the underlying records continue to diverge.

Assurance follows the work through the boundary between produced output and verified business consequence.

The system earns broader authority through evidence.

Agentic systems consume models, infrastructure, tools, integration capacity, review time, operational attention, and management effort.

They can also release human capacity, improve quality, increase throughput, reduce delay, avoid future cost, create revenue, and strengthen resilience.

Economic architecture connects these effects.

The central metric is:

Cost per Accepted Outcome = (Human Cost + AI Cost + Infrastructure Cost + Tools and Integration Cost + Review and Recovery Cost + Allocated Transformation Cost) ÷ Accepted Outcomes

Define one measurement period and one outcome class before calculating the measure. All costs and accepted outcomes must refer to that same scope. Count each distinct outcome once, only when it meets the stated acceptance criteria. Generated outputs, intermediate actions, failed attempts, and retries do not enter the accepted-outcome denominator.

Include the costs of failed attempts, rejected work, retries, review, and recovery in the numerator, even when they produce no accepted outcome. Allocate shared tools, integration, and infrastructure to the workflow using a stated, consistent basis such as attributable usage. Allocate transformation investment over a disclosed useful-life horizon and charge the measurement period only its share, rather than counting the same investment in full in every period.

Value human execution, review, and recovery labor using recorded time and a disclosed cost rate. Assign each cost once so that labor, platform, integration, and shared-service charges are not duplicated across categories. Use the same period, allocation rules, and acceptance criteria when comparing workflows. If no outcomes are accepted, report the incurred cost and zero accepted outcomes separately. Cost per accepted outcome is undefined, not zero.

This measure connects the complete operating system to a result the enterprise can use.

It also creates a meaningful comparison with the existing workflow.

Capacity has several possible destinations.

It can expand customer coverage, absorb growth, improve service quality, reduce existing expenditure, avoid future hiring, accelerate delivery, or support higher value work.

The economic consequence appears when the enterprise deliberately directs recovered capacity toward a measurable result.

The framework therefore follows the full path:

Accepted Outcome→Capacity Released→Capacity Destination→Operating Consequence→Financial Consequence