The Core Loop

The Failure Mode

Every AI-powered mission runs into the same wall. Not a capability failure — an infrastructure failure.

The failure mode is the same: high-frequency forgetfulness. The model is brilliant inside a moment. But across moments, there's no persistence layer. No state. No continuity. The mission doesn't compound.

The Five Primitives

AetherForge's response is five intentional primitives. Not a framework — a minimal set of concepts that, together, provide everything an agent needs to maintain mission continuity.

2.1 mission

The mission is the top-level unit. A persistent object with an identity that survives sessions. It has: an objective, a set of constraints, a status (planning/active/blocked/completed/failed), and timestamps. Everything else in the system is attached to it.

What it replaces: ad hoc session initialization prompts. Instead of "here's the context for this session," the agent asks: "what's the current state of Mission #47?"

2.2 reality_fact

A timestamped, source-attributed observation. Not a belief, not an assumption — a record of something observed, with provenance.

id              UUID PRIMARY KEY
mission_id      UUID NOT NULL REFERENCES mission(id)
content         TEXT NOT NULL        -- "staging DB has 2.3GB of data"
source          TEXT NOT NULL        -- "pg_dump stdout", "user email", "schema query"
confidence      DECIMAL(3,2)         -- 0.00–1.00
observed_at     TIMESTAMPTZ NOT NULL
created_at      TIMESTAMPTZ DEFAULT now()

Reality facts are immutable after creation. They represent what was observed, not what is currently true. This is critical for audit trails — if the agent made a decision based on a fact that later turned out to be wrong, you can reconstruct the decision context exactly as it was.

What it replaces: vector store entries (opaque retrievals vs auditable, source-attributed, temporally ordered records).

2.3 decision

A record of what the agent chose and why.

id                  UUID PRIMARY KEY
mission_id          UUID NOT NULL REFERENCES mission(id)
context_slice_id    UUID REFERENCES context_slice(id)
action             TEXT NOT NULL        -- "Use pg_upgrade instead of pg_dump"
rationale           TEXT NOT NULL        -- "pg_upgrade is in-place, requires less downtime"
expected_outcome    TEXT NOT NULL        -- "Migration completes in ~20 min with ~0 downtime"
outcome             TEXT                 -- filled in after validation
decided_at          TIMESTAMPTZ NOT NULL
created_at          TIMESTAMPTZ DEFAULT now()

Decisions are not execution logs — they're the agent's reasoning made durable. When expected_outcome doesn't match what actually happened, that delta is the most valuable signal in the system.

What it replaces: scratchpads, internal monologue, "let me think through this" chains that evaporate when the session ends.

2.4 context_slice

A relevance-scored, temporally weighted assembly of facts and decisions relevant to a specific task. The agent's working memory for a given moment — assembled fresh from the mission's accumulated history.

id              UUID PRIMARY KEY
mission_id      UUID NOT NULL REFERENCES mission(id)
task_label      TEXT NOT NULL        -- "Run the migration script"
relevance_score DECIMAL(5,2)         -- aggregate relevance of included facts
time_weight     DECIMAL(3,2)         -- decay factor based on fact recency
drift_flag      BOOLEAN              -- true if new facts contradict older ones
slice_json      JSONB NOT NULL       -- { facts: [...], decisions: [...], scores: [...] }
assembled_at    TIMESTAMPTZ NOT NULL
created_at      TIMESTAMPTZ DEFAULT now()

Drift detection: if a new reality_fact contradicts an earlier one, context_slice gets drift_flag = true. The agent knows its model of reality has shifted.

What it replaces: manual context window management, chat history dumps, "let me summarize what we know" prompts.

2.5 validation_event

The system closing the loop — outcome verification that connects decisions back to reality.

id              UUID PRIMARY KEY
mission_id      UUID NOT NULL REFERENCES mission(id)
decision_id     UUID REFERENCES decision(id)
check_label     TEXT NOT NULL        -- "pg_upgrade completed without error"
check_result    TEXT NOT NULL        -- "exit code 0, 2.3GB migrated in 18 min"
status          TEXT NOT NULL        -- "pass" | "fail" | "inconclusive"
validated_at    TIMESTAMPTZ NOT NULL
created_at      TIMESTAMPTZ DEFAULT now()

The delta between expected_outcome (decision) and check_result (validation_event) is the feedback signal that drives the loop.

What it replaces: nothing in today's agent stacks. Validation is the missing piece.

The Schema — Six Tables

In addition to the five primitives, there is one supporting table:

capability

id              UUID PRIMARY KEY
mission_id      UUID REFERENCES mission(id)  -- null means general capability
skill_name      TEXT NOT NULL               -- "postgres_upgrade", "rollback_procedure"
proficiency     DECIMAL(3,2)                -- learned confidence, 0–1
learned_from    UUID REFERENCES decision(id)
times_used      INTEGER DEFAULT 0
last_used_at    TIMESTAMPTZ
created_at      TIMESTAMPTZ DEFAULT now()

When a validation_event confirms a successful outcome, and the agent did something novel to achieve it, that skill gets recorded here. Future missions with similar needs can be routed to the relevant capability. The system gets faster the more it runs.

Worked Example — "Migrate Production Database to Postgres 16"

What's Next

Open API (Q3 2026): Full public API with SDK support for Python, TypeScript, and Go. Design partners get early access in July.

Design Partner Program: We are working with 12 agent framework teams who need persistent mission infrastructure underneath their execution layer. If you're building a coding agent, a research agent, or a workflow automation system, you have the same problem. Apply for early access →

MCP Server (Q4 2026): AetherForge as a Model Context Protocol server — so any MCP-compatible agent can connect directly to its mission state. No custom integration required.

The core loop is the foundation. What's built on top of it — autonomous code agents, research synthesizers, multi-agent coordination, long-horizon planning — that's where it gets interesting.