The middle of the integration stack converts an authorized task envelope into a sequence of bounded decisions and enterprise operations. This is where most operational complexity appears: planning, tool selection, workflow state, model routing, connector behavior, retries, compensation, and verification.
4B.11 The execution stack
The execution stack begins only after identity, policy, task class, and context have been established. Its input is not an unstructured prompt but a governed task envelope. Its output is either a verified business result, a structured draft, a request for approval, or an explicit exception.
These layers should not be implemented as one opaque agent loop. An opaque loop makes it difficult to determine which step failed, why a tool was selected, what state was persisted, whether a retry is safe, and which component is accountable for recovery.
4B.12 Layer 6 — Orchestration
The orchestration layer coordinates tasks across models, agents, tools, human approvals, and enterprise systems. It owns the control flow, but it should not own authoritative business records. Its responsibilities include task decomposition, step sequencing, state transitions, branching, parallel work, timeouts, retries, escalation, and termination.
Translate business intent into bounded steps with explicit inputs, outputs, and allowed capabilities.
Store step status, approvals, operation IDs, deadlines, and recovery data outside the model context.
Prevent unregistered tools, unsupported recursion, uncontrolled loops, and actions outside task policy.
Orchestration patterns
| Pattern | Use case | Primary control | Main risk |
|---|---|---|---|
| Deterministic workflow | Known business process with model-assisted steps | Workflow engine owns sequence and state | Rigid design if task genuinely requires adaptation |
| Planner-executor | Variable task with bounded tools | Plan validation before execution | Plan can omit required controls |
| Supervisor-agent | Multiple specialized agents | Supervisor limits handoffs and context | Supervisor becomes a privileged single point |
| Event-driven orchestration | Incident, monitoring, document, or process events | Durable events and idempotent consumers | Duplicate or out-of-order processing |
| Human-in-the-loop | High-impact or ambiguous decisions | Structured approval task and expiry | Approval becomes a rubber stamp |
The correct pattern is the lowest-complexity design that meets the use case. Multi-agent systems are justified when agents need separate tool scopes, domain ownership, model configurations, or lifecycle controls. They should not be introduced merely to imitate an organizational chart.
Durable workflow state
Conversation history is not a workflow database. A long-running process may wait for hours or days, survive deployment, receive duplicate events, and require compensation. The workflow state should record each transition and the exact operation identifier used for any side effect.
{
"workflow_id": "wf_88421",
"task_class": "supplier_onboarding",
"status": "awaiting_approval",
"current_step": "finance_risk_review",
"completed_steps": [
"identity_validation",
"supplier_record_match",
"document_extraction"
],
"pending_approval": {
"role": "finance_risk_approver",
"expires_at": "2026-07-25T12:00:00Z"
},
"operations": [
{"id":"op_221","capability":"erp.supplier.create-draft","status":"verified"}
],
"compensation_plan": "supplier_onboarding_v3"
}4B.13 Layer 7 — Model execution
The model execution layer provides language, reasoning, extraction, classification, ranking, and multimodal capabilities. It should be treated as a controlled portfolio of services rather than a single universal model. Tasks differ in required quality, latency, cost, context, geography, and data handling.
Model roles
| Role | Typical task | Control focus |
|---|---|---|
| Classifier | Task, intent, risk, document type | Stable labels, threshold, fallback |
| Extractor | Structured fields from text or images | Schema adherence and source offsets |
| Reasoner | Plan, compare evidence, generate recommendation | Grounding, tool boundary, uncertainty |
| Generator | Draft email, report, policy explanation | Tone, prohibited content, citation |
| Verifier | Check evidence, policy, consistency, or output | Independence from original generation path |
| Embedding / reranking | Retrieval and relevance | Access filtering, index version, evaluation |
A model router should select from approved deployments based on the governed task envelope. A fallback must preserve classification, geography, safety, and task requirements. Silent fallback to a weaker or differently governed model is an availability improvement only if it remains compliant.
Structured output
Whenever model output drives another system, use a structured contract. Schema validation catches syntax errors, but domain validation must still confirm business meaning. Enumerations, numeric ranges, identifiers, and required evidence should be checked outside the model.
{
"decision": "prepare_change",
"target_service": "payments-api",
"requested_capability": "service.change.prepare",
"parameters": {
"change_type": "feature_flag",
"flag": "fallback-mode",
"desired_state": true
},
"evidence_refs": ["incident:INC-88421","trace:tr_442"],
"uncertainty": [
"current customer impact not independently confirmed"
],
"requires_human_approval": true
}Model isolation
The model should not receive raw credentials, unrestricted network access, or tool implementations. It receives capability descriptions and the minimum context required to make a bounded decision. Sensitive tool outputs should be filtered before returning to the model, especially when the output contains secrets, personal data, or internal infrastructure detail.
4B.14 Layer 8 — Capability routing
The capability layer defines what the AI system is allowed to do. It converts raw system endpoints into stable, business-level operations with ownership, schemas, risk tiers, policy, and verification. This layer is the durable contract between agent reasoning and enterprise execution.
Capability maturity
| Level | Example | Risk |
|---|---|---|
| Raw primitive | Run SQL, shell, arbitrary HTTP | Very high; broad and difficult to govern |
| System endpoint | POST /refunds | Technical contract without full business meaning |
| Domain operation | Create refund draft | Bounded action with domain validation |
| Governed business capability | Prepare refund for approval within account and amount scope | Explicit owner, policy, evidence, approval, verification |
A capability registry should contain the business and technical owner, lifecycle state, schema version, risk tier, allowed agents, required data classifications, authorization policy, approval rules, service-level expectation, idempotency behavior, audit retention, and compensation path.
capability:
id: crm.account.note.create-draft
version: 2.1
business_owner: Customer Operations
technical_owner: CRM Platform
lifecycle: production
effect: draft_only
input_schema: crm-note-draft-v2.json
authorization_policy: crm-account-scope-v4
allowed_agents:
- account-assistant
- support-assistant
idempotency: required
verification:
type: target_readback
audit_retention_days: 25554B.15 Layer 9 — Enterprise connectors
Connectors translate governed capabilities into target-system operations. They handle authentication, protocol, schema transformation, retries, rate limits, target-specific errors, and post-condition verification. Connectors should be thin enough to remain maintainable but rich enough to preserve system semantics.
Connector responsibilities
Convert canonical business inputs into target-system fields, identifiers, and protocol.
Use scoped identity, network policy, quotas, schema checks, and target preconditions.
Read back or independently confirm the intended state rather than trusting a generic success message.
Connector types
| Connector | Typical target | Important behavior |
|---|---|---|
| API connector | SaaS, microservice, platform API | Version, rate limit, idempotency, structured errors |
| Event connector | Bus, topic, webhook | Delivery semantics, ordering, replay, schema registry |
| Queue connector | Asynchronous worker or batch | Visibility timeout, deduplication, dead-letter queue |
| Workflow connector | BPM, ITSM, approval platform | Durable state, human task, escalation, correlation |
| Database facade | Legacy or specialized data store | Read-only queries, canonical schema, query limits |
| RPA connector | Desktop or terminal-only legacy system | Visual state verification, session recovery, partial completion |
Idempotency
Every write-capable connector should define duplicate behavior. The caller supplies a stable idempotency key derived from the business operation, not a random value generated for each retry. The connector stores or forwards the key and returns the original result when the same operation is repeated.
Unsafe pattern: retrying a write because the model did not receive a response.
A timeout means the outcome is unknown, not that the operation failed. Query by operation ID or idempotency key before repeating the action.
Post-condition verification
The connector should define what business success looks like. For a CRM update, verify the exact record and version. For a financial draft, verify amount, currency, account, and status. For infrastructure change, verify the expected configuration and health signal. A generic HTTP 200 response is not sufficient evidence.
4B.16 Long-running workflows and human authority
Enterprise processes frequently outlive a model session. Procurement, onboarding, claims, remediation, and legal review require durable timers, approvals, escalation, and compensation. The workflow engine should own these mechanics.
Human approval should be a structured task. The approver receives the proposed action, resource, evidence, risk, expected side effects, and rollback plan. The approval is tied to an exact operation version and expires if the underlying data or proposal changes materially.
{
"approval_id": "ap_9201",
"operation_id": "op_44192",
"action_hash": "sha256:...",
"approver": "user_7721",
"approver_role": "production_change_approver",
"decision": "approved",
"evidence_viewed": [
"incident:INC-88421",
"change-plan:v3"
],
"approved_at": "2026-07-23T17:12:00Z",
"expires_at": "2026-07-23T17:42:00Z"
}4B.17 Failure semantics and compensation
Execution architecture is defined by its behavior under uncertainty. Each step should distinguish rejected, accepted, committed, verified, failed, compensated, and unresolved states. The agent should not summarize an unresolved operation as complete.
| Condition | Required response |
|---|---|
| Model produces invalid arguments | Reject before connector invocation; return validation evidence |
| Connector timeout before acceptance | Retry within policy using same idempotency key |
| Connector timeout after possible commit | Query operation state; do not blindly repeat |
| Partial multi-system completion | Run compensation or create explicit reconciliation case |
| Approval expires | Re-evaluate context and request a new approval |
| Post-condition fails | Mark operation unresolved, alert owner, and initiate recovery |
4B.18 Anti-patterns
| Anti-pattern | Consequence |
|---|---|
| Agent conversation stores workflow state | State loss, duplicate actions, no durable timers |
| One universal agent with every tool | Excessive agency and broad blast radius |
| Raw API schemas exposed directly | Technical operations lack business policy and meaning |
| Connector reports free-text success | Ambiguous status and weak verification |
| New idempotency key on retry | Duplicate financial or operational effects |
| Approval after execution | Human review becomes incident documentation, not control |
4B.19 Production checklist
4B.110 Summary
Chapter 4C covers the layers that turn a governed task into controlled execution. Orchestration owns sequence and durable state. Models contribute bounded intelligence. Capability routing restricts the available business operations. Connectors translate those operations into target-system behavior and verify the result.
Core conclusion: adaptive planning is safe only when execution is narrow, stateful, attributable, and recoverable.
The model should never be the only component that remembers what happened or decides whether an enterprise action succeeded.