A sovereign ReAct agent harness under in-loop governance

1. Contribution

Claimed. This is a sovereign-first ReAct (reason + act) agent harness whose loop mechanics are validated independently of any model. The implementation comprises five concrete mechanisms: (1) a tool registry declaring tools in a familiar function-calling schema; (2) tool-result message threading that feeds tool outputs back into the reasoning loop; (3) a bounded loop guard limiting iteration count; (4) short-term memory scoped to a single task; and (5) an in-loop governance gate through which every tool call passes a governor and an audit step before dispatch. The harness passes its full self-test suite with a model-free harness — i.e. the loop plumbing, registry dispatch, result threading, loop bound, and governance gating are exercised without a model in the loop.

NOT claimed. This note does not claim any result about end-task quality, reasoning ability, or task-completion rate on open-ended tasks — those depend entirely on the model placed behind the harness, which is absent from the validated path. It does not claim tool-ecosystem breadth comparable to mature agent frameworks, nor any throughput, latency, or scale measurement (none were taken). The altitude is honest: this is an engineering/plumbing-correctness result (a harness that wires ReAct + governance correctly and is covered by a passing test suite), not a novel algorithm and not a quality benchmark. The harness pass count is a unit-test result for the harness mechanics, not an evaluation score.

2. Design

The agent occupies the Worker layer of the stack. Its design pillars:

The Worker is fed by a skill factory and a skill runtime: the same loop that acts is the one whose successful traces crystallize into skills, which later activate in place of re-derivation (act -> crystallize -> activate). Other coding/agent runtimes occupy the same Worker role; the architectural distinction described here is the in-loop governance gate and the skill-compounding layer behind the Worker, not a comparative-performance claim.

3. Evidence / Status

The only quantitative claim is the harness-test pass count and the existence of a bounded loop guard. No throughput, latency, accuracy, or task-success numbers exist, and none are introduced here. Everything beyond the harness mechanics (e.g. real-task performance) is prototype/architecture-level, not measured.

4. Limitations (harsh, honest)

• The pass count is a unit-test result, not a benchmark. It establishes that the harness plumbing behaves as specified; it says nothing about agent task quality, robustness on adversarial inputs, or coverage breadth. What each test asserts beyond "harness mechanics" is not detailed.
• Model-free validation has a ceiling. By design the validated path excludes a model, so the entire reasoning-quality dimension — the part that determines whether the agent is actually useful — is untested here. Parity-of-plumbing is not parity-of-behavior once a model is attached.
• No performance data. There are no latency, throughput, token-cost, or scaling numbers; nothing about how the governance gate or audit affects per-step cost.
• Tool-ecosystem breadth unquantified. The number and kind of registered tools are not enumerated, so claims of practical utility cannot be substantiated from this note.
• Single source of truth, single run. The pass count is reported once with no variance, no CI configuration, and no independent reproduction recorded.
• Evidence level. Carried forward as "experimental"; given that the only data point is a harness pass count, a reader could reasonably read this closer to an architecture/prototype note than a measured experiment. We do not silently downgrade the field, but flag it here.

5. Provenance / Relation

• Provenance: hardware was an Apple Silicon (M-series) machine; build and test ran via the platform's standard release build/test toolchain; sovereignty was verified by confirming reliance only on the platform-native acceleration library, with no third-party ML framework in the path. Exact build identifiers, version pins, and the test harness location are not recorded in source notes. The reproducible artifact described is the passing harness; exact invocation is not given.
• Relation: this Worker is fed by a skill factory and skill runtime (act -> crystallize -> activate). It is positioned alongside other coding/agent runtimes as a Worker; the described distinction is the in-loop governance gate and the skill-compounding layer, not a comparative-performance claim.
• Validate-first caveat: when a model is attached, the model path must be validated separately — the model-free harness does not transfer correctness guarantees to model-driven behavior.