What is GenOS

What is GenOS?

GenOS is an experimental runtime and data model for versioned AI-agent execution. Its thesis is that serious agents need the same kinds of control that software engineering gained from version control, reproducible builds, test gates, and provenance.

An agent should not merely produce an answer. It should be possible to ask:

• What exact state did the agent start from?
• Which hypothesis was being tested?
• What changed in memory, beliefs, files, and goals?
• Could an alternative have run from the same baseline?
• Which evidence selected the winner?
• Can the supported state transition be replayed without calling the model again?
• Where did this result come from, and what is its lineage?

GenOS turns those questions into first-class data and operations.

The problem with a single mutable timeline

A typical agent loop looks like this:

prompt → model → tool → changed world → more context → model → tool → result

Once the world and context have changed, alternatives are difficult to compare fairly. Retrying may use a different prompt history, a different file state, a changed provider, or a different tool result. Even when the final answer is correct, the path that produced it is often poorly preserved.

GenOS replaces this with versioned execution:

baseline → snapshot → fork hypotheses → execute in isolation
                                  ↓
                   evaluate → diff → replay → promote

Four ideas that distinguish GenOS

1. Fork state, not just prompts

A branch carries an identity, genome, working state, world reference, event cursor, and budget. Two branches can share ancestry without sharing mutable execution state.

2. Treat hypotheses as executable objects

A branch can record why it exists: “minimal boundary fix”, “remove the abstraction”, “invalidate the cache assumption”. The result can then be evaluated against the hypothesis and the same gate as its siblings.

3. Separate generation from verification

The model may propose a future. Tests, invariants, scores, replay checks, or a human policy decide whether that future is promoted. This is the foundation of safe parallel debugging and counterfactual evaluation.

4. Preserve causal structure

Snapshots, events, parent links, correlations, diffs, and merge manifests retain more of the path from baseline to outcome. GenOS aims to make “why this state exists” inspectable.

Where GenOS fits

Adjacent system	Primary concern	GenOS adds
Agent framework	Prompts, tools, orchestration	Versioned state, alternative futures, replay, lineage
Workflow engine	Steps and retries	Agent/world capsules and evidence-aware branch selection
Git	Source history	Agent state, event history, budgets, beliefs, and runtime worlds
Container/sandbox	Process isolation	Causal history, semantic state, branch hypotheses, and promotion rules
Evaluation harness	Scores and benchmarks	Snapshotted candidates, lineage, multi-objective selection, and replay

GenOS can complement these systems. It is not intended to replace a hardened sandbox, a general workflow scheduler, or a model provider.

Representative use cases

• Safe parallel debugging: generate or define several fixes, test them in sibling worlds, replay the winner, then promote.
• Incident investigation: fork competing root-cause hypotheses from a dated checkpoint and compare causal outcomes.
• Agent policy experiments: mutate drives or genomes, run controlled cohorts, and evaluate phenotype divergence.
• Multi-objective search: preserve candidates that trade correctness, cost, latency, risk, or novelty differently.
• Belief provenance: track claims, contradictions, evidence, and inheritance across agent lineage.
• Research reproducibility: publish the exact command, revision, raw events, environment metadata, and result bundle.

Product, research, and roadmap

GenOS deliberately contains three kinds of material:

1. Implemented local primitives backed by source and tests.
2. Experimental workflows backed by focused demos but still free to change.
3. Target architecture and biomimetic research that explores future runtime behavior.

The Examples & evidence page separates these layers. The distinction matters: an accepted design is not automatically an implemented guarantee, and a passing correctness test is not a performance benchmark.