# Fermion Fleet: When the Door Is Code, Not a Prompt

> Source: <https://dev.to/xiaojia-fermion/fermion-fleet-when-the-door-is-code-not-a-prompt-n2m>
> Published: 2026-08-27 11:55:44+00:00

This post was created for the Google All Things Agentic Hackathon.

Autonomous agents can sound certain while still being wrong. That is not a prompt-quality problem; it is a boundary problem.

**Fermion Fleet** is a small multi-agent system built around one constraint: an order must not lock because a model says it is ready. It may lock only after code can read a structured boolean approval.

In the demo, a handler drafts an order confirmation. It misses required fields. An auditor sends it back. The handler rewrites. Only a valid review can release the order to the ledger.

The important part is not that the auditor is asked to be careful. The important part is that the ledger accepts only a real boolean approval from a parseable result.

The gate has a deliberately boring policy:

This is fail-closed by construction. Looks good, a persuasive explanation, an unexpected format, and a parser failure all resolve to **stop**.

We tested that boundary by breaking the auditor’s output format. The auditor could still identify a real hallucination in natural language. It sounded professional. But code could not read a structured approval, so the door stayed shut.

That is the project’s central idea: **the door is code, not a prompt.**

The other problem is context management. In a long-running system, context cannot expand forever. But forgetting should not mean permanently deleting facts that a later step may need.

Fermion Fleet uses a small context window and a recoverable pool:

customer

-> triage: writes the case file

-> gardener: select / evict / recall

-> gate: handler -> auditor -> parse, fail closed

-> ledger: locks only on boolean true

When the window is full, the gardener evicts low-priority items into a recoverable pool. That eviction is driven by pressure, not by a timer. Later, when a new step needs an earlier detail, the system scores and recalls that item.

In the recorded run, an after-sales commitment leaves the active window. A later customer question makes it relevant again; the system recalls it, and the handler can answer with details that were not present in the current conversation. Without recall, that answer would be impossible.

The runtime stack is Google’s:

The policy layer is ours:

That separation matters. A model can generate the next action; the system still needs explicit, inspectable rules for what that action is allowed to do.

This hackathon build keeps context and the ledger in process memory. A Cloud Run restart loses them. We deliberately do **not** claim Firestore, a managed memory service, Model Armor, or a background side-track as deployed components.

Those are sensible next steps, but they are not part of this submission. The architecture and README draw only what runs now.

The repository contains reproducible instructions. The Cloud Run service is an API, rather than a browser UI. To run a complete shift against the public deployment:

git clone [https://github.com/wubian87/fermion-fleet](https://github.com/wubian87/fermion-fleet)

cd fermion-fleet

URL=[https://fleet-843303850287.us-central1.run.app](https://fleet-843303850287.us-central1.run.app) ./跑班.sh

A cold start can take roughly 15 seconds.

A reliable agent system should make its important no decisions boring and mechanical. The model can be creative inside the workflow; the boundary that grants permission should remain readable by code.

That is the experiment behind Fermion Fleet: make a rejection visible, make a retry auditable, and make the final lock depend on a value that cannot be talked into existence.``