Governed by default: why a model should never touch the actuator
There is exactly one design decision that determines whether agentic AI is safe to put in front of a building, an order pipeline, or a warehouse. It is where you draw the line between the part that reasons and the part that acts. Fibric draws it in one specific place, and never lets it move.
Here is the question every serious deployment of an agent eventually has to answer, even if it avoids it for a while: when the model decides to do something in the real world, what actually performs the action? If the answer is "the model, by calling the tool directly," then the safety of your operation is now a property of a non-deterministic system that, by its nature, will sometimes be confidently wrong. That is not a configuration you can harden. It is a foundation you have to replace.
The instinct behind agentic AI is right. A model that can reason about an operation should be able to act on it. But the leap from "can reason" to "can actuate" hides the entire safety problem, and most systems make that leap silently by wiring the model's output straight to an effect. Fibric refuses to make it. The model is never the thing that touches the actuator. Something deterministic always sits in between.
Two sides, one line
The cleanest way to see Fibric's trust model is as a single line with the world's two halves on either side of it.
The model
Reads the real state, reasons about what is happening, and writes a validated plan: place a hold on order 4471, notify the customer. It is allowed to be brilliant. It is allowed to be wrong. It cannot touch anything.
The executor
Deterministic code takes the plan, checks it against your policy, enforces single-flight and idempotency, performs the effect at most once, and writes a receipt. No creativity. No surprises.
Everything uncertain lives on the left. Everything that reaches the world lives on the right. The model proposes; a deterministic executor disposes. The actuator is only ever driven from the right side of that line, which means a hallucinated number, a bad inference, or a runaway loop on the left can produce, at worst, a proposal that the right side declines. The reasoning never reaches the world unsupervised, because the path from reasoning to world goes through code that does not reason.
Fail-closed, not fail-careful
"Governed" is a word every AI product now claims, usually meaning a human glances at things or a prompt politely asks the model to behave. That is fail-careful, and it fails the moment attention lapses or the prompt is out-argued. Fibric is fail-closed: the default for any action is that it does not happen unless it clears the gate. Safety is the resting state, not the thing you remember to add.
Concretely, the executor will refuse a plan rather than guess. If a policy you set forbids messaging a customer outside business hours, that action does not fire and does not queue up to fire later by accident. If a required signal is missing, the executor does not improvise a value. The system would rather do nothing than do something it cannot justify, and "do nothing" is always available because it is the default.
Why determinism is the point
People sometimes hear "deterministic executor" and assume we are throwing away the model's intelligence. The opposite is true. The determinism is exactly what lets you use a powerful, occasionally-wrong model with confidence. Because the executor is deterministic, you can read it, test it, and reason about every action it is capable of taking. The set of things that can happen to your operation is bounded by code you can audit, not by the open-ended behavior of a model you cannot.
- It is enumerable. The actions the executor can perform are a finite, inspectable set. The model can propose anything; only those proposals that map to a real, governed capability can dispose.
- It is repeatable. Given the same plan and the same policy, the executor does the same thing every time. That is what makes a receipt meaningful and an incident reconstructable.
- It is enforceable. Single-flight and idempotency live in the executor, below every connector, so a retry storm on the reasoning side cannot become a flood on the acting side.
Where this lives, and why it is everywhere
The reason this matters in practice is that the gate is not bolted onto one feature. It is pushed down beneath every action Fibric can take, below every connector and every operator. A connector author teaching Fibric to talk to a new door controller or a new order system does not get to decide whether the gate applies to their integration. The gate wraps their capability automatically. They inherit governance; they cannot opt out of it. That is what "by default" actually means: not a setting you switch on, but the only path an action can take.
And because every action goes through the same gate, every action leaves the same kind of trace. The receipt is not a logging nicety. It is a consequence of the architecture: since the executor is the single deterministic chokepoint for effects, it is also the single place that records what happened and why, linked back to the intent that proposed it. You do not get governance and observability as two features. You get them as one shape.
The test to apply to anyone
If you are evaluating any agent that can act on the real world, ours included, ask one question and listen carefully to the answer: what performs the action, and can it ever be the model directly? If the line between reasoning and acting is fuzzy, or if it moves under load, the safety is a promise rather than a property. If the line is hard, deterministic, and the actuator is always on the far side of it, you have something you can actually leave running. That line is the product. Everything else is built on which side of it a thing is allowed to live.
Keep reading: The 657-message problem · Fail-closed governed autonomy