Governed by default: why a model should never touch the actuator
One important design decision is where to draw the line between the part that reasons and the code that acts. The Fibric reference architecture puts deterministic policy checks at that boundary; each deployment still has to verify credentials, bypass paths, connector behavior, and independent safeguards.
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. You cannot harden that configuration. You have to replace the foundation.
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. It follows the plan and nothing else.
In the reference design, model uncertainty stays on the proposing side and governed execution stays on the disposing side. This limits direct model authority, but policy can be incomplete, credentials can be mis-scoped, and external systems can have bypass paths. A bad inference is held only when a configured control catches it.
Fail-closed, not fail-careful
"Governed" is often used loosely. The Fibric reference contract instead targets default-deny behavior on covered action paths: a configured action should not execute unless it clears deterministic policy. That control still depends on correct policy, credentials, connector behavior, and the absence of bypass paths.
In the target executor, a plan with missing required state or no permitting rule is refused rather than guessed through. This reduces risk inside the governed path; it is not a universal safety property of every connected system.
Why determinism is the point
Deterministic checks make the covered invocation set more inspectable and testable than direct model tool use. Reviewers can reason about registered capabilities and policy outcomes, while still accounting for misconfiguration, external writers, and downstream behavior outside that boundary.
- 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, registered capability can dispose.
- It is predictable within its inputs. Given the same plan and policy state, it produces the same invocation request; downstream outcomes can still vary.
- It is enforceable on covered paths. Single-flight and idempotency reduce duplicate attempts inside the governed runtime; they do not cover independent writers or unknown external outcomes.
Where this lives, and why it is everywhere
The reference contract requires acting connector capabilities to pass policy checks. Public third-party publishing is not available today, so that contract should be read as a managed conformance objective. Each deployment must verify the credential boundary and ensure no unreviewed path bypasses the gate.
On supported paths, the gate writes a consistent execution record linked to the proposal and observed response. The record improves traceability; it does not prove an external effect if the connector reports an ambiguous outcome.
The test to apply to anyone
If you are evaluating any agent that can act, ours included, ask what performs the action, which credentials it holds, what paths bypass it, how policy coverage is tested, and how ambiguous outcomes are handled. A deterministic line is valuable evidence, not sufficient evidence by itself that a system can be left unattended.
Keep reading: The 657-message problem · Fail-closed governed autonomy