How to run it

The first question a skeptical engineer asks is the right one:

“What stops my agent from ignoring the gateway and just running git push itself?”

The honest answer depends on how you run flowgate. There are three modes, and they sit on an enforcement spectrum — from “governs everything you route through it” to “the wrong move literally cannot be called.” Pick by how tightly you want the agent locked down. All three share the same workflow definitions, guards, and audit log.

1. As an MCP gateway — inside Claude Code / Cursor

flowgate runs as the single MCP server your agent connects to. You map your other MCP servers, CLIs, and REST APIs behind it, so every one of those capabilities is consumed through flowgate’s two tools — flowgate.query and flowgate.command — and therefore through its gates. Your fifty tools collapse to two, and an action that isn’t a legal move in the current state isn’t on the wire: it comes back INVALID_TRANSITION with the legal moves attached.

What it enforces: everything you route through flowgate. A capability behind the gateway can only be called as a legal transition.

The one seam to know about: flowgate sits in front of the tools you wire into it — not in front of your host’s own built-in tools. If Claude Code’s native bash or Cursor’s native edit/run stay enabled, the agent can still act outside the gateway. For airtight enforcement in this mode, restrict the host to flowgate’s tools (see Wire into your editor) or route shell access through flowgate too. If you want enforcement with no seam at all, use mode 2.

This is the lowest-friction path — keep the agent you already use. Quick start sets it up in about a minute.

2. As the loop — the Wispr chat TUI

Here flowgate is the agent loop. You drive a model through flowgate’s own chat TUI (Wispr), and the model’s entire per-turn tool list is the current state’s legal transitions — nothing else exists to call. There’s no host with its own shell to escape to, because flowgate is the host.

What it enforces: everything. The wrong move isn’t restricted, it’s absent — the model cannot emit a call that isn’t a legal transition. This is the literal version of “unreachable, not improbable.”

This mode also unlocks two things the MCP-caller path can’t:

• Per-state model switching — each state’s step can run a different model (affinity: coding-frontier, resolved through models.yaml). Cheap model for the bounded steps, a frontier model for the one hard reasoning step, switched mid-workflow. You pay for capability only where the step needs it.
• Contained sub-agents — a step can spawn an autonomous sub-agent as an isolated subprocess with no write handle back to flowgate; it returns a structured result that’s projected through the step’s governed output mapping. Autonomy without an escape hatch.

See In-runtime LLM execution for the depth.

3. As Mission Control — the Build/Run cockpit

Mission Control is the management surface over the same runtime: a two-mode cockpit that reads the same affordance surface the model sees, so you and the agent share one view of the legal next actions. Build mode to author and validate workflows; Run mode to drive and watch them — every move, guard, and refusal on the record.

Same hard enforcement as mode 2, plus the oversight.

Which one?

You want…	Run it as
To keep Claude Code / Cursor and govern what you wire in	MCP gateway (mode 1)
The wrong move to be truly uncallable, no seam	Wispr (mode 2)
That, plus a cockpit to build, drive, and watch	Mission Control (mode 3)

Start in mode 1 to feel it in the tool you already use. Move to mode 2 or 3 when you want the loop itself locked down — and when you want a cheap model on the easy steps and a frontier model only where it earns its cost.