World

The Problem: Task-Oriented Agents

AI coding agents are reactive. They wait for instructions, execute them, and stop. This creates a fundamental limitation: the human becomes the intelligence, breaking down intent into discrete tasks and feeding them to the agent one by one.

1.1 The Decomposition Tax

Every feature requires the developer to decompose their intent into tasks the agent can execute. This decomposition is itself skilled work — it requires understanding the codebase, the domain model, the dependencies, and the right order of operations. The agent consumes tasks but cannot generate them from intent.

1.2 Silent Drift

Between development sessions, nothing watches the codebase. A model gains a field without a validation. A controller drifts from its specification. An association disappears during a refactor. These misalignments accumulate silently because no system continuously verifies that reality matches intent.

1.3 The Missing Primitive

Task-oriented agents operate on imperative commands: do this, then that, then check. But software has a natural declarative structure: entities have fields, fields have constraints, entities have relationships, behaviors connect actors to outcomes. No agent framework provides a persistent, testable declaration of what the software should be — independent of any specific task.

World: Architecture

World is a desired-state engine that maintains a persistent, testable model of what software should be. A convergence loop called Heartbeat continuously compares this model against reality and dispatches an AI agent to close any gap.

2.1 The World Model

A World is a Ruby DSL that declares application structure at a semantic level. It is not code generation configuration. It is a domain model that exists independently of any target stack:

World.define(:vet_practice) do
  entity :owner do
    has :name, type: :string
    has :email, type: :string, required: true, unique: true
    has :phone, type: :string
  end

  entity :pet do
    has :name, type: :string, required: true
    has :species, type: :string
    has :owner, type: :reference    # infers belongs_to + inverse has_many
  end

  behavior :book_appointment do
    actor :owner
    trigger on: :form_submit, screen: :new_appointment
    precondition { |state| state[:pet] && state[:vet] }
    outcome "Appointment created and confirmation sent"
  end
end

From this declaration, the system can project a complete Rails application, verify existing code against it, generate test hypotheses, simulate behaviors, and detect drift — all without human involvement.

2.2 The Convergence Loop

Heartbeat — a Rust daemon — ticks every 8 minutes. Each tick runs the brain, which executes a three-stage fidelity check:

1. Model Stability — Run all hypotheses against the World model itself. If the model has internal contradictions, stop and report. The model must be sound before checking code.
2. Code Fidelity — Read actual project files. Compare them against the World using AST-aware structural parsing. If drift is found — a missing validation, a dropped association, a divergent controller — fix it in place.
3. Code Coverage — Generate tasks from uncovered World objects. If entities exist in the World but have no corresponding code, create them.

The brain dispatches Claude Code with the World model exposed as an MCP (Model Context Protocol) server. Claude reads the model, reads the code, identifies the gap, and writes the fix. The next tick verifies convergence.

2.3 The Operator Pattern

This architecture directly mirrors the Kubernetes operator pattern. The World is the desired-state declaration (like a Kubernetes manifest). Heartbeat is the reconciliation loop (like a controller). Claude Code is the actuator that modifies reality to match the declaration. The system continuously converges toward the declared state.

The World DSL

The World DSL provides a complete vocabulary for declaring software structure. It is deliberately higher-level than code — it captures intent, not implementation.

3.1 Primitives

• Entity A domain object with fields, constraints, and relationships. Fields declare type, required, unique, format, inclusion, numericality, and length constraints. Reference fields automatically infer belongs_to and inverse has_many associations.
• Behavior An action that connects an actor to an outcome through a trigger. Behaviors have preconditions, outcomes, and can be tested through hypotheses. They map to controllers, services, or action methods in the projected code.
• Service An internal or external capability. External services declare their API contract. Internal services encapsulate domain logic. Both can have capabilities and connections.
• Screen A user-facing interface within an application. Screens contain components (forms, tables, buttons, modals) and navigations. They represent what the user sees, not how it renders.
• Infrastructure Database, cache, queue, or other backing service. Declares what the application depends on without specifying deployment details.

3.2 Reference Resolution

When an entity declares has :owner, type: :reference, the World resolves this after all entities are defined. It creates a belongs_to :owner on the referencing entity and a has_many :pets on the referenced entity. This means the developer declares the domain relationship once; the system infers both sides.

3.3 Hypotheses and Scenarios

The World model is testable. Hypotheses verify expected outcomes of behaviors. Scenarios chain multiple behaviors into multi-step sequences with state tracking. Both run against the model itself — no code required. If a hypothesis fails, the model is inconsistent. If a hypothesis passes but the code doesn't match, the code has drifted.

Fidelity Checking

The fidelity checker is the critical bridge between the World model and reality. It performs AST-aware structural comparison — not string matching, not grep, but semantic verification that the code expresses what the World declares.

4.1 What Gets Checked

• Entity presence — Does a model file exist for each World entity? Does it declare the correct class?
• Validations — Does the code enforce presence, uniqueness, format, inclusion, numericality, and length constraints declared in the World?
• Associations — Does the code declare has_many, belongs_to, has_one, and has_and_belongs_to_many relationships matching the World's relationship map?
• Behaviors — Does a controller, service, or action method exist for each World behavior?

4.2 Target Awareness

The fidelity checker understands target stacks. For Rails, it checks model files, validates macros, and association declarations. For Next.js, it checks TypeScript interfaces, field types, and API route handlers. The same World model projects and verifies across stacks.

4.3 Drift Classification

Each drift item has a type, severity, affected file, and human-readable message. Severities are either error (must fix — structural mismatch) or warning (should fix — convention mismatch). The brain fixes errors autonomously. Warnings are logged for human review.

Properties

5.1 Continuous Convergence

The system never idles. Every 8 minutes, reality is compared against intent. Drift is detected within one tick and fixed within two. The codebase continuously converges toward the World declaration without human intervention.

5.2 Declarative, Not Imperative

The developer declares what should exist. They never write tasks, tickets, or step-by-step instructions. The system decomposes intent into action autonomously. Changing the World model is sufficient to change the code — the convergence loop handles the rest.

5.3 Testable Intent

The World model is not documentation. It is executable. Hypotheses run against it. Scenarios simulate multi-step workflows. The model itself can be validated for internal consistency before any code is generated or checked.

5.4 Stack Independence

One World model projects into multiple target stacks. The same vet practice declaration can produce a Rails application, a Next.js application, or both. Domain logic is captured once; implementation details are projection concerns.

5.5 Auditable Convergence

Every brain cycle is logged with its session ID, duration, cost, and outcome. The journal records what was checked, what drifted, and what was fixed. Full provenance of every autonomous action.

Comparison with Existing Approaches

The gap: every agent framework is task-oriented. They execute what they're told. None of them maintain a persistent model of what the software should be. None of them continuously verify that reality matches intent. None of them autonomously fix drift without being asked.

Demonstration: Autonomous Drift Correction

The following scenario was executed on 2026-02-22 against a vet practice application.

Success Metrics

World instruments five metrics from day one. The primary validation question: does the code match the World model? If fidelity holds, the system works.

1. Fidelity score — Percentage of World objects with matching code. Target: 100% at every tick.
2. Drift detection latency — Time between code change and drift detection. Target: one tick (8 minutes).
3. Autonomous fix rate — Percentage of drift items fixed without human intervention. Current: 100% for validations and associations.
4. Convergence time — Time from drift introduction to confirmed fix. Current: two ticks (16 minutes).
5. Cost per cycle — LLM cost per brain cycle, reported by Claude Code from Anthropic's token pricing (input + output tokens across all turns). Current: $0.32 per fidelity check (~23 API round-trips).

Implementation

9.1 Tech Stack

• World model: Ruby DSL (37,000 lines)
• Convergence loop: Rust (Heartbeat daemon, axum + redb)
• Agent: Claude Code via CLI with MCP
• Fidelity checker: AST-aware structural parser (Rails + Next.js)
• MCP server: World exposed as 25+ tools via JSON-RPC
• Platform: macOS (Apple Silicon), launchd-managed

9.2 Current Scope

One developer, one World model, one target stack (Rails). Brain ticks every 8 minutes with a budget of 5 invocations per hour, 50 per day. Fidelity checking covers entity models, validations, associations, and controller presence. Projection generates complete Rails applications from the World model.

9.3 Roadmap

• Stage 1 (current): Solo — One developer, one World, one Claude Code agent. Prove the fidelity loop converges autonomously.
• Stage 2: Team — Multiple Claude Code agents working in parallel, coordinated by a shared World. Different agents own different parts of the model.
• Stage 3: Generalize — Strip coding specificity. Apply the desired-state convergence pattern to non-code knowledge work. The World primitive is domain-agnostic; only the projectors and fidelity checkers are stack-specific.

Conclusion

World addresses a fundamental gap in AI-assisted software development: the absence of persistent intent. By declaring what software should be rather than instructing an agent what to do, it eliminates the decomposition tax that fragments every development session.

The architecture applies a proven infrastructure pattern — desired-state convergence — to software development. The World model is the manifest. The Heartbeat loop is the controller. Claude Code is the actuator. Drift is detected in minutes and corrected autonomously.

The real change is not speed. It is continuity. The system never forgets what the software should be. It never stops checking. It never waits to be asked. Between sessions, between days, between developers — the World holds the intent and the loop maintains the truth.

Declare the World. The loop does the rest.

Contact

Email: delaney@zero2one.ee
Web: https://zero2one.ee