# Before AI Touches Critical Operations, Separate Decision from Execution

> Intuit's disaster recovery agent shows how enterprise AI should work: models interpret intent and orchestrate, while deterministic systems handle execution.

Source: https://www.starbox.work/en/insights/ai-news/2026-09-09-193/ (Starbox AI Insights, updated 2026-09-09)

Typing a single command like "fail over payments-gateway in production to the secondary region" can trigger sweeping changes across compute, databases, caches, and live traffic routing. Intuit's disaster recovery agent, EWOK Agent, allows on-call engineers to initiate these critical failovers using natural language. 

Yet the most valuable takeaway for enterprise leaders is not that "AI can perform disaster recovery." It is a disciplined architectural boundary: **the AI model determines what needs to be done, while deterministic systems determine how it gets executed.**

Intuit's existing disaster recovery orchestration had already cut recovery time for supported workloads from several hours down to roughly 20 minutes. However, choosing the right recovery workflow, confirming asset readiness, and handling exceptions during change-freeze windows still required seasoned on-call expertise. EWOK Agent fills the gap in comprehension and coordination: it identifies assets, lists approved workflows, runs readiness and policy checks, creates change records, triggers execution, and continuously reports progress across stages. The actual actions that alter the production environment remain strictly in the hands of existing APIs and workflows.

## Turn Experience into Skills, but Never Hand Control to Prompts

In this architecture, disaster recovery knowledge is formalized into structured skills with strict input and output constraints. These include machine-readable schema definitions, step-by-step procedures, explicit stop conditions, and deterministic policy branches. 

A change-freeze window is not treated as an error message for the model to bypass. Instead, the workflow halts and prompts the engineer for an incident ticket number or an emergency justification; if the user refuses, execution stops. If a step fails, the workflow must terminate immediately—the model is never allowed to experiment with alternative execution paths on its own.

This marks the clear divide between production-grade enterprise agents and basic chat assistants. Large language models excel at interpreting ambiguous requests, selecting among pre-approved options, synthesizing outputs, and communicating with human operators. However, permission checks, state changes, retry policies, and audit logging must remain inside traditional, verifiable execution engines. 

The model holds no cloud credentials and never connects directly to the disaster recovery infrastructure. Instead, the executor acquires scoped permissions within the boundaries of the approved request and returns structured success or failure states. Every critical action preserves the exact same approval and audit trail required for human operators.

> With every step toward automation, assign variable judgment to the model, and lock irreversible execution inside verifiable systems.

## The Starbox Perspective: A Dual-Ledger Framework for Autonomous Actions

At Starbox AI, we apply this separation through distinct operational layers. The organizational layer defines who can request an action, who can approve it, and what conditions trigger an immediate halt. The BOX layer stores approved skill versions, permitted actions, exception branches, and execution logs. The agent layer does only one job: mapping user intent to authorized capabilities.

This requires a dual-ledger model:
1. **The reasoning ledger:** Records why the AI model proposed a specific action based on context and prompts.
2. **The execution ledger:** Records whether the deterministic executor completed the action according to policy, along with proof of authorization.

These two records must never be collapsed into a single natural language summary.

This architecture directly informs our DDABC delivery framework:
- **Define:** Establish hard boundaries between judgment interfaces and execution interfaces.
- **Deploy:** Connect agents exclusively to scoped, deterministic tools.
- **Analyze:** Identify which requests face frequent rejections or require manual fallback.
- **Benchmark:** Measure task completion rates, response latency, and false triggers.
- **Calibrate:** Continuously refine skills, validation logic, and policy controls.

Scaling enterprise AI is not about granting models broader permissions. It is about enabling them to coordinate more complex work across strictly defined interfaces.

This principle applies beyond IT operations to marketing, customer service, and commercial workflows. A content agent can analyze brand guidelines and draft a publishing schedule, but it should never bypass review to publish directly to external channels. A sales agent can track buyer signals and suggest next steps, but it should never modify contract terms or authorize discounts independently. 

Enterprises must explicitly specify which tools are read-only, which can generate drafts, and which actions require an approved ticket or human sign-off. When these boundaries are built into the architecture, human oversight stops being a repetitive manual bottleneck and focuses where it matters most: on actions that alter business commitments and enterprise risk.

*(Source: AWS, "How Intuit built an agentic disaster recovery assistant with Amazon Bedrock," September 4, 2026. Recovery times and runtime figures reflect the documented Intuit/AWS case study and should not be extrapolated as industry averages.)*