A E G I S E SIntelligence with integrityRead as text ↗
PUBLIC ARCHITECTURE / 01

AGI Reactor A Safe, Governable Reference Architecture for Enterprise AGI

AUTHORRyan Smithright — Qthonic Labs

AGI Reactor is a reference design for persistent agents that carry knowledge and commitments across replaceable executions—with explicit authority, bounded resources, recoverable effects and human control.

“Safe” describes the architecture’s specified safeguards within its declared scope and trust assumptions. This is a reference design, not certification of a deployed system or a claim of general alignment.

Explore the architecture ↓
Public design draft 1.414 September 2026Architecture and validation criteria · not a deployment certification

Policy-governed service orchestration is all you need

The thesis is architectural composition: reasoning, memory, work, policy, learning and recovery are services. Their governed contracts also change the system itself. Durable state, explicit authority and recoverable effects are part of those contracts.

One specimen across the diagrams. Message M-17 asks to send an approved report to a named recipient. Ticket T-42, agent AG-7, attempt A-3, logical step STEP-1 and operation OP-9 retain distinct identities. The report service is illustrative; the worked fault test below uses a local HTTP target.

V4 · D1 / The reference machine
100%Full size ↗
The reference machinePlanned architecture. Labels, relationships and evidence limits also appear in the article text.D1 / REFERENCE DESIGNThe reference machineOne governed service model connects intent, cognition, state and external effects.People / chat / UIM-17: send the approvedreport to a named recipientCONTROL / STATE SERVICEOne initial deployment; distinct owned contracts.Intake + workTicket T-42 / one assigneePolicy + bindingsIdentity / active rulesAttempt + operation admissionCurrent generation / immutable OP-9 / budgetsubmitresult / unresolved statusNATS / JetStreamCore: calls and signalsJetStream: durable deliverypublishCommit state + outbox before notification; broker acknowledgment is not work completion.PostgreSQLAuthoritative recordsObjects / links / operationsowns transactionsCompositorPermitted context → frameresolve contextIsolated workerReason / plan / proposeframenotifyclaim attemptEffect boundaryService enforcement+ governed adapterinvokepolicy + OP-9 admissionTarget / providerTool, model or enterprise APIsendreply or lossrecord result / UNKNOWNHOST + SUPERVISOR / CONTROL BELOW THE MODELIsolation, scoped egress and resource ceilings apply to execution.Pause blocks new admission; already-admitted operations remain accountable.Arrows show logical calls and records. NATS transports crossings; owning services enforce them.Policy, models, learning, release and recovery are capabilities composed through governed services.
Read the owners and labeled crossings. Open full size for an uninterrupted view.Editable whiteboard ↓
Persist obligations.
Replace execution.

A model invocation can end. A process can fail. A service can change. Identity, commitments, unresolved operations and evidence remain recoverable in service-owned state.

A small vocabulary, with real semantics.

Objects retain identity and state. Typed links connect any relevant objects. Messages carry attributed communication. One invocation envelope exposes typed service methods. Each resource has an owning service, revision checks and explicit lifecycle.

D2 / Definitions and durable objects
100%Full size ↗Editable ↓
Definitions compose. Obligations endure.Planned architecture. Labels, relationships and evidence limits also appear in the article text.D2 / REFERENCE DESIGNDefinitions compose. Obligations endure.Three views of the same object model · proposed relationships · arrows name the relationship01One source can create several durable objectsSource attribution is preserved; extraction does not activate a policy or assign work.Source message M-17“Send the approved report.”EdictVersioned directionTicket T-42Durable obligationyields 0..manyyields 0..manyIndependent relationshipsThe same message may yield both,either, or several of each.Each derived object cites M-17.02Definitions and authority follow different pathsOwning services version definitions and bindings. Policy authority remains separately controlled.EdictProposed directionPolicy revisionValidated rule + scopePolicy bindingRule ↔ typed scopeEnforcerOwning serviceauthorizedpromotion0..manybindingsapplies atTemplatesExamples + edictsSkill revisionVersioned procedureAgent typeComposed profileAgent AG-7Stable identity0..manysource links0..manyskill bindingsclassifiesSkill ≠ grantType ≠ identityBindings are typed links; definitions are not processes.03Execution changes; identity and effect intent surviveControl/state service owns ticket, attempt and operation records/admission. Adapters enforce admitted calls.Ticket T-42Acceptance + revisionDurable result / recoveryAttempts A-3 → A-40..many over ticket lifetimeAt most one current attemptOperation OP-9T-42 / STEP-1 retains the IDOriginal intent is immutablerecords attemptsauthorized custodymay transferAgent AG-7Same identity as aboveassigned to 0..1Resource revisionChecked by owning serviceinvocation carriesexpected revisionEvidence E-9Receipt, failure or UNKNOWNhas 0..manyOne assignee does not lock shared resources.Concurrent tickets still require resource-level revision checks or transactions.OP-9 binds tenant, original caller, method, targetand canonical argument digest. Takeover cannot change them.
One source can yield both edicts and tickets. Policy revisions and skill revisions follow distinct paths. An agent type classifies an identity; it is not the running process. The control/state service owns ticket, attempt and operation records in the initial design. Each resource owner enforces its own concurrency contract.

Object

A ticket, agent, service, edict, skill or observation with a stable identity and versioned state.

Link

A relationship with meaning and provenance: assigned to, depends on, supports, contradicts or governed by.

Message

An attributed communication. Chat, commands and committed events share transport, not authority.

One transactional state service owns object changes and an outbox. Consumers deduplicate into an inbox and commit before acknowledging. World State, indexes and embeddings are derived views. PostgreSQL is the default starting point; blob storage remains behind service references.

A ticket makes an obligation durable.

A ticket preserves outcome, acceptance, state, one assigned agent and a result. It survives the process doing the work. Parallel activity uses linked tickets; assignment is never mistaken for proof of execution.

D4 / One operation through time
100%Full size ↗Editable ↓
One operation through time.Planned architecture. Labels, relationships and evidence limits also appear in the article text.D4 / REFERENCE DESIGNOne operation through time.A response can reach a worker while the durable obligation remains unresolved.M-17 message → T-42 ticket / STEP-1 logical step → A-3 attempt → OP-9 operation01 Accept into durable custodyChat M-17 arrives through NATS.Commit T-42 + source link + outboxbefore reporting acceptance.02 Dispatch durable notificationPublish committed outbox to JetStream.Reuse the same event identity.Dispatch does not confer execution rights.03 Acquire current attemptDeduplicate; atomically claim A-3.T-42 assignee: Agent AG-7.Commit execution custody before ACK.ACKNOWLEDGMENT ≠ COMPLETIONT-42 remains the durable obligation after broker acknowledgment.Worker / attempt A-3Control / effect serviceExternal targetTIME ↓A-3 custody committed; bounded execution beginsRequest OP-9 for logical step T-42 / STEP-1Commit OP-9 admissionBind immutable intent; serialize custody.Intent = tenant + original caller + method+ target + canonical argument digestCommit UNKNOWN before sendingAdapter sendsTarget commits exactly one effectHTTP 200 reaches worker; result has not been committedWorker crashes after 200No success result is saved.Controller knows: UNKNOWNIt cannot infer success or safe retry.External reality: one effectOnly the test oracle can count it.Backup contains UNKNOWNTaken after the external effect.No transaction spans the controllerand this non-idempotent target.No idempotency key.No target status lookup.RESTORE CONTROL STATE; DO NOT RESTORE EXTERNAL REALITYFence admissionEstablish epoch 2 + recovery holdoutside the restored database.Epoch 1 is refused: STALE_EPOCH.T-42 → NEEDS_RECONCILIATION.Preserve unresolved identityOP-9 stays UNKNOWN.Replay returns OUTCOME_UNKNOWN.Replacement ID for STEP-1 is refused.A new attempt grants no replay right.Changed intent is INTENT_MISMATCH.Give uncertainty an ownerAssign an authorized reconciler.Inspect · record finding · escalate.Without admissible evidence, stop.No ordinary Retry; preserve OP-9.After hold release, the per-operation guard must still refuse blind replay.RFC-001 / OBSERVED REFERENCE SPECIMENLocal HTTP + SQLite + actual worker crash after 200.Guarded restore: 1 effect, 0 duplicates, still UNKNOWN.Unsafe reset: 2 effects; the safety assertion fails.PLANNED / REQUIRES DEPLOYMENT QUALIFICATIONNATS / PostgreSQL, concurrent controllers, real identityand containment are not exercised by this specimen.A backup predating OP-9 requires an additional test.M-17 / T-42 / A-3 / OP-9 are diagram aliases; RFC-001 publishes its exact fixture identities and evidence.
State and outbox commit before notification. A consumer acquires and commits current custody before acknowledging. An operation retains its identity across attempts. If a target accepted a non-idempotent request but success was not saved, UNKNOWN survives recovery; a replacement operation is not a safe retry. RFC-001 witnesses only the specific local HTTP/SQLite fault described below.

Assignment

Zero or one agent, changed atomically. The accountable identity survives worker replacement.

Attempt

One current execution generation per ticket, with bounded custody and an explicit return point.

Operation

A durable service effect bound to immutable intent. Already accepted operations survive worker takeover.

The scheduler admits work against capacity, priority and budget. Routines and reactions create or wake work through the same contracts. Resource owners reject conflicting revisions. Queue delivery does not establish assignment; an expired worker cannot admit new effects.

One service contract, several entry points. CLI, UI, routines and event subscribers invoke the same typed operations. A reaction binding names its event type, conditions, input mapping, operation, version and accountable owner. One event may produce several legitimate reactions. Deduplication distinguishes the event and binding while preserving existing operation identities when a binding changes.

Intelligence returns with its place intact.

The loop observes, composes, reasons, acts, evaluates and consolidates. Its persistent state carries obligations and learning while models and harnesses remain replaceable.

Compositor

Resolve permitted sources; assemble a bounded frame with intent, acceptance, constraints, pending operations and source revisions.

Knowledge

Preserve observations, uncertainty, contradictions and correction. A model summary remains derived content.

Learning

Propose versioned lessons and skills; compare outcomes against a baseline before promotion.

Required continuity is never silently dropped to fit a context window. Frames do not grant authority. Access, sensitivity and retention travel into derived material; model submission is itself a governed disclosure. Deterministic coordination handles routine work so cognition can focus on ambiguity and invention.

Explode the cognition & learning diagram V3.B3 / Cognition & learningPlanned architecture. The full contracts and equivalent text are documented on this page.V3.B3Cognition & learningIntelligence is a loop with memory, evaluation and stopping conditions.V3.B / OVERVIEWOBSERVE → BUILD A VIEW → CHOOSEPerceiveAttributed observationsComposeScoped, bounded frameReasonHypotheses + plansACT → COMPARE → LEARNInvokeService admissionEvaluateExpected vs observedConsolidateVersioned correctionsCompositor contractPrincipal + ticket + permitted sourcesIntent · acceptance · applicable edictsAssignee · attempt · pending operationsReturn point · ranked optional contextManifest: source revisions + compilerMissing required input is explicit.Knowledge contractObservations retain time and source.Hypotheses retain uncertainty.Conflicts and corrections stay linked.A model summary is derived content.Access applies before serialization.Frames do not grant capabilities.Learning earns promotionSkills, memory procedures and model routes evolve through representative evaluation.Compare task quality, cost and recovery against a baseline. Retain a usable old version.Learned guidance may propose policy changes; it cannot grant itself authority.Start with deterministic assembly; add sophistication only for measured benefit.HUMAN + AGENT CONTROLThe loop may wait, ask, stop or resume. Budget limits are mechanically enforced.A returning agent recovers obligations and uncertainty before admitting another effect.

Every consequential crossing has a boundary.

An aegis binds identity, policy, scoped grants and an attributable operation record. It governs both action and information release. Human control and changes to the governing rules use explicit authority.

D3 / Policy becomes enforcement
100%Full size ↗Editable ↓
Rules become enforceable decisionsPlanned architecture. Labels, relationships and evidence limits also appear in the article text.D3 / REFERENCE DESIGNRules become enforceable decisionsOne source can create policies, acceptance conditions and reusable guidance. Each follows its own contract.Edict / source spanAttributed requirementwith intended applicabilityPolicy candidateTyped authorization rulesproposeValidate + reviewSchema / tests / impactAuthorized approvalqualifyActive versionExact bytes + scopeactivateSkill / procedureVersioned guidance+ adoption requirementsderive guidanceAcceptance / reviewTask-specific criteriaObserved evidence requiredderive conditionsBindingsPrincipal / typeObject / actionbind versionPolicy decisionApplicable rules + factsDeterministic evaluationresolveCompositorContext informs reasoningIt confers no authority.composeInvocation proposalCaller / action / targetOP-9 / argument digestinformacceptance contextService enforcementDecision + current scopeBudget / revision / custodyrequestevaluate at admissionfactsevidenceAdapterAdmitted effectallowRefused / expired / missing required evidenceRecord the reason. No new external effect.denyRULE CHANGES USE THEIR OWN GOVERNED OPERATIONSPrivilege expansion requires distinct author and approver.Review is conditional on the governing contract; ordinary requests do not require a universal human approval step.Revocation blocks new admission. Accepted operations survive policy changes and require explicit reconciliation.
Edicts can produce authorization policy, acceptance conditions and reusable guidance. Activated policy versions bind to typed scopes. The service supplies request facts to the decision and enforces the result together with budget, revision and operation custody. Required evidence is checked by its owning workflow or validator; guidance entering context never grants authority.

Before execution

Authenticate the caller; authorize the method, resource, destination and scope; reserve budget; persist operation identity.

At execution

An isolated worker uses scoped adapters. Infrastructure credentials and unrestricted network egress are unavailable.

After execution

Record results and inspect effects. A lost reply triggers reconciliation of the same operation, not a replacement.

The operation ID binds tenant, caller, method, target and argument digest. A changed binding is rejected. Target idempotency and outcome queries are used where available. When neither can resolve a sent request, the outcome remains UNKNOWN and automatic replay stops. A successor reconciles under its own scoped authority while preserving the original caller and intent; custody transfers are separately recorded. Policy, identity, budgets and release controls require separate administrative capabilities.

Replace services. Preserve the system.

Stable contracts decouple service identity from its process, model and storage implementation. Begin with a small operational footprint and add distribution only when workload or availability needs justify it.

Bound execution

Supervisor, concurrency limits, resource allowances, backpressure, deadlines and retry ceilings operate below the model.

Upgrade in place

Isolate a candidate; qualify live canaries; route explicit traffic stages; keep the old version hot through stabilization.

Recover deliberately

Drain bounded calls; resume long work from durable continuations; preserve compatible state and operation custody.

Failed or stale evidence stops promotion; breached criteria route traffic back. Old and new versions share the operation ledger, including timers and reconcilers. Restore starts with effect admission disabled until older workers, external outcomes and newer revocations are reconciled. One recoverable host is a viable first deployment, not host high availability.

Explode the runtime & evolution diagram V3.B5 / Runtime & evolutionPlanned architecture. The full contracts and equivalent text are documented on this page.V3.B5Runtime & evolutionStable service identities. Replaceable implementations.V3.B / OVERVIEWStart with a small operational footprintNATS + JetStream · transactional control service · compositor · workers · adaptersHost OS + supervisor isolate, restart and bound processes.Split deployments for fault containment, load or independent release—not every noun.REPLACE A SERVICE WITHOUT RESTARTING THE WHOLE SYSTEMIsolateZero ordinary trafficQualifyLive canary evidenceRampPolicy-controlled stagesTHE OLD VERSION STAYS HOT THROUGH STABILIZATIONDrainStop new assignmentResumeDurable continuationStabilizeCompatible stateResource stewardshipReserve allowance before dispatch.Cost / tokens / CPU / memory / timePriority · fairness · concurrency limitsBackpressure · timeout · retry ceilingFinOps proposes reviewed refactoring.Failure containmentFailed/stale canary → stop promotionBreached criteria → hot fallbackExpand / migrate / contract schemasOne operation custodian across versionsRestore starts with admission disabled.VIABLE FIRST / SCALE WHEN THE OUTAGE BUDGET REQUIRES ITOne recoverable host is not host high availability. Prove backups and restore.Broker, database and host maintenance remain separate operational responsibilities.

Safety must be
inspectable.

Here, safety means containing identified hazards within a declared operating scope. A policy decision is necessary; it cannot alone prove that an authorized action is appropriate.

Scope and trust assumptions

The design assumes correctly enforced host isolation, trustworthy administrative roots, usable cryptography and service implementations that meet their declared contracts. It does not establish general alignment, harmlessness of every authorized action, or protection from a compromised administrative root. Each domain needs its own permitted-use constraints and hazard analysis.

Design invariant → enforcing mechanism → validation specimen → evidence status
HazardEnforcing mechanismRequired challengeEvidence
Unauthorized actionAuthenticated caller + scoped service policy; generated code has no bypass path.Deny wrong tenant, target, expired grants and attempts to self-escalate.Designed
Private data disclosureRead and release policy; scoped model/tool egress; sensitivity on derived artifacts.Attempt forbidden provider submission, cross-account retrieval and secret leakage.Designed
Duplicate or stale effectsImmutable operation binding, durable custody and target-aware reconciliation.Duplicate command; race workers; crash after external acceptance; resume old version.Designed
Uncontrolled consumptionReserved allowances, scheduler admission, deadlines and retry ceilings.Exhaust budget, stall a dependency and flood the queue; retain stop control.Designed
Loss of human controlIndependent suspension and privileged control changes; admitted effects remain visible.Pause during reasoning and execution; prove new admission stops and in-flight work is accounted for.Designed
Unsafe evolution or restoreIsolated rollout, hot fallback, compatible state and a recovery admission barrier.Fail a canary; run old/new adapters; restore a backup older than an effect or revocation.Designed
Incorrect reasoning or poisoned memorySource attribution, contradictions, bounded tasks, outcome evaluation and scoped approval.Plant misleading instructions/evidence; verify they cannot grant authority or silently become truth.Designed

“Designed” means the contract and challenge are specified here. This publication does not supply end-to-end runtime test receipts. A future verified claim must link the exact implementation, environment, specimen, result and date. Documentation alone is not certification.

Prove the journey,
including the interruption.

Start with one useful service change requested through chat. The acceptance test crosses the whole architecture and returns a result a person can actually use.

  1. 01

    Receive

    Persist a useful request and recover the same ticket after losing its reply.

  2. 02

    Coordinate

    Race workers; enforce current custody, capacity and a real test budget.

  3. 03

    Understand

    Recover context, preserve a conflicting observation and produce a useful plan.

  4. 04

    Execute

    Crash after target acceptance; reconcile the same operation without a duplicate effect.

  5. 05

    Control

    Pause and revoke access; show enforced refusal and account for admitted work.

  6. 06

    Evolve

    Canary a service while its fallback stays hot; fail it and demonstrate recovery.

  7. 07

    Deliver

    A recipient uses the result; evaluate a source-linked lesson on follow-up work.

  8. 08

    Restore

    Recover an older backup without resurrecting stale workers, grants or completed effects.

Measure usefulness and control together.

Task quality · latency · total cost · recovery time · duplicate effects · recipient acceptance. Choose numerical service and recovery objectives for the workload before qualification.

Explode the whole-system trial + V3.B6 / Prove the whole systemPlanned architecture. The full contracts and equivalent text are documented on this page.V3.B6Prove the whole systemA useful end-to-end outcome is the unit of progress.V3.B / OVERVIEW01Receive & resumeAccept a real request; lose the reply; recover the same ticket.02Coordinate & boundRace workers, enforce one current attempt and a real budget.03Know & reasonCompose permitted context; preserve contradiction; make a useful plan.04Act & reconcileCrash after target acceptance; recover the original operation.05Stop & governPause new work; deny expired authority and exhausted allowance.06Evolve & recoverCanary a service change; fail it; use the checked hot fallback.07Deliver & learnRecipient uses the result; evaluate a source-linked lesson.08Restore & continueBlock effects; exclude old workers; reconcile outcomes and revocations.Measure usefulness and control togetherTask quality · latency · total cost · recovery time · duplicate effects · recipient acceptancePUBLIC ACCEPTANCE / aegises.org/agi-reactorAn outside human or AI can reconstruct the system, its safety contracts and its limits.

Complete without
multiplying primitives.

The enterprise orientation sections describe the operating world. They map into a small set of contracts; a heading does not require a new daemon, protocol or authority.

Orientation vocabulary mapped into the reference architecture; no account records or operational census are included.
ResponsibilityEnterprise sectionsArchitectural home
People & enterpriseEnterprise · Account · Org Chart · Projects · Roadmap · CampaignsPurpose, stakeholders, ownership, priorities and acceptance. Contract ↗
Interaction & orientationService Shell · Chat · Topics · Channels · Sessions · Tickets · Pinned · Urgent! · Dashboards · System DiagramsShared intent, bounded invocation, interruption, decisions and intelligible delivery. Contract ↗
Meaning & knowledgeOntology · Wiki · FAQ · Files · Skills · Memory Agents · Data SovereigntyTyped state, attributed knowledge, custody, retention, correction and retrieval. Contract ↗
IntelligenceAgents · Agent Onboarding · AI · Code HarnessesPersistent identity, bounded context, model routing, learning and recovery. Contract ↗
Work & timeTicketing · Dispatch · Workflows · Routines · ReactionsSingle ownership, dependencies, attempts, triggers and bounded execution. Contract ↗
Authority & custodyAegises · IAM · Keys · Policies · Wallets · TransactionsScoped powers, controlled data release, accountable finance and reconciliation. Contract ↗
Execution & economyPlatform Stack · Core Services · Integrations · Network · Hosts · Fleets · Domains · Billing · BudgetsService placement, connectivity, dependencies, capacity and resource limits. Contract ↗
Improvement & assuranceCode Repos · Testing · Gauntlets · Observability · FinOps → Dynamic Refactoring · AGI Reactor EngineeringExact artifacts, independent challenge, measured outcomes, safe change and recovery. Contract ↗
Research & participationResearch Labs · Aegises.org · PanSigna.org · Community · Civic Engagement · Careers · Partners · InvestorsResearch and participation connect to owned work; these are organizational surfaces, not kernel primitives. Contract ↗

One effect.
Two possible recoveries.

A target accepts a non-idempotent request and returns HTTP 200. The worker dies before saving success. A restored backup contains UNKNOWN. The test must catch recovery that sends the effect again.

Guarded recovery

One effect, zero duplicates. UNKNOWN remains unresolved; the original operation and replacement attempts are refused.

Broken recovery

Reset UNKNOWN to ready and clear the hold: two effects. The same safety assertion fails, as intended.

What was exercised

Real loopback HTTP, worker termination and SQLite backup. This is an isolated reference specimen, not qualification of a production NATS/PostgreSQL runtime.

The test oracle can count the external effects. The recovering controller cannot. An honest unresolved result is required when no admissible evidence can close the gap.

Read the complete fault schedule, assertions and operator contract +

Status: executable reference specimen · 14 September 2026 · Draft 1.1 companion.

Question

Can a recovered controller avoid repeating a non-idempotent external effect when its restored operation record cannot establish whether the effect happened?

The required outcome is one effect and an honestly unresolved commitment. Silently treating the operation as successful would be as incorrect as retrying it. Liveness is intentionally sacrificed for the affected step until admissible evidence resolves the uncertainty.

System under test and limits

The supplied reference guard uses Python's standard library, a real loopback HTTP target, an actual worker subprocess, SQLite transactions and the SQLite backup API. The target commits an append to its own ledger before returning HTTP 200. The worker reads that response, then terminates with exit code 86 before saving success.

The target implements neither an idempotency key nor a status route. Each POST appends another record. Only the test oracle reads the target ledger to count effects; the recovering guard never receives that path or a query capability. Oracle knowledge must not become production evidence.

This is a small, single-controller reference implementation for falsifying a recovery algorithm. It does not exercise NATS, PostgreSQL, concurrent admission, distributed custody, real authentication, actual sandbox containment, provider behavior, multi-host failure or production deployment. The local epoch file represents recovery authority outside the restored database; it is not a production implementation of that authority. Its persistence, monotonicity and exclusion of old processes remain deployment obligations.

Fixed input

{
  "ticket": "ticket-001",
  "assignee": "agent-a",
  "step": "ticket-001/step-1",
  "operation": "operation-001",
  "epoch": 1,
  "intent": {
    "tenant": "specimen",
    "caller": "agent-a",
    "method": "append",
    "target": "local-receipt-ledger",
    "arguments": {"receipt": "R-001"}
  }
}

The operation binds a SHA-256 digest of canonical JSON: sorted keys, compact separators, UTF-8. This fixture uses only strings and objects; general cross-language canonicalization is not specified by this example. A unique workflow-step binding prevents replacement operation IDs from evading unresolved work.

Fault schedule

StepActionController knowledgeExternal reality
0Persist ticket, step and immutable operation bindingADMITTED; epoch 1No effect
1Commit conservative send-intent before issuing POSTUNKNOWN: the call may be sentNo effect yet
2Target commits receipt R-001 and returns HTTP 200Worker receives 200; durable record still UNKNOWNExactly one effect
3Terminate worker with exit code 86 before result commitUNKNOWN; no durable success evidenceExactly one effect
4Take a control database backup while UNKNOWN; attempt retryRetry returns OUTCOME_UNKNOWNExactly one effect
5Restore that backup; establish epoch 2 and an admission hold outside restored stateTicket NEEDS_RECONCILIATION; operation UNKNOWNTarget ledger is not restored
6Retry from epoch 1STALE_EPOCHNo new effect
7Change the arguments, invent a replacement ID, and replay the originalINTENT_MISMATCH; RECOVERY_HOLD; RECOVERY_HOLDNo new effect
8Test-only probe: remove global hold without changing UNKNOWNOriginal → OUTCOME_UNKNOWN; replacement → STEP_ALREADY_HAS_OPERATIONNo new effect
9Inspect the test-only oracleGuard still knows UNKNOWNExactly one effect; zero duplicates

Step 8 isolates the per-operation guard so a global hold cannot mask a broken UNKNOWN check. The harness directly removes that hold; it does not implement or qualify the production barrier-release policy.

UNKNOWN starts before send because no atomic transaction spans the control database and the external target. A crash before transmission may therefore also produce uncertainty. The runtime must not silently reinterpret UNKNOWN as “sent,” “failed,” or “safe to retry.”

The trace restores the control database without restarting the target or rolling back its effect. It models the asymmetric restoration boundary, not a full infrastructure disaster. A backup predating the operation's existence, lost revocations, concurrent old/new controllers and transfer of adapter custody need additional deployment specimens.

Assertions

  • Initial execution actually reaches the target: effect count before restore is exactly 1. “Never send anything” cannot pass.
  • Worker exit is 86, reached only after reading HTTP 200; the backup contains UNKNOWN.
  • Guarded restore leaves the operation UNKNOWN and the ticket NEEDS_RECONCILIATION.
  • Old-epoch, changed-intent, replacement-ID and same-operation requests cannot produce a new effect under the hold.
  • The independent target oracle counts exactly 1 effect after recovery attempts.
  • No success result or settled outcome is inferred from the oracle by the guard.

Negative control: make the algorithm fail

The unsafe-reset-on-restore mode deliberately converts UNKNOWN to ADMITTED and clears the recovery hold. Replaying the original operation then creates a second external receipt.

The very same target-count assertion must fail. This control demonstrates sensitivity to the identified defect; it does not prove completeness against every recovery defect. The normal test suite expects and catches that assertion failure, so both suite tests pass when the test oracle works.

python3 -m unittest discover -s agi-reactor/conformance -v
python3 agi-reactor/conformance/unknown_restore.py --assert-safe
python3 agi-reactor/conformance/unknown_restore.py --mode unsafe-reset-on-restore --assert-safe

The last command is expected to exit 1 with duplicate external effect after UNKNOWN restore. It is an intentionally failing specimen, not a production mode. All runs use an automatically allocated loopback port and disposable local state. No third-party target or real customer operation is contacted.

Operator contract: uncertainty is a working state

A blocked operation must expose, together: ticket and step, immutable operation identity, original initiating principal, current assignee/reconciliation owner, last admitted intent, last trustworthy evidence and time, why the outcome is unknown, next inspection action and escalation deadline. The system must distinguish an assigned operator from an actually delivered alert; notice delivery and acknowledgment are recorded independently.

The safe surface offers inspect evidence, assign reconciliation, record a finding, and escalate. It does not offer an ordinary Retry button for an unresolved non-repeatable effect. Repeated alerts are bounded and have an escalation owner. Deleting or dismissing an alert does not clear the operation hold.

A finding must preserve source, scope, observer and observation time. A separately authorized reconciliation operation can record confirmed success or confirmed absence only under the adapter's declared evidence rules. “No record found” is not proof of absence when the provider can still commit a delayed request or its observation is incomplete. If a target cannot establish final absence, the operation stays unresolved. An authorized risk acceptance for a fresh action is a distinct decision and operation, linked to the unresolved predecessor; it cannot be reported as a safe automatic retry or erase duplicate risk.

Cancellation blocks new work but cannot unsend an accepted effect. Closure may record accepted uncertainty; it must retain the unresolved effect and its audit trail. In this specimen no admissible target evidence reaches the controller, so the correct terminal observation is still UNKNOWN.

Adjacent review requirements

  1. Compositor non-escalation. A deployment qualification vector must plant grant-widening instructions in a permitted wiki object and a derived summary. Execute the resulting grant-change request through the real boundary. Assert that effective grants and external effects remain unchanged; a textual refusal is insufficient. This vector is specified, not implemented by RFC-001.
  2. Policy promotion. A suggested lesson remains advisory until a versioned policy candidate passes typed validation, a scoped impact analysis, adversarial tests and independently authorized approval. Privilege-expanding changes require distinct author and approver identities; the same principal cannot satisfy both roles. Activation is bound to exact policy bytes and scope, with expiry where appropriate and a recoverable rollout. An LLM's recommendation and a human click are not evidence of informed review.
  3. Service split criteria. A proposal to split the initial control service must identify measured lock/queue contention against a declared latency objective, an independently required release boundary, or a fault/trust boundary. Include the state owner, transaction boundary, migration and rollback, new failure modes and expected operational cost. An ontology heading or desire for symmetry is insufficient.
  4. Kernel growth. A new primitive, protocol or daemon must name the consumer and invariant that existing contracts cannot satisfy. Prefer a typed object, method or projection until evidence requires another boundary.
  5. Isolation qualification. Isolation is mandatory. Each deployment names its host/sandbox, effective privileges, egress policy and relevant escape/bypass tests. CHERI/seL4 is a candidate substrate with its own qualification obligations; drawing that label does not establish end-to-end containment.

Evidence classification

Observed here: a real local side effect; crash after 200; backup containing UNKNOWN; guarded refusals; and a negative control that creates a duplicate and fails the assertion. These are reference-specimen results. Production controls remain Designed until the same fault schedule is exercised against the actual services with attributable receipts.

Zero observed duplicates is necessary for this specimen to pass. It is not an exactly-once guarantee for arbitrary external systems or a universal safety certificate.

The backup in this specimen is taken after the target effect, while the controller still records UNKNOWN. Restore from a backup predating the operation, concurrent admission and production barrier release remain separate qualification cases. Zero observed duplicates in this specimen is not a universal exactly-once guarantee.

The decisions
behind the diagram.

Concrete record semantics, concurrency rules, effect recovery, learning, governance and upgrade tradeoffs. The complete text is included in this page and available as a plain-text companion.

Read or download the complete Markdown specification ↗
Read the full technical specification +

Architectural judgment

The architecture should make a persistent agent's knowledge, commitments, authority and resources coherent across replaceable executions. Its defining quality is continuity with consequence: it can resume useful work without guessing what happened, exceed neither its authority nor its resource allocation, and improve without discarding its obligations.

NATS is the communication kernel. The kernel contract is larger: authenticated invocation, owned state transitions, durable commitments and recoverable operations. The host OS still isolates and schedules processes. These are deliberate responsibility boundaries, not objections to a service-oriented system.

The compressed semantic surface is object, link, message; invoke. This is a working design constraint, not a claim that three universal tables solve every domain. State machines, authorization, transactional storage, scheduling and reconciliation remain real implementation responsibilities. If compression hides one of these, it has failed.

Safety scope and assumptions

Safety here means containing identified hazards within a declared operating scope: unauthorized effects, disclosure, duplicate effects, uncontrolled resource consumption and loss of human control. Each consequential service declares permitted use, action constraints, foreseeable hazards, enforcement points and validation specimens. Authorization alone does not establish that an action is appropriate. This architecture does not establish general alignment, harmlessness of every authorized action, or safety against a compromised administrative root.

Workers and generated code run without infrastructure administration credentials or unrestricted external egress. Tool access, model-provider submission and external destinations pass through scoped adapters. Authorization covers reading information and releasing it to a destination. Retrieved instructions remain untrusted content; they cannot change authority. Tenant and sensitivity constraints propagate into frames, derived artifacts, logs and indexes, with explicit retention and deletion behavior.

Whole-system coverage

ResponsibilityViable first implementationExpansion trigger
Human purpose and controlConversation, explicit outcome and acceptance, priority, pause/cancel, decisions and observed deliveryMultiple stakeholders need negotiated portfolio allocation
Identity and authorityStable principal, scoped delegation, policy at service boundaries, revocation, tenant isolationAdditional trust domains require federation
Shared meaning and stateTyped objects and links, owning services, revision checks, provenance, attributed assertionsMeasured query or schema needs exceed the initial relational model
Perception and knowledgeAdapters turn observations into attributed records; retrieval carries source, time, uncertainty and contradictionMore modalities or measured retrieval deficits
Cognition and learningBounded compositor, replaceable models, explicit hypotheses/plans, outcome evaluation, versioned lessonsDemonstrated improvement on held-out tasks warrants more automation
Work and coordinationTickets with one assignee, dependencies, bounded attempts, routines, events, deadlines and cancellationMeasured throughput/fairness needs exceed simple admission
Effects and reconciliationTyped invocation, durable operation identity, target-aware idempotency, outcome query and evidenceNew effect domains require new adapters/contracts
Runtime and economicsSupervisor, bounded concurrency, admission budgets, health, usage and restart backoffActual capacity pressure or availability requirement
Evolution and recoveryIsolated candidates, staged traffic, hot fallback, compatible state, backup/restore trialFailure-domain requirements justify replicated infrastructure
Human/agent orientationWorld State and UI projections over the same authorized records; visible source freshnessNew consumers require new projections, not new authorities

Semantic contract

  • Object: stable ID, type/schema version, owning service, revision, attributed state. Ticket, agent, edict, skill, service, observation, hypothesis and context frame are domain types. A principal is an identity, not a model process. A service identity is not its current implementation instance.
  • Link: typed relationship between object IDs, with provenance and temporal/revision scope where meaningful. assigned-to, depends-on, supports, contradicts, governed-by, implements, supersedes. No fixed semantic fan-out, but every traversal has access, depth, time and result limits. Not every link creates a scheduling dependency; dependency cycles must be rejected or explicitly resolved.
  • Message: immutable attributed communication with ID, kind/schema, sender, intended recipient/scope, correlation and causation, body and references. Chat is the conversational form of IPC. Natural-language content is not executable authority. Typed commands require admission; events report committed facts. Transient presence and token streams need not be retained as durable commitments.
  • Invoke: one envelope, typed methods. invoke(service, method, target, arguments, operation_id, expected_revision?, frame_ref?, attempt_generation?, deadline, budget_ref) with authenticated caller authority supplied by the transport/session. A request naming a principal does not authenticate it. Responses distinguish rejected, accepted/pending, succeeded, failed and unknown. Cancellation and status are discoverable service methods. This is illustrative notation, not a claim that those exact endpoints exist today.

Keep the domain vocabulary rich and the protocol small. Do not flatten a policy into an ordinary note or an observation into a fact merely because they share a record form.

Concrete placement

Start with a small number of deployments: NATS + JetStream; one transactional control/state service; a compositor; agent workers; governed effect adapters; a supervisor. Identity, policy, catalog, ticket scheduling, inbox and outbox can begin as modules behind the control service's contracts. Split processes for measured load, independent release or failure containment, not for every noun in the ontology. Untrusted execution belongs outside that process.

The control/state service owns transactional object revisions, links, ticket assignment, active attempt generation and operation records. PostgreSQL is my default backing store for these atomic changes and relational queries. Reuse existing storage only where it provides this contract; changing storage is a separate implementation decision with a migration plan. Blobs, source code and large artifacts remain in suitable stores behind references. “Everything is a service” means stable mediated access; it does not require replacing physical files with individual daemons.

Use Core NATS for bounded request/reply and disposable signals. Use JetStream for recoverable dispatch and committed change propagation. Accepted work must reach durable custody before the UI reports acceptance. SQL state plus outbox event are one transaction; an outbox publisher retries using the same event identity. A consumer deduplicates into its inbox and commits the resulting state before acknowledging. Broker duplicate suppression helps, but is not the permanent application operation ledger.

The control database is authoritative for the records it owns. JetStream is the delivery/replay substrate for retained events, not a second editable ticket authority. Search, embeddings, World State and dashboards are rebuildable projections with source revisions and freshness. Do not begin with a requirement to reconstruct every object solely by replaying all history.

Ownership is simple; concurrency is enforced

A ticket has zero or one assigned agent, one acceptance contract and a durable result/recovery record. Assignment is updated atomically against an expected revision. Begin with one active attempt per ticket. Parallel work uses linked tickets with separate assignees; it does not make one ticket multiply owned.

Assignment survives worker replacement. An execution attempt has a generation and bounded custody; renewals and reassignment use authoritative state. Workers cannot create their own valid generations. A named-agent dispatch route does not itself authorize execution. Queue groups distribute messages; they do not establish business assignment.

At the effect boundary, the service admits an operation against current authority, ticket/attempt generation and target revision. A stale worker cannot start a new operation. An already admitted operation remains durable owned work and may finish after the initiating worker dies; reassignment does not erase it. The next worker reconciles it. Cancellation is cooperative for work already committed to an external system.

At first admission, bind the operation ID to tenant, authenticated caller, method, target and canonical argument digest. Reuse with a different binding is rejected. Retries and successors recover the ID from the durable workflow step; they do not replace it while the outcome is unresolved. Adapters declare the target idempotency scope and retention window. A successor uses a separately authorized status or reconciliation method referencing the existing operation; it does not resubmit the original effect with a different caller binding. The original initiating principal remains immutable, while the reconciler identity and any custody transfer are separately attributed. Reconciliation cannot widen the admitted effect scope.

An effect gateway must make admission and operation ownership durable and serialize competing attempts for the same operation. A one-time generation check followed by unconstrained direct external calls is insufficient. Where a target supports idempotency keys, reuse the operation ID. Where it supports status lookup, reconcile. Where neither exists, a crash after sending can leave UNKNOWN; stop automatic retries and expose the uncertainty. No database transaction or NATS acknowledgment can erase that boundary.

Different tickets may target the same object: its owning service serializes or rejects conflicting revisions. Tickets are a durable coordination abstraction, not a global lock for every linked object. Multi-service workflows use explicit steps and compensating actions where available; no universal distributed transaction is required.

A durable dispatch notification can be acknowledged once the state service has accepted execution custody and a reconciler can find abandoned work. Do not use an hours-long unacknowledged broker delivery as the only ticket lifecycle. A low-cost deterministic reconciler repairs expired attempts, unpublished outbox entries and stuck operations; it does not wake a model when no reasoning is needed.

Cognition must include more than context assembly

The compositor receives principal, ticket, permitted sources and resource limits. It resolves access before traversal, retrieves relevant material, and assembles a versioned frame manifest with source revisions and compiler version. Required continuity includes purpose, acceptance, assignee, active attempt, applicable constraints, unresolved operations and return point. Missing required material produces an explicit incomplete frame. Optional material is ranked and bounded.

A frame is a bounded view, not a copy of the entire world or a bearer capability. There is no promise of a global atomic snapshot across external services: each source reports revision/time, and consequential writes recheck their preconditions. An initial deterministic compositor is easier to inspect; model summaries can later become attributed, cached derivative objects.

Perception produces observations. Reasoning produces hypotheses, plans and proposed actions. Evaluation compares expected and observed outcomes. Consolidation proposes corrections, lessons and skill changes with provenance. Do not silently promote a model's confident summary into canonical truth. Preserve conflicting observations and invalidation links; use appropriate uncertainty representations rather than a universal invented confidence number.

Memory retrieval, procedural skills and model inference remain replaceable services. Improved behavior is promoted after representative evaluation and bounded trials. Learned policy suggestions cannot grant authority. Budgets, stop conditions and an independent supervisor bound the loop; cognition may choose to wait or ask a human instead of generating more tasks.

Authority and human agency

Authenticate principals; bind scoped authority to service methods and resource targets. NATS subject permissions constrain transport; the service still enforces object-level policy and tenant scope. Enforce revocation at new operation admission, with explicit expiry/cache behavior. The policy service must not depend on an LLM to decide ordinary admissibility.

Changing policy, identity, resource ceilings, routing or release controls requires a distinct administrative capability and an attributable versioned change. Ordinary work cannot enlarge its own authority or disable its enforcing boundary. Emergency suspension blocks new effect admission independently of models. If a control service is unavailable, only explicitly defined safe operations remain available; cached authority has bounded expiry.

Edicts retain the original distinction between laws/standards, SOPs, guidelines and examples. Machine-enforceable requirements become versioned policies at the relevant boundary. Advisory guidance informs composition. Ambiguous prose does not become a deny rule by accident. Approval is a scoped decision object with identity, expiry and conditions when required, not a generic confirmation loop.

Human interfaces expose meaningful controls: change priorities, inspect reasons/evidence, pause, cancel future work, decide exceptions and receive a usable result. Pausing cognition, blocking new effect admission and undoing a completed external effect are distinct operations. A supervisor can stop new work even when a model or optional UI is unhealthy. Secret values stay in managed secret storage; ordinary frames contain references and only the minimum needed context.

Resources, reliability and upgrades

Every execution is admitted against bounded concurrency and a resource allocation: model/token quota, money, CPU/GPU, memory, wall time and downstream capacity are distinct dimensions. Reserve an allowance before dispatch, account usage, cap retries and release unused capacity. Priority and fairness belong in the scheduler. Backpressure, timeout, retry delay, quarantine and load shedding must be specified; they cannot be delegated to “the agent will figure it out.”

Service identity and contract stay stable while implementation instances change. Start vNext isolated with zero ordinary traffic. Qualify with attributable live canaries. A governed router/controller allocates explicit traffic stages. Keep the old version hot and continuously checked through stabilization; stop promotion on stale/failed evidence and return traffic automatically when criteria breach. Ordinary NATS queue sharing is not that rollout controller.

Old and new versions share the authoritative operation ledger. Dispatch, reconciliation, timers and background jobs acquire custody through the same protocol. A rollout cannot grant both versions permission to send the same non-repeatable effect. Compatible continuation and operation formats are qualification requirements. If safe transfer is not established, the old instance retains the operation or it enters reconciliation; upgrades do not justify blind replay.

Stop assigning new work to an old instance, drain bounded in-flight requests, and resume long work from durable continuations. Preserve schema and message compatibility across old/new versions using expand/migrate/contract. Delay destructive cleanup until fallback is no longer required. Secret rotation, routing and policy updates are likewise versioned control-plane changes. The broker, database and host have their own maintenance procedures; avoiding a global application restart does not eliminate maintenance.

Start with one recoverable host if its outage budget permits: persistent volumes, supervised processes, real backups and a witnessed restore. This can survive worker crashes; it does not provide host availability. A multi-node NATS cluster and a highly available database are separate later decisions. Avoid a premature orchestration platform or bespoke storage engine solely to make the architecture sound complete.

Restoring older state begins with new effect admission disabled. Recovery establishes a new runtime epoch, excludes old workers, reconciles retained events and external outcomes, and restores or revalidates authority changes newer than the backup. Missing evidence blocks replay of affected effects. Dispatch resumes only after this recovery barrier is satisfied. The selected workload must define recovery-point and recovery-time objectives before qualification.

Prove one complete system before widening it

Use a small representative service change requested through chat, with acceptance that a human can verify. Include one relevant knowledge correction and one pause/resume so cognition and human control are tested alongside transport.

  1. Receive the request; persist acceptance and link source intent. Lose the acceptance reply and recover the same ticket by operation identity.
  2. Admit a budget, assign one agent and race two workers. Exactly one current attempt may admit new effects. A resumed stale worker is refused.
  3. Compose bounded context, preserving a contradictory source and a pending operation. Denied material cannot enter the frame. Demonstrate useful planning, not merely valid JSON.
  4. Execute a reversible representative effect; redeliver its command and kill the worker after the target accepts but before reply persistence. Reconcile the same operation; never create a replacement solely because its reply was lost.
  5. Pause new work and exhaust a small test budget. Neither condition should depend on the model politely stopping; the service boundary refuses further admission. Already admitted work remains visible.
  6. Upgrade the effect service through isolated candidate, canary and a small traffic stage while the old instance remains hot. Inject a failed/stale canary and demonstrate rollback. Preserve the ticket and operation identities across versions.
  7. Deliver a result the recipient can use; record their acceptance and update the derived World State. Consolidate a source-linked lesson; compare a follow-up task against baseline before promoting a new skill.
  8. Restore durable state from backup in an isolated environment and recover unresolved commitments. Check object revisions, operation status and replay boundaries together, not just that the process boots.

Measure completion quality, latency, total cost, recovery time, duplicate effects, stale-worker refusals and usability of the result. Set numerical SLOs from the chosen workload before implementation qualification. These are planned acceptance specimens, not reported test results.

Design judgment / explicit decisions

  • Persist obligations and evidence; make model executions replaceable.
  • Prefer rich domain meaning over many protocols or transport-specific nouns.
  • Put enforcement beneath simple interactions. A user assigns one agent; the runtime handles attempts and failures.
  • Spend cognition on ambiguity and invention; use deterministic code for routine coordination.
  • Treat uncertainty as state that can be resolved, not prose that gets forgotten.
  • Build service contracts first, with few deployments. Separate implementations when evidence justifies it.
  • Pay for redundancy and abstraction when a named consumer needs them.
  • Evaluate learning and usefulness as seriously as delivery and authorization.
  • Make continuing, stopping and recovering understandable to both human and agent.

An architecture
open to examination.

Author: Ryan Smithright (ryan@smithright.com). Developed from his architecture work and World State vocabulary, with architecture development, visualization and implementation assistance from Astra / Codex. This revision includes a focused independent AI critique of the design; that is architectural review, not security certification or runtime verification.

The “all you need” formulation proposes a smaller coordinating model: governed service contracts compose the system and its evolution. In the architectural simplification tradition of Attention Is All You Need, the burden is a concrete construction and experiments that can challenge it.

The application contracts and safety criteria are proposed architecture. NATS transport guarantees do not establish external-effect idempotency, object authorization or AGI capability.

V4 adds four relationship diagrams. Read preserved public draft 1.3 ↗ · Download the complete V4 whiteboard ↓

For an independent reader

Can you reconstruct the components, their authority boundaries, their failure behavior and the evidence still needed—from this page alone?

Critique the design against those contracts. Do not infer implementation from documentation.