LLMOS is the deterministic substrate DESIGNED to power every workflow on the Forge engine . It is specified and documented but not yet implemented — see Status . Today’s reproducibility comes from snapshot-per-turn at the session layer.
Why a runtime instead of a chat log
LLM calls are probabilistic. Ask the same question twice and you might get two different answers. For a chatbot that’s fine. For a multi-agent pipeline producing production code it isn’t.
LLMOS borrows from databases what databases borrowed from accountants: an immutable event log. Every prompt, every response, every state change is a numbered event in an append-only stream. The “current state” of any workflow is just a fold over that stream. So:
- Replay is trivial — feed the events to the projection function in order.
- Branching is cheap — copy a stream pointer, append divergent events.
- Audit is exact — every decision links back to the event that caused it.
- Reproducibility is structural — given the same events you always get the same state.
The probabilistic part (the LLM call) is contained inside individual events. The orchestration around them is fully deterministic.
The .llmos language
LLMOS workflows are written in a small DSL that compiles to a typed AST and runs on the event-sourced engine.
agent pm {
model = "claude-sonnet-4-6"
temperature = 0.2
max_tokens = 8000
}
agent architect {
model = "claude-opus-4-7"
temperature = 0.1
}
workflow design_session {
use pm
message system "You are a product manager writing acceptance criteria."
message user from input.issue_body
if tokens > 12k {
compress history using extract_facts(max=600)
}
snapshot pm_done
use architect
message system "You are a staff engineer designing the technical solution."
message context structured.goals, structured.constraints
emit
}
Layered memory
LLMOS treats memory as a stack of projections over the event log:
| Layer | What | Where | Purpose |
|---|---|---|---|
| L0 — Raw events | Every token, tool call, decision | PostgreSQL append-only table | Source of truth, immutable |
| L1 — Active context | What the model sees right now | Computed per turn | Token-budget-aware projection |
| L2 — Structured state | Goals, constraints, decisions, facts, open questions | Persisted, updated via events | Survives compression |
| L3 — Vector index | Embeddings of messages | pgvector | Semantic retrieval over history |
When a session approaches its context budget, LLMOS doesn’t truncate — it projects. The structured state in L2 (the decisions, the goals, the constraints) is preserved exactly. The raw chatter in L1 is summarised, deduplicated, or replaced with extracted facts. Nothing is destroyed; the L0 events are still there for replay.
Compression strategies
Four compression policies, picked per workflow:
summary— LLM-generated narrative compressing the conversation into a single system message. Cheap and fast, lossy on detail.extract_facts— Structured JSON extraction (goals/constraints/decisions/facts/questions). Recommended default. Updates L2 directly.semantic— Embedding-based dedup, no LLM call. Drops messages with cosine similarity above a threshold.structured— Most aggressive: extract_facts + semantic. Used for very long-running pipelines.
Compression is validated: extracted facts are checked against the source events to prevent hallucinated state. Decision conflicts (same topic, different values across compression rounds) resolve by sequence — the latest event wins.
Branching
fork microservices_path {
use architect
message user "Design as separate microservices"
emit
}
fork monolith_path {
use architect
message user "Design as a modular monolith"
emit
}
compare microservices_path monolith_path
using judge(model="claude-opus-4-7")
select best
Forking creates an isolated event stream that branches off at the current sequence number. Both branches run independently. compare calls a judge agent to evaluate them on user-specified criteria. select best merges the winning branch back into the main stream.
Branches don’t affect the main stream until merge. You can keep them for replay, or discard them.
Time-travel API
| |
When the Developer agent produces a buggy implementation in turn 47, you don’t need to re-run the whole pipeline — you can ForkFrom(stream, 46, "v2") and explore alternatives starting from the last good state.
Status
LLMOS is currently a research and design effort. The language spec, AST types, execution model, event schema, compression pipeline, and time-travel API are all designed and documented. Implementation has not started — Forge’s current pipeline uses a simpler, role-state-machine approach that ships today.
When LLMOS lands, Forge will migrate the multi-agent pipeline onto it for stronger reproducibility and easier branching. Until then, the pipeline gets reproducibility through snapshot-per-turn at the session layer.
Why this matters
The cost of probabilistic systems is often debugging cost. When something goes wrong in a multi-agent pipeline today, you scroll through chat logs trying to figure out which decision was wrong. With LLMOS, you replay to the offending event, diff the state before and after, and either rerun deterministically or fork into a corrected branch.
Infrastructure thinking, applied to AI orchestration. That’s the bet.