Intuit’s EWOK Agent turns a plain-English request into a governed production failover while keeping the foundation model away from credentials and direct infrastructure access. The model selects what should happen; a deterministic executor handles authentication, policy checks, change records, failover execution, and audit logging. Intuit says teams have used the system for eight months, building on an orchestration platform that can cut supported failovers from several hours to about 20 minutes.
One sentence can start a production failover
Intuit has built an AI agent that can take a request like “failover payments-gateway in production” and turn it into a real disaster-recovery workflow.
The system is called EWOK Agent. It sits on top of Intuit’s existing Ecosystem Wide Orchestrator Kit, or EWOK, which already handles the deterministic infrastructure work behind regional failovers.
The agent adds a reasoning layer. It identifies the target asset, finds the available recovery workflows, checks whether the asset is ready, evaluates policy gates, starts the approved workflow, and then reports progress back to the engineer.
Intuit says teams across the company have been using EWOK Agent to run failovers for the past eight months.
The interesting part is not that a language model can understand the request. It is how Intuit lets that model influence production without turning the model itself into the production control plane.
The model decides what to do — conventional code decides how
Intuit describes the design with a clean boundary: the model decides what to do, and EWOK Agent deterministically executes how.
The foundation model never performs the failover directly.
Instead, it selects a typed skill and returns structured arguments such as the asset name, environment, and requested operation. A conventional executor then calls EWOK’s authenticated APIs, resolves the asset, checks policy, creates the change record, and starts the recovery workflow.
From EWOK’s point of view, the agent is just another authenticated caller.
That separation keeps the model in the interpretation and coordination layer. The infrastructure-changing work remains in code that can be tested, logged, permissioned, and reviewed like the rest of the production system.
It is a useful pattern for any agent that needs to operate near critical infrastructure: let the model choose among bounded capabilities, but keep state-changing execution outside the model.
EWOK already turned hours of recovery work into about 20 minutes
The agent did not replace Intuit’s disaster-recovery machinery. It was added on top of a system that had already standardized the hard operational steps.
EWOK coordinates failover across compute, databases, networking, caches, and asynchronous workloads. Service owners describe recovery intent in YAML, and the orchestration layer turns that declaration into an ordered sequence of infrastructure actions.
Intuit says EWOK reduced recovery times from several hours to about 20 minutes for supported workloads.
What remained was the decision layer around that automation.
Engineers still had to know which recovery workflow applied, whether an asset was ready, how to handle an exception, and which procedure to follow when policy blocked an action. That knowledge often lived in runbooks and in the experience of the people on call.
EWOK Agent is designed to absorb more of that coordination while keeping the engineer in the supervisory role.
Operational knowledge is encoded as typed skills
Instead of writing another free-form prompt around a long runbook, Intuit converts operational knowledge into skills.
Each skill is a Markdown file with YAML frontmatter that declares a typed input and output schema. The prompt body then describes the procedure, rules, stop conditions, and policy branches the model should follow.
The schema compiles into the tool definition the model can select.
For a failover skill, the model might choose an operation such as `invoke-failover`, along with the asset and target environment. The executor then performs the real API call.
Intuit also keeps the skill instructions deliberately structured. Steps map to specific executor calls. Errors stop the workflow instead of inviting the model to improvise. Policy conditions are explicit branches rather than vague advice.
That makes the skill both human-readable and machine-consumable, while keeping the agent’s action space narrow enough to reason about.
Policy gates stay inside the workflow
Production failovers do not happen in a policy vacuum.
Intuit gives the example of a change-freeze window, when normal changes are restricted. If an engineer asks for a failover during one of those windows, the system does not simply push ahead.
The skill treats the restriction as a defined branch. The agent can ask for an incident number or an emergency justification, then rerun the request once with the additional information.
Critical or irreversible actions keep a human in the loop, especially in production.
The policy is therefore part of the workflow the agent reasons over, not something bolted on after the model has already made a decision.
This is one of the strongest parts of the design. The agent can make the interaction conversational without making the underlying operational rules conversational.
The model never gets the production credentials
Intuit built the security boundary so the foundation model does not hold AWS credentials and does not have a direct network path to EWOK.
The model emits tool arguments. Authentication is injected into the executor from request-scoped context, and that executor assumes the appropriate IAM role before calling the underlying APIs.
The same pattern applies to auditability. State-changing actions return typed JSON with explicit status fields, and the agent loop reacts to those structured results rather than trying to interpret free-form infrastructure output.
Intuit also describes immutable audit logging, least-privilege IAM, rate limits, replay-attack protections, and human approval for critical actions.
Amazon Bedrock Guardrails are attached to each model invocation, while the infrastructure boundary remains enforced outside the model.
The result is a layered design: language-model reasoning on top, deterministic execution underneath, and conventional production controls around the whole path.
The engineer moves from orchestrator to supervisor
Before EWOK Agent, a failover could involve runbook lookups, console visits, API calls, policy checks, and repeated status monitoring.
With the agent in the loop, Intuit wants the engineer to supervise the process instead of manually coordinating every step.
The agent resolves the asset, selects or presents the relevant workflow, validates readiness, triggers the approved execution, and returns the execution and change records. It can then keep reporting stage-by-stage status as the recovery progresses.
The human still makes judgment calls and approves gated actions.
That distinction is important. The system is not trying to remove operational ownership. It is moving the repetitive coordination into a persistent agent that already knows the typed procedures and can call the right bounded tools.
For on-call work, that can make a major difference: less time remembering the mechanics, more time deciding whether the recovery is the right move.
The Upgrade Feeling
EWOK Agent is a useful example of what production agent design can look like when the model is not treated as the execution environment.
The plain-English interface is the visible part. Underneath it, the architecture is deliberately conventional: typed skills, deterministic executors, policy branches, IAM, change records, audit logs, and human approvals.
That is probably the more important story.
As AI agents move from code generation into infrastructure operations, the useful question is not only whether the model can choose the right action. It is whether the surrounding system can make that action bounded, inspectable, and recoverable.
Intuit’s answer is to let the model reason — and let trusted software touch production.