Why Mockflow
Draw the system.
Run the story.
Explain what really happens.
Mockflow turns architecture from a picture people argue about into a system story you can run, replay, and save — one shared explanation for your team and any approved tools you choose to connect.
- Clear components
- Repeatable runs
- Controlled agent access
Every outage starts as a diagram
Somewhere in your company there is a picture of your system. It was accurate the day it was drawn. Since then the queue grew a dead-letter route, the cache got a TTL nobody wrote down, and the “simple” service in the corner now calls four others. The picture didn’t change — because pictures can’t tell you when they’re wrong.
Mockflow closes that gap by making the diagram do something. Components are building blocks with clear connection points. Scenarios describe situations you care about, and runs play those situations out step by step. When the picture can tell a story, missing routes and surprising behavior become easier to see.
What makes it different
Connections that make sense
Every component has clear connection points. The editor helps you join compatible parts and explains why a connection is rejected, so mistakes are easier to spot while you design.
Behavior you can watch
Write a scenario, press run, and watch a request move through the system. Each step is recorded, and the same saved scenario produces a repeatable story you can review together.
Failure is a first-class route
Retries, dead letters, cache misses, timeouts, rejected requests — in Mockflow these are drawn routes, not footnotes. The unhappy path gets the same visibility as the happy one, which is exactly where designs go wrong.
Review points that stay put
Keep working in a draft, then create a checkpoint when the team needs a stable point to review. Later changes do not rewrite that earlier decision.
Runs are illustrative, not load tests. Mockflow demonstrates the behavior and ordering you designed — who calls whom, what happens on failure, where state lives — not real-world capacity or latency.
Where it earns its place in your week
Mockflow isn’t a documentation chore you do after the real work — it’s a tool you reach for at the moments where software development actually gets expensive.
The design review
Run the proposal in front of the room and walk through the route step by step. The conversation can focus on behavior instead of different readings of the same arrow.
The new teammate
Instead of a stale wiki page, hand them the checkout diagram and let them replay an order scenario, event by event. Architecture onboarding becomes an afternoon, not a month.
The fork in the road
Queue or topic? Saga or one big service? Wire both versions, run the same scenario through each, and compare the stories before you commit a sprint to either.
The incident retro
Reconstruct the failure path as a scenario — the timeout, the retry storm, the dead-letter queue — and keep it as a runnable artifact the next design has to survive.
The docs that don’t rot
The diagram, scenario, and run stay together. A reader can see the picture and replay the behavior instead of relying on a slide deck with no evidence behind it.
Tell your agent the story of your software
Available nowScoped reading and guarded diagram authoring over MCP
An AI coding tool can help more when it has the right system context. Without that context it may make a reasonable-looking assumption that does not match your design. A scoped Mockflow connection lets you provide approved context without sharing the whole workspace.
The Mockflow MCP serveris the controlled connection between Mockflow and an approved client. You create a separate Agent Access Key, choose what it may reach, and store the key in that client's secure settings. Read-only is the default, and you can separately allow guarded writing when the client needs to create or change a draft.
What your agent gets to read
Selected diagrams
The components and connections in the diagrams you chose for that key.
Scenarios
The situations the system is expected to handle, when the key is allowed to read them.
Approved run evidence
The route and event story from approved runs, limited by the key's data setting.
Contract summaries
Approved descriptions of important requests, messages, and data boundaries.
Implementation links
Approved links that help a client understand which system or owner a component represents.
Handoff context
A focused collection of approved diagrams, scenarios, and supporting information for a task.
The result is a focused briefing rather than a dump of workspace data. The client can understand the chosen system story while unrelated diagrams and information remain out of reach.
What your agent can author
With guarded write access, an approved client can turn a plain-English description into a complete new diagram. It can choose suitable components, connect them, add important scenarios, and describe supporting information. It can also improve a permitted existing draft, for example by adding a missing failure route or retry.
The client writes drafts, not final decisions. You review the work in Mockflow before it is approved, presented, or shared. Its access stays limited to the diagrams and information allowed by the key.
Read-only is the default. Complete diagram authoring needs a separate, short-lived write-capable key, explicit owner confirmation, and the workspace setting that allows MCP draft changes. Availability depends on the Mockflow environment and its production release configuration.
Keep approval, publication, sharing, export, and workspace administration in the signed-in Mockflow application. Owners can narrow, rotate, or revoke a key at any time.
Start with a picture
The best way to understand Mockflow is to draw something small and run it. Sketch a client, a gateway, and a service; write a one-line scenario; watch the request come back. Then break it on purpose.