The executor doesn't reason. That's the point.
The Fibric reference design separates model reasoning from narrow, deterministic execution code. This note explains that control objective; BearScope’s current live path implements governed application controls directly rather than routing through the generalized kernel described here.
There is a temptation, when you build agentic systems, to make everything smart. The planner is a model, so why not let a model interpret the plan? Let it patch a malformed field, infer a missing parameter, choose the closest available tool when the named one doesn't exist. Each of those choices feels like robustness. Together they dissolve the one boundary that makes the whole system safe to run.
Fibric's executor — the code that actually performs actions against order systems, contact centers, and building controllers — contains no model. It cannot interpret, infer, or improvise. It takes a validated ExecutionPlan, checks it against policy, and either performs exactly the effects the plan names or declines. The model proposes; the executor disposes. Nothing in between reasons.
Boring is a load-bearing property
Call the executor what it is: a dispatcher with a rulebook. Its virtues are the virtues of dull code, and every one of them is something you cannot get from a model.
- It is enumerable. The full set of actions the executor can take is a finite registry of capabilities. You can print it. The blast radius of your autonomous system is a list, not a distribution.
- It is testable. Given a plan and a policy, the executor's behavior is a pure function you can cover with ordinary tests. There is no prompt to regress, no temperature to drift. Its CI is just CI.
- It is predictable within its inputs. The same validated plan produces the same invocation request. External systems can still return different or ambiguous outcomes.
- It is enforceable on the governed path. Single-flight and idempotency checks reduce known duplicate attempts; connector behavior and writes outside the path remain separate concerns.
None of these properties survive contact with a model in the path. The moment inference can touch the actuator, enumerability becomes "probably," testability becomes evaluation, and repeatability becomes a benchmark score. Those are fine properties for the proposing side. They are disqualifying for the disposing side.
The freedom this buys the model
The executor’s rigidity can bound the authority of a reasoning model. A wrong inference may be declined when policy catches it, but a flawed proposal that passes incomplete policy can still produce a wrong effect. Deterministic execution narrows the problem; it does not solve model correctness.
BearScope is the current live proof point for governed CX and commerce data through its application BFF. The room-by-room hotel twin is an illustrative managed-pilot pattern. A production physical deployment would need verified executor coverage, connector semantics, independent life-safety systems, and commissioning evidence before any setpoint authority is granted.
What "validated plan" actually means
The handoff between the halves is a schema, not a conversation. A plan names registered capabilities, typed arguments, the entity each action targets, and the idempotency key for each write. Validation is strict: an unknown capability is a rejection, not a fuzzy match; a missing argument is a rejection, not an inferred default. The executor never asks the model to clarify, because a clarification loop is just reasoning smuggled across the boundary.
Strictness at this seam is the composability objective. The catalog has 48 listings, of which 5 support live BearScope paths and 43 are managed early access. A future public connector contract would still need conformance testing; typed invocations do not by themselves guarantee an at-most-once external effect.
Engineering as restraint
The hardest reviews on this codebase are the ones where we decline to add intelligence. Every proposal to make the executor "a little smarter" is a proposal to move reasoning across the line, and the answer is always the same: put it on the proposing side, where being wrong is survivable. The executor stays boring. That is not a limitation we tolerate. It is the property everything else is built on, and the reason you can leave the brilliant half running.
Keep reading: Governed by default · Fail closed