Cascade

Inspiration

When working on an app launch, we found ourselves sending planning docs back and forth between us and our agents. That was very problematic. We wanted to move beyond asking an AI, “What could go wrong?” and getting another list to read. What if the agent could work inside the plan itself, connecting assumptions, exploring consequences, and proposing alternatives that a person could inspect and challenge?

That became Cascade: a shared decision canvas for people and their agents.

What it does

Cascade turns a consequential plan into a connected map of objectives, assumptions, dependencies, constraints, risks, and outcomes.

Our demo starts with a product launch: six weeks, 500 teams, and a $12,000 budget. What happens if billing arrives three weeks late? An agent can create a separate what-if branch, apply the disruption, and trace modeled downstream effects. It can then stage possible responses, such as launching a free beta first.

The human can inspect the map, drag cards with their connections following, compare scenarios, and accept or reject proposed factors and relationships. Applying a shock is allowed inside a what-if branch; proposed mitigations remain drafts awaiting review. Promoting a branch is a human action.

Product launch is the starter. Cascade also includes a community tool-lending scenario and a blank workspace for other plans.

Why WebMCP

Cascade is built around a shared working surface, not a separate chat transcript.

WebMCP lets the agent read and act on the structured model behind the page. Tool actions update the same interface the person is watching: branches appear, shocks enter the map, and proposals arrive for review.

This makes an otherwise awkward workflow practical: the agent explores alternatives inside the live application while the person retains an inspectable record of the model and controls which proposals are accepted. There is no need to copy the plan into a chat and manually translate the answer back into a diagram.

How we built it

Cascade uses TypeScript and React, with a Next.js-style App Router implemented through vinext on Vite. React Flow provides the draggable node-and-edge canvas. Custom CSS and a Tailwind CSS build pipeline support the visual design.

The app registers 11 imperative WebMCP tools through document.modelContext.registerTool(). They cover reading the workspace, staging factors and relationships, creating branches, applying shocks, proposing mitigations, running stress tests, and comparing or explaining results.

Tools use structured schemas and bounded inputs. Version checks on scenario-editing tools help reject stale writes when a person and an agent are working on the same model. Draft revision is limited to unlocked draft factors.

A local TypeScript engine propagates shocks through accepted relationships to produce deterministic sensitivity metrics and impact paths. Its outputs are modeling aids. Vitest tests cover stable metrics, shock propagation, draft exclusion from cost and schedule totals, and graph layout.

The workspace is stored in browser localStorage and can be exported as JSON. The app does not need its own AI API key; a connected agent uses the page's tools. That agent still receives the workspace data exposed through those tools.

Cascade is hosted on ChatGPT Sites with a Cloudflare Workers-compatible build, with source code on GitHub under the MIT license.

Challenges we ran into

One challenge was making the graph behave like a genuine working surface: cards needed to move freely while their connections stayed anchored.

Another was separating exploration from commitment. An agent needs room to test a disruption without silently rewriting the baseline, and people need a clear distinction between proposed and accepted changes.

Rehearsing the demo exposed a subtler problem: an agent created a scenario whose description mentioned a delay, but did not actually apply the delay to the model. That reinforced an important lesson: a success message is not proof of a state change. Reliable collaboration needs outcome verification, not just well-described tools.

Accomplishments we're proud of

We built a working shared canvas where agent actions become visible, reviewable changes rather than suggestions trapped in a conversation.

The same decision model supports both the product-launch and community examples, and the app remains usable by a person when WebMCP is unavailable.

Most importantly, human review is part of the interaction itself: proposals, locks, scenario branches, and promotion controls make the collaboration boundary visible.

What we learned

Agent-native design is as much about accountability as capability. Giving an agent tools is only the beginning; the application must make its actions understandable and checkable.

We also learned to distinguish a useful model from a confident-looking number. Cascade's purpose is to expose assumptions and explore consequences, not claim certainty about the future.

What's next

• Stronger end-to-end evaluations that verify actual model changes after agent actions.
• More explicit feedback when a scenario has been created but no disruption has been applied.
• Improved mitigation-effect modeling, uncertainty handling, and explanation of score contributions.
• Shared team workspaces with durable persistence.
• Evidence links and richer review history for the assumptions behind a decision.

Built With

• github
• next
• react
• tailwind
• typescript
• vinext