PRODUCT DIRECTION

Roadmap

Building the operating system for people running serious AI agent operations — and for the robotic fleets that come next.

Shipping now

Live in production. The system already coordinates real fleets across real projects.

Fleet command center

The web control plane coordinates fleets of AI agents across projects, with one-button autopilot: pause all, or build all.

Details (4)
  • Agents drain each project's queue, then pick the next-best task.
  • Per-project pause / resume / direct-send semantics with per-project autopilot overrides.
  • Reliable handoff system between agent sessions, with truthful card status surfaces.
  • Multi-user SaaS foundation — GitHub OAuth, organizations, team invites, agent tokens.
Fleet Runner desktop app

One local execution path: the desktop app owns the agent terminals, agent launching, and state sync — the same React tree the web serves.

Details (3)
  • Tray icon, OS notifications on agent idle, and an embedded session watcher for fire-and-walk-away dispatch.
  • The legacy bash runner was retired by deletion — one path, not two.
  • Multi-OS release pipeline: one tag push produces signed installers from a shared CI matrix.

Next

Concrete engineering, in sequence: distribution first, then the remote control channel, then mobile on top of it.

Distribution and auto-update

Make Fleet Runner trivial to install and keep current on every platform — including for builders who never open a terminal.

Details (4)
  • Public macOS (.dmg, signed + notarized) and Windows (.exe) builds landing on every tagged release alongside the existing Linux AppImage / .deb.
  • Auto-update via electron-builder's GitHub provider so users never download a stale binary.
  • Native package channels where they exist — Homebrew tap for macOS, winget for Windows, .deb apt repo for Linux.
  • Headless CLI agent install path for servers, CI runners, and operators who prefer a pure terminal flow.
Remote control channel

Web and mobile become genuine remote control surfaces — not eventually-consistent dashboards.

Details (4)
  • The local app opens an authenticated outbound WebSocket to the control plane when remote control is enabled; commands flow surface → backend → that user's specific local app.
  • Falls back to the existing queue when the local app is offline.
  • Scoped credentials via the existing agent token system. Outbound-only connections — easy to firewall.
  • All execution of dangerous actions stays on the user's machine. The backend never sees raw file contents unless the user explicitly shares them.
Mobile fleet control

Native iOS and Android apps on the remote control channel — optimized for steering and approval, not authoring.

Details (3)
  • Push notifications for Beacon mode and Mission checkpoints.
  • Swipe actions for approving or rejecting agent outputs at the moments that actually need a human.
  • Voice capture for the autopilot intent ladder — direct the fleet while walking.

Research

Directions we are committed to that are design and strategy work today. Nothing here is presented as available.

Cloud agents as a complementary mode

When the local machine is unavailable, parallel cloud agents take over — with explicit handoff, never as the default.

Details (3)
  • Cloud agents for long-running, highly parallel work that does not fit on one laptop.
  • Explicit handoff between local and cloud sessions — the same agent identity continues across substrates.
  • Useful for builders running 8–12 agents at once who need extra parallelism or 24-hour availability.
The fleet learns from its own runs

The same evidence that decides whether a run was done should decide how the next one is briefed — with a human gate on every learned change.

Details (4)
  • Every dispatch is stored with the exact prompt that produced it and the graded outcome it earned — one joinable record instead of two disconnected logs.
  • Prompt improvements are proposed from real run history and reviewed by a human before they land.
  • Per-project lessons carry forward as references the agent may consult, never as rules it must obey; every learned change stays in version control.
  • The judge that grades a run is a different model lineage from the agent that did the work — an unsupervised self-grading harness learns to game its own scoring, so the human gate is the feature, not the friction.
Team and multi-machine surfaces

Same control plane, multiple operators, multiple machines — shared fleet views, per-operator permissions, per-project autonomy ceilings.

Details (2)
  • Coordination when several people steer the same fleet without stepping on each other.
  • Multi-machine orchestration for power users running across desktop, laptop, and remote box.
Connected products, owner-controlled sharing

Build independently in FleetCrown. Optionally link an OrangeCat profile for public updates and funding, with separate consent before publishing work.

Stakeholder graph

Track each project's surrounding relationships — competitors, collaborators, investors, customers — as typed edges in OrangeCat's entity graph, surfaced on FleetCrown for the agent to act on. Competitors ship first as the most automatable category.

Read the essay: Where Stakeholders Live
OrangeCat integration — the transaction half

Make it natural to fund what people build and build what people choose to fund, without pretending the full loop is already automated.

Details (5)
  • Optionally connect an OrangeCat identity through the existing OIDC bridge; FleetCrown also works without an OrangeCat account.
  • Typed links connect a FleetCrown project to any OrangeCat entity acting as its origin, public profile, funding page, offering, or community.
  • A signed, ten-minute OrangeCat handoff can prefill a FleetCrown project and Loki plan; the owner approves before anything is created or dispatched.
  • OrangeCat remains the share, promotion, and Bitcoin funding surface. FleetCrown shows its confirmed funding summary read-only.
  • Bitcoin is the first live settlement rail because confirmed transfers can be independently audited. Automatic work orders, escrow, fiat, and privacy coins stay research — none is presented as available today.
Physical robotic fleets

The same control patterns — autonomy dial, handoff, queues, visibility, override — applied to a different execution substrate. Not a separate product line bolted on later.

Details (2)
  • Per-fleet autonomy — the same dial: Manual → Queue → Beacon → Continuous → Mission.
  • The person who today directs a fleet of agents building software is developing the muscles that will let them direct a fleet of robots building physical things.
WHAT STAYS CONSTANT

Throughlines

These do not change as the phases ship. They are constraints we hold across every stage.

01
Local execution is privileged.

When the user's machine can do the work, it should. We do not push everyone into remote sandboxes.

02
Open and local models are first-class.

Frontier subscriptions are often the best tool. But the infrastructure does not require them — the user points their fleet at whatever model serves their goals best.

03
Autonomy is a user-controlled switch.

Pause all, or build all — with per-project overrides. Per project. Per moment. Never forced.

04
Outbound connections only.

The local client connects out to the control plane, not the other way around. Easier to firewall. Easier to reason about. Credible to security-conscious operators.

05
Nothing hidden.

Every agent's state is legible. No black boxes inside your own fleet.

This is the public-facing roadmap. Detailed engineering plans, deadlines, and sequencing live in internal documents and the architecture reference post.

Begin.

For builders running real agent operations.