Orbit Rover: Self-Evolving, Self-Healing AI Agent Systems at the Edge

AI agents can now do meaningful work across a remarkable range of domains. They can synthesise research, draft structured documents, diagnose system faults, process filings, and respond to events in the environment around them. The question is no longer whether the models are capable. It is how to deploy them in a way that is reliable, auditable, and able to improve over time.

That question matters differently depending on where you are building. A team working with a cloud API and a reliable network connection has one set of options. A builder working on an air-gapped workstation, a remote field device, or a factory floor controller has another. And anyone building workflows that need to run for months without active developer maintenance has requirements that neither context fully addresses on its own.

Orbit Rover is an open-source orchestration layer for CLI AI agents designed for exactly these conditions. It is pure bash, with no infrastructure dependencies, and runs anywhere you can run a shell and a CLI agent. It coordinates any CLI-based AI agent, including Claude Code, OpenCode, and local models via Ollama, making fully offline deployment a first-class option rather than a workaround.

The design is built around three ideas that compound on each other. First, that safety and reliability should be properties of the environment the agent operates within, not of the agent itself. Second, that a well-designed orchestration layer should be able to recover from its own failures without human intervention. Third, that a system running in a specific environment long enough should be able to improve at the work it does there, accumulating domain knowledge and refining its own tooling across runs.

The result is a governed, reactive, multi-agent orchestration system that runs on a laptop, a Raspberry Pi, or an air-gapped workstation, and gets better at its job over time.

This post explains what Orbit Rover is, how it works, and the theoretical frameworks that shaped its design.

What is Orbit Rover?

Rover is a declarative orchestration layer for CLI AI agents. You describe what should happen in YAML, specifying which agents run, under what conditions, in what sequence, and with what constraints, and Rover handles execution, monitoring, recovery, and learning.

It is important to be clear about what Rover is not. It is not a framework that wraps an LLM API. It is not a prompt chaining library. It does not manage conversation history or session state. The agents it coordinates bring their own runtime. Rover sits above them, managing the conditions under which they run.

The domain is any knowledge work

Most AI tooling is built around software development, with tasks such as code generation, code review, and CI pipelines. Rover makes no such assumption.

The only structural assumption Rover makes about an agent’s task is simple. There is input that can be read from disk, there is judgment that requires an LLM rather than a script, and there is output that can be written to disk and evaluated. That structure is universal. It describes code review. It also describes regulatory documentation, financial analysis, research synthesis, clinical documentation, and legal review. The agents do domain-specific work. The orchestration primitives are the same.

Zero dependencies by design

Most orchestration tools assume connectivity: a cloud state backend, a message broker, and an API endpoint to report to. Rover makes the opposite assumption. Nothing external can be relied upon.

This constraint is deliberate. It determines what the system has to be:

State lives on disk, inspectable and portable without a database
Coordination is local, using file-based signals between components rather than a message queue
Agents are self-contained, reading from disk, writing to disk, and exiting cleanly
Recovery is automatic, without requiring a human or a cloud service

The runtime requirements are minimal. Bash 4+, jq, and yq (or a python3 fallback) form the core. At least one agent adapter is required, either Claude Code or OpenCode. Optional dependencies include inotifywait for efficient file watching, gum for the terminal dashboard, cron for schedule sensors, and Ollama for fully local model inference. Run orbit doctor to verify your setup before you start.

When Rover is paired with Ollama, the system is end-to-end offline. No cloud model API calls, no data leaving the device. This is not a workaround for edge deployments; it is the intended architecture for contexts where data sovereignty is a requirement.

The configuration format is forward-compatible with Orbit Station (Go), which is in active development. Studios built with Rover today will run without modification when the broader platform ships.

The deterministic / adaptive boundary

A defining architectural choice in Rover is where it draws the line between two fundamentally different kinds of work.

Deterministic components are sensors, preflight scripts, and validation scripts. They observe the environment and compute without ambiguity. They produce facts such as whether this file exists, whether this condition holds, or whether this document contains the required sections, and they are fast, predictable, and resource-cheap.

Adaptive components are LLM agents. They receive the facts the deterministic layer produces and apply judgment, interpreting, inferring, deciding, and generating outputs that no script could produce. They handle what genuinely requires reasoning.

Rover keeps these cleanly separated. The deterministic layer provides signal. The adaptive layer responds to it. Neither is asked to do the other’s job.

This boundary has practical consequences. When a preflight script distils a large project directory into the few hundred tokens of context this particular agent needs for this particular task, the agent receives focused signal rather than raw complexity. Output quality improves. Resource overhead drops, whether that overhead is measured in API cost for cloud models or in inference time and power draw for local models running on constrained hardware. The architecture works because the expensive adaptive layer is only invoked for what it is uniquely suited to handle.

The orbit loop

Based on the ralph loop, the orbit loop is the core execution primitive. Everything in Rover composes from it. The name draws from a spacecraft navigation metaphor describing the repeated corrective manoeuvres a vessel makes to achieve and maintain orbit. Like its namesake, the orbit loop runs until a stable condition is reached, correcting course on each pass.

The loop runs as follows:

Rover spawns a fresh agent process for each orbit
A preflight script (deterministic) distils exactly the context the agent needs from disk
The agent reads context, applies judgment, and writes output to disk
The agent exits; a checkpoint persists relevant context for the next orbit
A success condition (deterministic) evaluates whether the promise flag is satisfied
If satisfied, the component exits. If not, Rover orbits again, up to a configured maximum.

flowchart TD
    A[Spawn fresh agent process] --> B["Preflight script<br>distils context from disk"]
    B --> C["Agent reads context,<br>applies judgment,<br>writes output to disk"]
    C --> D["Agent exits;<br>checkpoint persists context"]
    D --> E{"Success condition<br>satisfied?"}
    E -- Yes --> F["Component exits<br>Promise flag met"]
    E -- No --> G{"Orbit ceiling<br>reached?"}
    G -- No --> A
    G -- Yes --> H["Component exits<br>Ceiling reached"]

    style F fill:#2d6a4f,color:#fff
    style H fill:#9d0208,color:#fff

Disk is the only memory. Nothing of value lives in memory between invocations. Every state transition is inspectable by reading files in .orbit/. All state writes are atomic (write to a temp file, then rename), so power interruptions at any point leave state intact rather than partially written.

There is an important distinction between checkpoints and waypoints. Checkpoints persist agent context between orbits within a single component run, so the agent does not start cold on retry. Waypoints are mission-level checkpoints between stages, enabling a long workflow to resume from its last known-good position rather than starting over after an interruption.

Here is a complete component definition from the orbit-research studio:

component: researcher
agent: claude-code                # CLI agent adapter
model: sonnet                     # Model alias
prompt: components/researcher/researcher.md

preflight:                        # Deterministic scripts run before each orbit
  - scripts/distil-sources.sh
  - scripts/extract-findings.sh

delivers:                         # Files the component is expected to produce
  - findings/

orbits:
  max: 200                        # Orbit ceiling — high for large corpora
  success:
    when: bash                    # Success check mode (file | bash)
    condition: |
      jq -e '[.tasks[] | select(.done == false)] | length == 0' \
        {mission.run_dir}/plans/research/tasks.json
  deadlock:
    threshold: 5                  # Stall orbits before deadlock action fires

The component runs two preflight scripts that distil the relevant source material and extract existing findings, invokes the agent, and only exits when all tasks are marked done. If the agent runs five orbits without advancing the task list, the deadlock handler fires. The orbit ceiling of 200 reflects the reality of research work: a large corpus may require many focused passes, each processing a single task.

Missions

Missions coordinate components into multi-stage workflows. Each mission is a directed acyclic graph of stages with dependency ordering, optional parallelism, and configurable retry and flight rules. The same primitives work for a software build pipeline, a research workflow, or an infrastructure incident response process.

The two-tier decompose-then-execute pattern is the standard approach for complex work. A planning stage runs once, reads the full scope of work, and produces a tasks.json file. An implementation stage processes one task per orbit using orbits_to to loop until all tasks are complete. This keeps each agent invocation focused on a single atomic unit of work, which is where context discipline produces the biggest quality gains.

From orbit-sentinel:

mission: monitor
status: active

sensors:
  schedule:
    cron: "0 6 * * *"            # Trigger daily at 06:00

stages:
  - name: decompose
    component: source-decomposer
    waypoint: true                # Mission-level checkpoint for resume

  - name: analyse
    component: analyst
    depends_on: [decompose]
    orbits_to: decompose          # Loop back until exit condition met
    max_orbits: 100

    orbit_exit:
      when: bash
      condition: |
        jq -e '[.tasks[] | select(.done == false)] | length == 0' \
          {mission.run_dir}/plans/sentinel/tasks.json

  - name: assemble
    component: brief-writer
    depends_on: [analyse]

  - name: brief-gate
    type: manual
    prompt: |
      Daily intelligence brief ready.
      Review: intelligence/daily-brief.md
      Approve to archive and reset, reject to iterate.
    options: [approve, reject]
    timeout: 12h                  # Gate expires after 12 hours
    default: reject               # Safe default — closes rather than opens
    depends_on: [assemble]

flight_rules:
  - name: cost-ceiling
    condition: "metrics.cost_usd > 2.00"
    on_violation: abort           # Hard stop — not a warning

flowchart LR
    CRON["Cron sensor<br>06:00 daily"] --> D["<b>decompose</b><br>source-decomposer"]
    D -- waypoint --> AN["<b>analyse</b><br>analyst"]
    AN -- "orbits_to<br>(up to 100)" --> AN
    AN --> AS["<b>assemble</b><br>brief-writer"]
    AS --> G{{"<b>brief-gate</b><br>(manual)<br>timeout: 12h<br>default: reject"}}
    G -- approve --> DONE[Archive & reset]
    G -- reject --> ITER[Iterate]

    FR["Flight rule:<br>cost > $2.00"] -. abort .-> AN
    FR -. abort .-> AS

    style G fill:#e9c46a,color:#000
    style FR fill:#9d0208,color:#fff
    style DONE fill:#2d6a4f,color:#fff

The mission triggers daily at 06:00, decomposes the source watchlist, analyses each source over multiple orbits, assembles a brief, and holds for human approval before archiving. The flight rule enforces a hard cost ceiling at the orchestration layer regardless of what the agents do. If no human approves the brief within 12 hours, the gate defaults to reject rather than open.

Key Features

Reactive sensors

Sensors detect changes in the local environment and trigger work without manual intervention. Rover supports three sensor types. File watch uses inotifywait or a polling fallback. Interval fires on a time schedule without requiring cron. Cron delegates to the system crontab and is managed via orbit cron. File watch sensors support a cascade control flag that determines whether one component’s output can trigger another component’s sensor, enabling reactive chains across the system.

Debounce configuration prevents thrashing when files change in rapid succession. On a device with no network connectivity, the system still responds to local events and does real work.

Full documentation: docs/sensors.md

Flight rules

Flight rules are hard invariants enforced by the orchestration layer, not by prompting the agent. They specify conditions that must hold throughout execution, with configurable violation responses of warn, throttle, or abort.

flight_rules:
  - name: token-budget
    condition: "metrics.total_tokens < 50000"
    on_violation: warn            # Log warning, continue execution

  - name: cost-ceiling
    condition: "metrics.cost_usd < 5.00"
    on_violation: abort           # Hard stop — mission terminates
    message: "Cost ceiling reached. Stopping execution."

The difference between a flight rule and a prompt instruction is structural. A prompt instruction asks the agent to stay within budget. A flight rule makes it impossible for the workflow to continue if the budget is exceeded, regardless of what the agent does. On a device running unattended, this distinction matters because there is no engineer watching a dashboard to intervene.

Four exit codes distinguish different termination conditions. Exit 0 means the promise flag was satisfied. Exit 1 means the orbit ceiling was reached or a deadlock abort occurred. Exit 2 means a flight rule fired. Exit 3 means the operator issued a graceful stop via orbit stop.

Full documentation: docs/mission-safety.md

Tool system and governance

Rover’s tool system allows you to create custom deterministic processes that a CLI agent can invoke during a session. These are executable scripts placed in the project’s tools/ directory and can be written in bash, Python, or any language that can be run from a terminal. Each tool performs a specific, predictable operation such as reading logs, checking service health, restarting a process, or applying a configuration change. They extend what a component can do while keeping that work deterministic and inspectable, separate from what the agent reasons over directly.

The tool governance layer controls which of these tools each component is permitted to use. Components declare a tool policy of either standard, giving access to all available tools, or restricted, limiting access to only the tools explicitly listed.

When a restricted agent encounters a task requiring a tool it does not have, it emits a <tool_request> XML tag with justification. The request is queued in .orbit/tool-requests/pending.jsonl. A human reviews and grants or denies access via orbit tools grant or orbit tools deny. Auth keys verify that tool invocations originate from authorised component and mission combinations.

tools:
  policy: restricted              # Only assigned tools are accessible
  assigned:
    - read-logs
    - check-health
    - notify-operator

In orbit-fieldops, the remediator component has access to check-health and notify-operator without approval, but must request restart-service and apply-config-patch through the governance workflow. This prevents capability creep on an unattended system while still allowing the agent to acquire the tools it legitimately needs.

Full documentation: docs/tool-system.md

Manual gates

Manual gates are human approval checkpoints with configurable timeouts and safe defaults.

- name: approval-gate
  type: manual
  prompt: |
    Review the analysis in output/report.md before proceeding.
    Approve to continue, or reject to iterate.
  options: [approve, reject]
  timeout: 48h
  default: reject
  depends_on: [analyse]

The key design choice is default: reject. If no human responds within the timeout window, the gate closes rather than opens. On a system running in a regulated context, this means the workflow cannot advance past a sign-off checkpoint without an explicit human decision.

Gates are file-based and work fully offline. A pending gate is a file in .orbit/. Approval is writing to that file. No API call or network connection is required. Operators review pending gates with orbit pending and action them with orbit approve or orbit reject.

Self-healing

Rover’s self-healing behaviour is a composite of several mechanisms working together.

Deadlock detection tracks whether the agent is making meaningful progress by hashing the content of deliverable files before and after each orbit. If the hashes match across multiple orbits, the agent is not advancing. The configured action fires: abort stops cleanly with full state preserved; perspective injects a reframing prompt that encourages the agent to try a different approach, then resets the stall counter.

Waypoint recovery ensures that interrupted missions resume from the last checkpoint rather than starting over. Whether from a power outage, a process crash, or a full disk, when conditions normalise the mission continues from where it stopped.

Checkpoint continuity carries agent context forward between orbits within a component run. The agent does not start cold on retry; it inherits the working notes from the previous orbit via the {orbit.checkpoint} template variable.

Atomic writes throughout prevent partial state corruption from interruptions at any point in the write cycle.

Combined, these mechanisms allow a Rover-orchestrated system to run unattended for extended periods in degraded conditions and fail gracefully when it cannot self-correct, without silently corrupting state.

The learning system

The learning system is what separates a static workflow from one that improves. It operates through four layers, each persisted as JSONL in .orbit/learning/ and assembled hierarchically into agent context.

Feedback is a general-purpose improvement signal. After each orbit, an agent can emit <feedback> tags describing anything that would help it do better work. This might be a script it needed but did not have, a tool or MCP server that would have made a task tractable, a clearer prompt structure, a missing validation step, or a workflow change that would reduce repeated errors. The tag is not limited to prompt suggestions; it is the channel through which agents communicate what the system needs to work better.

Feedback accumulates across runs. Agents can reinforce existing entries with <vote> tags, and the top entries by vote count are assembled into agent context on future runs so the system is aware of its own known improvement backlog.

Critically, feedback can be acted on autonomously. An Orbit mission can be configured to run periodically or reactively against the accumulated feedback store, analyse the improvement signals, and implement the proposed changes, including writing scripts, building tools, updating prompts, and configuring new capabilities. The system uses itself to improve itself. A researcher component that repeatedly signals it needs a better source distillation script will, on the next improvement cycle, have one written and integrated by an agent that reads the feedback and acts on it.

Insights capture operational knowledge accumulated across executions. Insights are scoped observations at the project, mission, component, or run level. A system that has run 50 times on the same document corpus has accumulated observations about formatting patterns, common errors, and reliable strategies that are specific to that corpus. Those observations are on disk, travel with the system, and shape every future run.

Decisions record analytical choices with a managed lifecycle. Each decision moves through proposed, accepted, superseded, or rejected states. A decision made in run 10 holds in run 200 unless explicitly superseded. The system does not re-derive known conclusions on every execution.

Orchestration-level improvement is where the improvement mission pattern becomes most powerful. Accumulated feedback and decisions can describe not just domain knowledge but workflow problems, for example a mission structure that causes unnecessary orbits, a flight rule threshold that is too conservative, or a component that should be split into two. An improvement mission that reads this signal and edits the YAML configurations directly closes the loop at the orchestration level. The system, through an explicitly built mission, can restructure how it works.

Full documentation: docs/learning-system.md

Dashboard

Rover provides two dashboard modes. The terminal TUI (orbit dashboard) reads .orbit/ state directly and renders mission progress, component status, pending gates, and sensor activity. The web dashboard (orbit dashboard --web) provides a Cytoscape.js topology graph of the mission DAG served by a Python stdlib HTTP server with no external dependencies. Both run fully offline.

Why It Matters: Self-Evolving, Self-Healing Systems for Any Knowledge Work

The edge deployment problem

Cloud-dependent orchestration has a fundamental limitation for edge, regulated, and constrained environments. It assumes reliable connectivity, accepts that state may live remotely, and requires operational infrastructure that many deployment contexts cannot support.

A system monitoring industrial equipment in a remote facility cannot depend on a cloud state backend. A compliance workflow in an air-gapped government environment cannot send data to an external API. A data collection system on a field device cannot assume that a database connection will be available when a sensor fires. These are not edge cases; they are the normal operating conditions for a large class of deployments.

Rover was designed for these conditions. When there are zero external dependencies, every mechanism the system needs to be reliable must be local. Deadlock detection, waypoint recovery, atomic writes, and file-based gates are not convenience features. They are what a self-contained system requires.

What self-healing looks like in practice

Self-healing in a Rover system does not mean the system never fails. It means the system fails cleanly, attempts recovery, and preserves enough state that a human can understand exactly what happened and resume from a known position.

The orbit-fieldops studio demonstrates this pattern. An anomaly trigger file lands in a watched folder. The diagnostician component runs, analyses system health using restricted tool access, and produces a structured findings report. The remediator component reads the findings, applies fixes, and verifies outcomes. If the remediator stalls across multiple orbits without resolving the anomaly, the deadlock handler injects alternative framing. If a resource ceiling is approached, whether that is a monetary cost limit for cloud-hosted models or a time limit for a local inference deployment, the flight rule fires. If the system is interrupted mid-mission, the next run resumes from the last waypoint. Throughout, every write is atomic.

No cloud service is involved. No operations team is watching. The system handles the full incident response cycle, escalating to a human gate only when it needs approval for privileged actions.

What self-evolution looks like in practice

A Rover system deployed for three months in a specific environment is not the same system it was at deployment. The learning system has been running on every execution cycle, and the changes are specific to the actual environment rather than generic LLM performance improvements.

The researcher component in orbit-research, after months of processing papers in a particular corpus, has accumulated insights about which source types in that corpus are reliable, which formatting patterns appear in high-quality outputs, and which analytical approaches produce the most useful findings. Those observations were not pre-loaded; they emerged from real runs. They are on disk, they are auditable, and they are reversible.

This is the governed part of governed evolution. Every adaptation is traceable, including which run produced this insight, which orbit generated this decision, and what the agent said when it superseded a previous choice. The orbit insights and orbit decisions commands surface the full picture. Nothing changes silently.

Knowledge work beyond software

The ecosystem of AI agent tooling has been overwhelmingly focused on software development. This reflects where the early adopters were, not where the leverage is.

Consider the structural pattern of knowledge work in other domains. A research team repeatedly synthesises literature, produces summaries, identifies gaps, and updates its understanding as new material arrives. A compliance team repeatedly produces structured documents from evolving evidence bases, tracing every claim to a source. A financial analysis team repeatedly processes filings, applies analytical frameworks, and produces reports under time and cost constraints. An infrastructure operations team repeatedly diagnoses anomalies, applies fixes, and verifies outcomes.

All of these follow the same shape as a software development workflow, where input arrives, judgment is applied, structured output is produced, the output is evaluated, and the workflow advances or iterates. Rover’s primitives handle all of them. The YAML looks different. The prompts are domain-specific. The orbit loop, the sensors, the flight rules, and the learning system are identical across every domain.

The honest caveat is that Rover still requires YAML configuration and bash scripting to set up. The accessibility claim is about what the agents do, not about who can configure the system. A researcher who cannot write YAML still benefits from a Rover workflow that a colleague configured; they interact with it through the structured outputs it produces and the approval gates it presents.

Theoretical Underpinnings

Orbit Rover was designed from engineering first principles, but its architecture reflects three theoretical frameworks that converge on the same structural conclusions. Understanding them is not required to use Rover, but they explain why the design choices are what they are and predict how the system behaves as it scales.

Systemic design as a practice

Systemic design integrates systems thinking with design practice to address complex, multi-stakeholder problems. Where conventional design focuses on products or services in isolation, systemic design works with the whole system, attending to the relationships between levels, how constraints propagate, and how intervention at one level produces effects throughout the levels below.

A single Orbit component that analyses a document and produces a report is immediately useful. A mission that chains a few components together is more useful still. But the more interesting possibility opens up when you start thinking about the system as a whole, designing it to sense its environment, respond to events autonomously, govern its own behaviour, and accumulate knowledge over time.

This is where systemic design thinking becomes a powerful lens. Orbit’s configuration maps naturally to the four levels of systemic design: social, organisational, service, and product. Each level shapes what is possible at the level below, and understanding that relationship makes it much easier to see what to build and where.

flowchart TD
    subgraph social ["Social — Domain context"]
        S["Regulatory frameworks, data governance,<br>professional standards"]
    end

    subgraph org ["Organisational — Governance"]
        O1["Sensors"] ~~~ O2["Flight rules"] ~~~ O3["Tool governance"] ~~~ O4["Manual gates"] ~~~ O5["Learning system"]
    end

    subgraph service ["Service — Missions"]
        SV["Stage DAGs, dependency ordering,<br>waypoints, retry logic"]
    end

    subgraph product ["Product — Components"]
        P["Orbit loop, preflight scripts,<br>prompts, delivers"]
    end

    social --> org --> service --> product

    style social fill:#264653,color:#fff
    style org fill:#2a9d8f,color:#fff
    style service fill:#e9c46a,color:#000
    style product fill:#e76f51,color:#fff

Product design —> components. Each component produces a specific declared output through a focused orbit loop. Its prompt is its role definition, describing what kind of work it performs and what quality standard its output must meet.

Service design —> missions. A mission is the repeatable internal process that coordinates components to produce a valuable outcome reliably. The research mission in orbit-research is not a one-off document generator; it is a service that transforms a research brief into a structured body of findings, consistently and on demand.

Organisational design —> everything that governs how the system operates. This is where Orbit’s configuration becomes genuinely expressive. The reactive sensor system determines what the system attends to. The learning system is organisational memory. The tool governance layer controls what capabilities each component can access. Manual gates bring human judgment into the process at exactly the right points. Flight rules set the operational policy that holds regardless of what any individual component does. When this layer is designed thoughtfully, the result is a system that is coherent under pressure, recovers from failure, and accumulates capability over time.

Social design —> the domain context. The policy environment within which Orbit is deployed, including regulatory frameworks, data governance requirements, and professional standards, shapes what the entire system needs to look like. A clinical documentation workflow operating under health data regulations has specific traceability, audit trail, and approval requirements. Those requirements flow naturally through the organisational layer, into the service layer, and down to what each component produces. Mapping these constraints at the start is one of the most valuable things systemic design thinking offers.

When an environment changes, this hierarchy means changes can be located precisely and made at the right level. A tightened regulatory requirement flows into a flight rule adjustment. A service that is not producing the right output points to a mission structure change. A component that is underperforming points to a prompt refinement. The configuration is always the full picture of how the system works.

The learning system adds a further dimension. Component feedback surfaces capability gaps. Improvement missions can act on that feedback, building new tools, updating prompts, and refining configurations. Over time, the system could accumulate enough operational experience to restructure parts of itself without a developer rewriting it from scratch. That possibility is what distinguishes a living Orbit deployment from a static workflow.

Complex adaptive systems

Systemic design provides a practice for thinking about and building with Orbit. Complex adaptive systems (CAS) theory explains the dynamics of what emerges when that thinking is applied well, specifically how agents interacting with a governed environment produce adaptive behaviour over time.

A complex adaptive system is one where agents sense their environment, adapt their behaviour based on that sensing, and collectively produce emergent properties that no individual agent was designed to produce. Ecosystems, markets, immune systems, and cities are examples.

Orbit Rover is structured as exactly this.

The agents are the LLM components. They are the adaptive, sense-making elements. They interpret environmental signal and produce responses that no deterministic computation could produce. The environment changes in response to their actions (files are written, states advance), which changes the signal they receive on the next orbit.

The selection pressure is the set of promise flags, flight rules, success conditions, and tool governance policies. These determine which agent responses persist and advance the workflow. A response that satisfies the success condition propagates forward. A response that violates a flight rule does not.

The retention mechanism is the learning system. Insights, decisions, and feedback accumulate experience into the context that future agents operate in. What the system learns is compressed and carried forward.

The evolutionary triad, variation-selection-retention, runs continuously at all four timescales in a Rover system. Within a component orbit, the agent varies its approach across retries, the promise flag selects the response that satisfies the condition, and the checkpoint retains working context. Within a mission, stages vary in their outputs, waypoints select the progress that advances past checkpoints, and delivers retain the artifacts that downstream components depend on. Across missions, reactive cascades vary how the system responds to environmental events. Across runs, the learning system selects observations that persist as insights and decisions and retains them for future executions.

The emergent properties of self-healing and self-evolution are not features that were engineered in. They are what happens when the evolutionary mechanism runs long enough in a consistent environment.

The deterministic / adaptive boundary as design principle

Evolutionary theory distinguishes between the environment, which operates by fixed rules, and the agents, which adapt. Rover makes this distinction concrete at the architectural level.

The deterministic layer, comprising sensors, scripts, and validation, is the environment. It is stable, predictable, and cheap to run. The adaptive layer, the LLM agents, varies in its responses, and the environment selects among those responses via success conditions and flight rules.

This boundary matters for a practical reason beyond theoretical elegance. On constrained hardware, the LLM call is the expensive operation. Every task that can be handled by a bash script rather than an agent call is a task that costs microseconds rather than seconds. For cloud deployments, that difference is also monetary. For offline deployments running local models on constrained hardware, it is compute time, power draw, and thermal load, which are equally real constraints on a Raspberry Pi or an industrial controller. The preflight script that distils a complex project state into focused agent input is doing the same work as the environment in an evolutionary system: filtering the signal so the adaptive layer only processes what it is uniquely suited to handle.

The principle is domain-agnostic. The structure of a document can be checked by a script. The adequacy of its content requires an agent. The presence of a required field is deterministic. The quality of what is in it is adaptive.

Constitutional engineering

In evolutionary terms, the selection environment determines which adaptations survive. In Rover, that selection environment is the constitutional layer, comprising flight rules, tool governance, success conditions, and manual gates.

These function as what might be called constitutional provisions. A flight rule with on_violation: abort is not a preference or a recommendation. It is a structural constraint that the system cannot violate regardless of what the agent produces. Like a constitutional provision that binds all actors within a system, it applies whether or not anyone is watching.

The interesting property of this layer is that it can itself adapt within bounds. Decisions and feedback accumulate observations about where the selection environment is too loose, too tight, or structured incorrectly. An improvement mission can act on those signals and edit the YAML configurations directly, for example tightening flight rule thresholds, adjusting mission structure, or modifying success conditions. The constitution changes. But every change is made through the same explicit, auditable configuration that defined the system in the first place. The system can improve its own governance; it cannot do so silently.

This is what makes Rover safe to deploy in contexts where human oversight is intermittent. The agents adapt to their environment. The constitutional layer constrains what adaptations persist. The system can improve continuously; it cannot evolve outside its governance boundary.

Getting Started

Orbit Rover is open source under the Apache 2.0 license. The repository includes three example studios that demonstrate the main patterns.

orbit-research is a three-mission workflow (plan, research, write) with five components (research-planner, topic-decomposer, researcher, section-decomposer, section-writer) showing the two-tier decompose-execute pattern, orbits_to looping, and preflight source distillation. orbit-sentinel is a daily intelligence monitoring workflow showing cron sensors, iterative analysis, and a manual approval gate. orbit-fieldops is an infrastructure incident response studio showing restricted tool governance, flight rules, and file-sensor triggering.

git clone https://github.com/Modal-Vector/Orbit-Rover
cd Orbit-Rover
./orbit doctor
./orbit init my-project
cd my-project
./orbit launch my-mission

The config specs in the docs directory are designed for AI-assisted authoring. Paste a spec into Claude, Cursor, or Copilot, describe what you want, and get valid YAML back. They substantially reduce the learning curve for new projects.

Full documentation is available in the Orbit Rover repository, including the getting started guide, architecture overview, and detailed references for every system component.