---
title: "Orbit | Dylan Tullberg"
description: "An unreleased control plane for AI agents: one mission coordinating agent sessions, approvals, recovery, and delivery evidence across local, remote, and container runtimes."
url: "https://tull.ink/work/orbit"
---

[← All projects](https://tull.ink/work)

Aquablu R&D · Agent orchestration · 2026

# Orbit

Keep the mission intact when the agents change.

Orbit began as a way to automate planned work across development, user feedback, and campaigns involving multiple projects. Feedback had its own review paths, with automated checks and human decisions at different points in the flow.

My responsibility

I defined, designed, and built the program: the mission model, agent coordination, approval and recovery workflows, and the interfaces for people and agents.

**Unreleased R&D.** A working exploration, not a shipped customer platform.

## Many sessions. A shared objective.

The agent is replaceable. The mission holds the context, decisions, and evidence that make the next session useful.

Orbit

### Many agents. One mission.

Sessions can change. The objective, decisions, and evidence stay with the work.

Project rules Human approvals Recovery history

Inspired by Orbit’s login swarm.

## Designing for continuity and control.

### Sessions are disposable. The objective is not.

Keeping the mission separate from the session executing it is what made everything else possible: recovery, handoff, and an honest record.

### Autonomy belongs in configuration.

How much an agent may do alone should be a project decision that is compiled, versioned, and inspectable, not something buried in a prompt.

### Interruption is the normal case.

Connections drop, context runs out, and machines restart. Resume, restore, and replace have to be designed in from the start.

### Explore the architecture and integration boundaries

## One mission, wherever the work runs.

Requests arrive from a terminal, an API, an AI client over MCP, or a tracker. Orbit decides how the work enters the project, then launches agent sessions on a laptop, a remote host over SSH, a container, or a cluster. When a session is lost, the mission is not.

Requests arrive

-   CLI
-   API
-   MCP
-   Web
-   Trackers

Mission**Fix flaky CI checks**

Program

direct-bugfix · governed

Sessions

3 launched · 1 replaced

Decisions

1 approved

Evidence

PR · checks · notes

Durable state · Postgres

**Human gate**Approved in Slack

Sessions run wherever the work is

-   **Laptop · tmux**Claude CodeRunning Shaping complete
    
-   **Remote host · SSH**CodexRunning Connection lost
    
-   **Container · Docker**Claude CodeResumed with mission history
    
-   **Cluster · Kubernetes**Any supported agentAvailable
    

Program rules · Budgets · Approvals · Recovery history · Delivery evidence

Illustrative workflow with example data.

## Built to be swapped out.

Every external dependency sits behind a plugin slot, so the control plane does not care which agent, runtime, or tracker a project uses.

-   ### Agent
    
    Who does the work
    
    -   Claude Code
    -   Codex
    -   Gemini
    -   Cursor
    -   OpenCode
    -   Aider
    -   OpenHands
    -   SWE-agent
-   ### Runtime
    
    Where a session runs
    
    -   tmux
    -   Process
    -   SSH
    -   Docker
    -   Container
    -   Kubernetes
-   ### Tracker
    
    Where requests come from
    
    -   GitHub
    -   GitLab
    -   Linear
    -   Asana
-   ### Source control
    
    Pull requests and CI
    
    -   GitHub
    -   GitLab
-   ### Notifier
    
    How people are asked to decide
    
    -   Slack
    -   Desktop
    -   Webhook
-   ### Terminal
    
    How a person attaches to a session
    
    -   iTerm2
    -   Web

    $ orbit request submit site "Investigate flaky CI and propose the fix"
    $ orbit status --watch
    $ orbit session restore ses-142 # pick up where the lost session stopped
    $ orbit decision resolve dec-17 --message "Approved"

Example commands and identifiers.

1.  ### One source of truth, many surfaces.
    
    The CLI, API, MCP, and web interface all read and change the same state, so people and agents never work from different versions of events.
    
2.  ### Draw the boundaries early.
    
    Agents and harnesses change every few months. Explicit seams for agents, runtimes, trackers, and notifiers kept each change contained.
    

## What remains useful.

Company needs were still taking shape and priorities kept shifting, making stable workflows difficult to define. Orbit remained unreleased, but useful parts can be adapted to current agent harnesses.

The emphasis on CLI and MCP interfaces kept the design independent of any single agent. Review paths, quality checks, and human approval points remain useful foundations for coordinating work and improving it over time.

TypeScript · Node.js · Next.js · React · PostgreSQL · Rust sidecar · MCP integration protocol

[Explore more work](https://tull.ink/work)[Discuss a role or engagement](https://tull.ink/#contact)