Definition
A gated multi-agent flow is a multi-stage workflow where an agent’s output only “counts” after it passes explicit gates (tests, checks, or reviews) and produces a build receipt.
It’s the difference between:
- “I fixed it” (narrative)
- “Here’s the diff + the gate outputs” (evidence)
The basic shape
A typical flow looks like:
- Explore → inventory + plan (explore agent)
- Implement → small, reviewable diffs (task agent)
- Verify → tests, linters, typecheck, security checks
- Challenge → oppositional validation (try to disprove)
- Merge / ship → only after gates pass
The key: each stage produces artifacts that the next stage can trust across a trust boundary.
Common gates
Pick gates that are cheap, deterministic, and hard to game:
- Lint / format
- Typecheck
- Unit tests, integration tests
- Targeted checks like mutation on diff for risky logic
- Schema checks (schema gravity in action)
- Security checks (headers, CSP, input validation)
Design rules
- Make gates machine-verifiable. If you can’t script it, it’s not a gate.
- Keep stages small. A gate is only useful if you can understand why it failed.
- Prefer “stop the line.” Don’t let downstream work continue on a broken upstream artifact.
Failure modes
- Gates are optional (“soft fails”) → velocity looks high, correctness collapses.
- Gates are too slow → agents route around them.
- Gates are superficial → reward hacking becomes the default strategy.
Practical rule
If you can’t point to the gate output, the gate didn’t pass.