Industrial AI has an uncomfortable property that conventional software engineering largely trained us not to expect:
the same valid input can produce a different valid output on the next run.
That is not necessarily a defect. Probabilistic reasoning is exactly what gives modern models their ability to interpret ambiguous evidence, form hypotheses, summarize complex material, plan work and adapt to situations that were never enumerated by a developer.
But in industrial operations, useful reasoning and trustworthy execution are not the same problem.
A model may suggest a maintenance action. It should not be able to grant itself permission to perform it. An agent may generate three different investigation plans across three runs. The production system still needs the same authorization rules, evidence requirements, approval boundaries, rollback semantics and audit guarantees every time.
Our engineering principle is simple: keep intelligence probabilistic where it creates value, and make the system boundary deterministic wherever consequence begins.
That principle shapes how Facthory runs agents in production.
There is a common category error in discussions about trustworthy AI: treating model determinism as the goal.
Large language models are stochastic systems. Temperature can be lowered. Sampling can be constrained. Structured output can be enforced. Models can be pinned to versions. None of that turns open-ended reasoning into ordinary deterministic application code.
We therefore design around the opposite assumption:
model output is untrusted proposed state until deterministic software accepts it.
Facthory separates the reasoning plane from the control plane. Agents can research, compare evidence, generate hypotheses, call approved analytical tools and propose actions. A proprietary orchestration and safety harness, implemented in Rust, owns the deterministic boundaries around that work.
The implementation is deliberately not public. The important architectural contract is.
The distinction matters.
An agent can arrive at different candidate explanations for a defect. That is probabilistic reasoning.
Whether it is allowed to write to an enterprise system, whether the requested operation is within scope, whether required evidence is present, whether two accountable people must approve, whether the action completed successfully, and whether the resulting state may be committed are deterministic control decisions.
This is how we think about deterministic outcomes from non-deterministic intelligence. We are not promising that every sentence generated by a model is identical. We are designing so that the rules governing accepted state transitions do not change because the model phrased its reasoning differently.
A recent Vercel engineering article, The best workflow engine is a programming language, makes an argument we strongly agree with: a programming language already expresses sequence, branching, parallelism and dependency. Durable execution should preserve those semantics rather than forcing engineers to redraw application logic as an external workflow graph.
Our implementation is independent, but the broader principle is the same.
For agentic systems, this becomes even more important. If the workflow itself is hidden in prompts, informal conventions or a visual builder, it becomes difficult to prove which paths are possible, where an action can occur, what gets retried, what must be approved, and what state survives a failure.
At Facthory, consequential workflow semantics are expressed through executable contracts in our self-developed Rust orchestration harness. The agent is free to reason inside those contracts. It is not free to rewrite them.
This architecture has a useful property: the agent can be upgraded without moving the safety boundary into the new model.
A stronger model may produce a better plan. A cheaper model may handle a routine classification. A specialist model may reason over engineering evidence. The authorization, approval and commit semantics remain outside the model.
We treat an agent action less like a chat response and more like a transaction proposal.
The proposal has to survive a series of deterministic checks before it can become enterprise state.
This state machine is intentionally simplified. The production implementation contains more nuance, but the public principle is stable: reasoning does not equal commitment.
A trustworthy runtime needs explicit states for proposal, authorization, review, execution, verification, recovery and commitment. Otherwise failures become ambiguous. Did the model merely suggest an action? Did a tool actually execute it? Did it execute twice after a retry? Was the post-condition checked? Did a human approve the exact operation that later ran?
Those questions cannot be answered reliably from a chat transcript.
Long-running agents introduce another risk: partial work.
An investigation may run for hours. A connector can fail after five successful steps. A model endpoint can time out. A human approval may arrive the next morning. A deployment can occur while work is still in progress.
A system that responds by starting from the beginning can duplicate effects, lose evidence or reinterpret an already approved decision under a different execution context.
Facthory therefore treats durability as a correctness concern, not merely a convenience feature.
At stable boundaries, work can be checkpointed. Completed operations are preserved. Retries are bounded by execution semantics. External effects are designed to be idempotent where possible. In-flight work remains associated with the execution contract under which it began rather than silently inheriting new behavior mid-run.
The exact checkpoint representation, scheduling logic, retry strategy, version-binding mechanism and recovery algorithms are proprietary. What matters externally is the guarantee we engineer toward: failure should not erase history or cause the runtime to improvise around an uncertain state.
Multiplayer is often presented as a productivity feature: multiple people and agents can work in the same persistent project.
For consequential AI, it is also a control primitive.
A single-user copilot concentrates proposal, interpretation and action inside one conversational path. That is convenient for low-risk work. It is weaker for decisions where independent review, separation of duties or qualified approval matters.
Facthory can place different people and agents into the same governed context while giving them different responsibilities.
One agent can produce the analysis. Another specialist can challenge the evidence. A maintenance engineer can inspect the recommendation. A quality owner can validate the effect on product release. For higher-consequence decisions, policy can require multiple accountable humans before execution is possible.
This is the four-eyes principle expressed as runtime behavior, not a policy document somebody is expected to remember.
The important part is not that every action requires two people. That would make automation unusable. The system should increase human involvement as consequence, uncertainty, safety impact or organizational materiality rises.
Low-risk work can flow. High-risk work can stop.
And the person who is accountable must be able to override, reject or terminate the workflow rather than merely watch an autonomous system continue.
A human approval step is meaningless if the reviewer cannot understand what they are approving.
For this reason, a review request should carry an evidence package, not just an agent recommendation.
Depending on the workflow, that package can include:
the proposed action
the operational objective and affected scope
source evidence and provenance
assumptions and known uncertainty
alternatives considered
relevant policy or procedural constraints
model, tool and execution versions
expected consequences
unresolved contradictions
the exact action that will execute after approval
This reduces a dangerous failure mode in AI-assisted work: automation bias. A polished answer can make uncertainty look resolved when it is not.
The system should therefore make disagreement visible. Conflicting evidence, weak provenance, low-confidence interpretation or missing authority should produce an escalation state rather than a more persuasive paragraph.
In ordinary SaaS, logs primarily help engineers debug software.
In agentic systems, logs also establish accountability.
A trustworthy runtime needs to reconstruct what the system knew, what it proposed, why it was permitted, who approved it, what actually executed and what changed afterward.
For Facthory, traceability is part of the execution model. It is not something added afterward by scraping application logs.
That distinction is important because operational evidence can become part of future reasoning. If a root-cause investigation is later reused by another agent, the organization should be able to distinguish approved findings from intermediate hypotheses and tool output from human decisions.
Model benchmarks are useful. They are not sufficient for an industrial system.
The runtime fails if the model is accurate but the wrong document version was retrieved. It fails if the reasoning is correct but the connector returned stale data. It fails if an action is retried twice. It fails if a human approves one operation and another is executed. It fails if a model upgrade subtly changes tool behavior. It fails if an adversarial instruction embedded in a document can cause the agent to cross a permission boundary.
Trust therefore has to be measured across the whole socio-technical workflow.
NIST's AI Risk Management Framework makes a similar lifecycle point: trustworthy AI requires continuous governance, mapping, measurement and management of risk rather than a one-time model assessment. Source: NIST AI Risk Management Framework
Our engineering approach reflects that philosophy through multiple classes of checks:
| Risk surface | What must be measured or controlled |
|---|---|
| Model behavior | Task accuracy, uncertainty, refusal behavior, structured-output validity, regression across model versions |
| Evidence quality | Provenance, source authority, version, freshness, completeness, contradiction |
| Tool execution | Authorization, argument validity, idempotency, timeout behavior, post-conditions, rollback or recovery |
| Workflow robustness | Checkpoint recovery, dependency failure, retries, version changes, partial execution, degraded services |
| Human control | Correct reviewer routing, approval integrity, separation of duties, override and safe-stop behavior |
| Security | Least privilege, tenant isolation, prompt-injection resistance, secrets handling, unauthorized tool use |
The test target is not "did the LLM answer correctly once?"
It is does the complete system remain inside its guarantees when components behave imperfectly?
That means testing normal paths and failure paths: unavailable tools, stale evidence, malformed outputs, connector latency, duplicate events, interrupted runs, model changes, permission changes and adversarial inputs.
This is one of the most important rules in Facthory's architecture.
The model does not authenticate users. It does not assign itself permissions. It does not decide which tenant it belongs to. It does not promote a read operation into a write. It does not waive an approval because it considers the action obvious.
Those decisions belong to deterministic enterprise controls.
This boundary also limits prompt injection and model manipulation. Even if a malicious instruction influences the reasoning layer, it still encounters a separately authoritative permission and execution layer.
The right security question is therefore not "Can the model ever be manipulated?"
It is "If the model is manipulated, what can it actually cause the system to do?"
That blast radius should be explicit and bounded.
No production AI system remains static.
Models change. Tool APIs change. enterprise data changes. New failure modes appear. Operational procedures evolve. Attack techniques improve. A workflow that was low-risk can become material because the surrounding business process changed.
For that reason, trustworthy execution requires a closed engineering loop.
We do not want an opaque agent that silently "learns" from its own output and changes production behavior without governance.
Validated outcomes can strengthen organizational memory, but changes to execution behavior belong behind evaluation and release controls. This separates organizational learning from uncontrolled runtime self-modification.
For industrial environments, that distinction is essential.
Trust does not require publishing the mechanisms that create competitive advantage.
Facthory's public architecture is intentionally specific about guarantees and boundaries while remaining abstract about the proprietary machinery that implements them.
We do not publish details of our:
internal orchestration algorithms
execution scheduling and work partitioning
checkpoint and state representation
policy compilation and evaluation internals
evidence scoring and acceptance thresholds
model-selection and routing logic
recovery and retry heuristics
context construction and compression
evaluator composition
internal watchdog and anomaly-detection mechanics
Those mechanisms are part of the engineering IP behind the platform.
What customers should be able to understand is the contract: models reason inside bounded context; deterministic code controls authority and state; humans retain decision rights; high-consequence work can require independent review; actions are traceable; failures are recoverable; and changes to the system are measurable and governed.
The most capable industrial AI systems will not be the ones that eliminate probabilistic reasoning.
They will be the ones that know exactly where probabilistic reasoning is allowed to end.
At Facthory, we are building around that boundary.
Agents can explore. They can generate hypotheses. They can coordinate specialists. They can work for hours. They can use different models. They can surface information a deterministic rules engine would never discover.
But they cannot turn uncertainty into authority by themselves.
Our proprietary Rust orchestration harness provides the durable control structure around them: executable workflow semantics, governed state transitions, bounded tool execution, verification, evidence history, human checkpoints and multi-person decision gates where consequence requires them.
The result is not deterministic AI.
It is something more useful for industrial operations: non-deterministic intelligence inside a deterministic, inspectable and accountable operating system.
