There are two ways to build a hosted verification product. Become the kitchen: pull the customer's code into your cloud, run everything there, own the whole mess. Or become the conductor: coordinate the performance while the actual cooking happens in kitchens the customer already owns and already trusts.
Fusion chose conductor, and the choice shapes everything.
What the control plane does
The hosted side has a deliberately short job description:
- hold the run graph: which task, which lanes, which judges, what order;
- receive verdicts and store receipts as the permanent record;
- publish the results where decisions happen, like a status check on your pull request;
- keep the dashboard and the ledger that billing projects from.
What it deliberately does not do by default: check out your repository, hold your model keys, or execute your workloads. Those stay inside your trust boundary in local and CI modes.
Why not just be the kitchen
Hosting customer code execution means inheriting the entire security surface of everyone's codebase at once: secrets in env files, malicious dependencies, the untrusted-code problem in its full glory. Products that start there spend their roadmap on containment instead of verification.
The conductor model quarantines that burden. Heavy, long-running execution never sits inside a web request handler; it happens in your environment, or, for teams that opt in, inside an isolated managed tier built specifically for it. The security story stays legible because the boundary stays sharp.
The tell
When you evaluate any agentic tool, ask the kitchen question early: where does my code execute, and who holds the keys while it does? If the answer takes more than two sentences, the boundary is probably not sharp. Ours: your code executes where you choose; the control plane sees metadata, verdicts, and receipts, and gets code artifacts only when you explicitly share them.