Faultline

Design a cloud architecture with your AI agent on a shared canvas, then fail an availability zone or region and watch the blast radius spread. Price it, lint it, generate the Terraform, together

Comment

Inspiration

I work as a solutions architect. The job runs on a loop: sketch a topology, ask what breaks if an availability zone dies, argue the trade-off, write the Terraform, run a lint, repeat. A language model is good at that kind of reasoning, but only when it can work against the same diagram I'm looking at. An agent that takes screenshots and clicks can't read a canvas, and it can't run a blast-radius analysis over one. WebMCP fixes that. The page hands the agent the architecture graph and the analysis engine as typed tools, so it edits the same model I'm dragging around.

What it does

Faultline is an infinite canvas where you and your browser agent design cloud infrastructure together. You describe a system in a sentence and propose-architecture lays down a connected, configured, placed topology. The agent wires up dependencies, picks provider variants, explains any node or edge (its role, its blast radius, the principle behind it), and estimate-cost attaches a monthly-dollar figure to the design and to every change you make. Either of you can then run simulate-failure on one availability zone or a whole region, and the diagram turns red and amber as the outage spreads along the edges. Single points of failure get ringed. resilience-lint names the anti-patterns it finds and points each one at the chapter of Designing Data-Intensive Applications that explains why it matters. generate-iac writes the Terraform. Every tool also has a button in the UI, so the app works on its own; the agent is what makes the loop fast.

How we built it

  • A Rust compute core compiled to WASM. The graph model, the sentence-to-topology proposer, the blast-radius analysis for zone and region failures, the single-point-of-failure scan, the cost estimator, the resilience-lint rules, and the Terraform emitter all live in one pure library with #![forbid(unsafe_code)], no async runtime, and about 90 tests. Both the UI and the WebMCP tools call into it, so they can't drift apart.
  • A Svelte 5 and Vite shell. The canvas (pan, zoom, drag, orthogonal edges, status overlays) is hand-written SVG with no diagram library.
  • 13 intent-level WebMCP tools in thin TypeScript against document.modelContext, one file each. They stay coarse rather than CRUD: propose-architecture turns a sentence into a topology, configure-resource sets variant, region, zone, and validation in a single call. Pure reads are marked readOnlyHint; anything that echoes a label a human typed is marked untrustedContentHint. The /learn route lists every tool and its schema, live.
  • Test-first, and the git history shows it. CI runs formatting, clippy, unit tests, headless-Chrome WASM tests, cargo-deny, Biome, the build, and a Playwright run of the full demo on every push. The site deploys statically to Cloudflare Pages under a strict CSP.

Challenges we ran into

In real Chrome, executeTool receives its input as a JSON string rather than an object, and the polyfill I developed against is more forgiving, so every tool's execute had to accept both. Keeping the tools intent-level took restraint: the quick version is set-node-property, the version worth having is configure-resource checking variant, region, and zone against a bundled provider profile before it commits. Everything crossing the WASM boundary is a string, so the Rust side has to keep its JSON readable by older documents as the schema grows. And because the agent never sees the rendered canvas, every visible cue (red nodes, failure rings, the outage banner) had to be computed from data the agent can read back just as easily.

Accomplishments that we're proud of

The resilience lint cites a specific book chapter for every finding rather than hand-waving, and the findings come from deterministic graph checks, so the agent can explain them instead of guessing. The failure simulator covers two failure domains, which lets it show you that a Multi-AZ database survives a zone outage but still goes down with its region. Because every tool runs through the same core the UI uses, the agent behaves like a design partner rather than a brittle UI script. Tool calls return in a few milliseconds.

What we learned

WebMCP works best when the page is a real domain model with an MCP interface on top, not a pile of buttons to press. Once the tools delegated to a tested core instead of carrying their own logic, the agent got noticeably more reliable. The Rust and WASM core turned out to be worth the setup cost: few other entries take that route, and the determinism it buys is what you want when an agent is going to read your results back to a user.

What's next for Faultline

GCP and Azure profiles over the same neutral core. The profile is already plain JSON, so another provider is a config file rather than a release. A staged accept-or-reject overlay so the agent's bigger edits preview before they land. Importing an existing Terraform state and linting that. Packaging Faultline as a standalone MCP server, so faultline check can run in CI and publish the resilience score as an artifact.

Built With

  • amazon-web-services
  • biome
  • cloudflare-pages
  • document.modelcontext
  • github-actions
  • hcl
  • model-context-protocol
  • playwright
  • rust
  • svelte
  • svg
  • terraform
  • typescript
  • vite
  • vitest
  • wasm-bindgen
  • wasm-pack
  • webassembly
  • webmcp
Share this project:

Updates

Submission history