ProcessTwin — Pull Requests for Application State
I built ProcessTwin around a simple frustration: workflow editors are easy for a person to understand and awkward for an agent to use reliably. A person can see a canvas and drag a connection. An agent asked to do the same thing through pixels has to guess at coordinates, handles, and inspector fields—and a mistake can look correct while changing the wrong process.
ProcessTwin does not put a chatbot inside a diagram editor. Instead, the page gives an external agent a small, explicit set of WebMCP capabilities. The human edits a process on the canvas; the agent reads and changes the same process state through those capabilities.
Why this is a good fit for WebMCP
The useful action here is not “click near this connector.” It is “send this decision’s false branch to Manager Approval and apply this condition.” WebMCP lets ProcessTwin expose that semantic operation directly. In the demo, the agent builds a workflow in three domain-level calls instead of reproducing a long sequence of drags and clicks.
What gets better
Agents receive structured process graphs, validation results, simulation percentiles, bottlenecks, and suggested fixes instead of screenshots. The app also shows the evidence: a telemetry panel tracks tool calls, payload size, and estimated UI work avoided. That makes the benefit visible while the demo runs.
What people and agents can do together
The agent can tell what the human changed. ProcessTwin versions process state and exposes changes, including actor attribution and before/after values.
The agent can try an idea without changing the live process. It forks a private scenario, makes changes, runs the simulation, and brings back a before/after diff. I deliberately left out an agent merge tool: the human reviews the proposal and clicks Apply.
The human can also set boundaries that the agent cannot ignore. For example, a policy can require high-value refunds to pass through a human approval step. An agent mutation that breaks the rule is rejected with a structured explanation, so it can adapt rather than silently doing the wrong thing.
How it works
ProcessTwin registers 13 core tools with document.model Context registerTool and adds analysis or scenario tools only when the current state makes them useful. Zod is the source of truth for tool inputs, with JSON Schema generated from it. Each tool returns a structured envelope with a summary, data, state version, and practical next steps.
The important implementation choice is that there is only one mutation path. Canvas actions and WebMCP calls both go through the same command layer, which handles validation, policy checks, undo history, activity logging, and state-version updates. The human and agent therefore cannot end up with competing versions of the process.
Built with Next.js, TypeScript, React Flow, Zustand, Zod, dagre, and Vitest. No backend. MIT licensed.
Key capabilities
- Semantic tools for creating, connecting, editing, validating, simulating, and arranging workflow nodes.
- Private scenario branches, simulation comparison, and human-only merge review.
- Policy enforcement that gives the agent recoverable constraint errors.
- Seeded capacity-aware simulation and bottleneck analysis.
- State-aware registration: 13 core tools expanding to up to 19 tools.
- Live end-to-end WebMCP verification in Codex's in-app browser.
Built With
- next.js
- react
- react-flow
- tailwind-css
- typescript
- vitest
- webmcp
- zod
- zustand