Intuit extended its internal disaster‑recovery orchestrator (EWOK) with an AI‑driven component built on Amazon Bedrock, creating an agentic disaster recovery assistant that interprets plain‑language failover requests and hands off deterministic actions to EWOK. Practitioners care because the addition shifts decision‑making from tribal knowledge to a model‑based reasoning layer while preserving existing execution guarantees, and it does so without requiring engineers to manage model infrastructure.
What Changed
EWOK already automated the low‑level steps needed to fail over compute, databases, networking, caches, and asynchronous workloads, cutting recovery time to roughly 20 minutes for supported services. The missing piece was a consistent way to select the correct recovery workflow, validate asset readiness, and handle exceptions such as change‑freeze overrides. The new EWOK Agent introduces a Bedrock‑backed reasoning loop that parses natural‑language intents (e.g., “failover payments‑gateway in production”), maps them to predefined skills, and invokes EWOK actions through Bedrock’s Converse API with function‑calling support.
Why It Matters to Engineers
- AI engineers gain a concrete pattern for coupling foundation models to operational tooling via Bedrock’s tool‑use capability, without building custom model serving stacks.
- Cloud and platform engineers can expose the agent as a plugin for internal portals or IDEs, leveraging Bedrock’s managed service model and guardrails to keep data encrypted in transit and at rest.
- DevOps/SRE practitioners receive a deterministic execution path—model decides *what* to do, EWOK decides *how*—which reduces reliance on undocumented runbooks and shortens mean time to recovery.
- Security engineers benefit from Bedrock’s built‑in guardrails and the guarantee that model training does not ingest production data, addressing data‑privacy concerns for financial workloads.
Architecture Overview
The agent sits between the user request and EWOW’s orchestration engine. A request is sent to a Bedrock foundation model via the Converse API. The model, selected from the Bedrock catalog, returns a function call that maps to a skill—such as “validate change‑freeze window” or “trigger failover for service X”. The skill implementation lives in Python, using Boto3 and the langchain‑aws library to invoke EWOW actions. Because Bedrock abstracts model hosting, the architecture requires only IAM permissions for bedrock:Converse, bedrock:ConverseStream, bedrock:InvokeModel, and bedrock:ApplyGuardrail. The agent is packaged as a plugin, installable in the engineering portal or any supported IDE, and runs in the same AWS account as EWOW, preserving network isolation.
Operational and Security Implications
Operationally, the agent introduces a new dependency on Bedrock availability and model latency; teams must monitor Bedrock service health alongside EWOW. The ability to swap foundation models without code changes provides flexibility but also requires governance to ensure the selected model meets the organization’s policy and performance expectations. Security considerations include verifying that Bedrock guardrails are correctly configured to prevent disallowed content, confirming that all data in transit uses TLS, and ensuring that data at rest remains encrypted per Intuit’s standards. Since production financial data never leaves the AWS environment for model training, the risk surface is limited to the Bedrock inference path.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting an agentic layer built on Amazon Bedrock can reduce reliance on undocumented expertise and accelerate failover decisions, but it adds a managed AI service to the reliability chain. Teams should evaluate Bedrock model latency, guardrail configuration, and IAM permission scope before rollout. Monitoring should cover both EWOW orchestration metrics and Bedrock API health. Finally, treat the model as a decision engine only; keep all execution steps within EWOW to maintain deterministic, auditable recovery actions.
