Roadmap

Foundation

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

• Web command center coordinates fleets of AI agents across projects.
• Per-project autonomy ladder: Manual → Queue → Beacon → Continuous → Mission.
• Two local execution paths: the production daemon and the newer event-sourced home/ stack (Brain + Bridge + Worker).
• Reliable handoff system between agent sessions, with truthful card status surfaces.
• Per-project pause / resume / direct-send semantics and a real autopilot intent ladder.
• Multi-user SaaS foundation — GitHub OAuth, organizations, team invites, agent tokens.
• Native Fleet Runner desktop app — loads the same React tree the web serves (one UI, two surfaces) plus tray icon, OS notifications on agent idle, and an embedded Zellij watcher for fire-and-walk-away dispatch.
• Multi-OS release pipeline. One tag push produces signed macOS, Windows, and Linux installers from a shared CI matrix.

The architecture is proven. The next phase is finishing distribution and auto-update so non-technical operators can install without touching a terminal.

Distribution and auto-update

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

• 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.
• Clean window.fleetRunner IPC bridge so the web React tree can detect 'I am running inside the desktop app' and surface desktop-only affordances coherently.
• Daemon install path stays supported for headless servers, CI runners, and operators who prefer a pure CLI flow.

Cursor, Claude Code, and Grok Build all converged on the same pattern — local client owns execution as a real application, not a service that polls a queue. Fleet Runner takes one extra step: the app and the web run the same React tree, so there is exactly one product surface to design and one codebase to keep at parity.

Remote control channel

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

• 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, over the open connection.
• Status flows back the same way, with low latency.
• 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

Steering a fleet from your phone should feel native, not like a phone-sized web page.

• Native iOS and Android apps on the same remote control channel.
• Optimized for steering and approval, not authoring.
• 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.

Cloud agents as a complementary mode

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

• 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.
• A complement to local execution, never the default for hosted users.
• Useful for builders running 8–12 agents at once who need extra parallelism or 24-hour availability.

Team and multi-machine surfaces

Same control plane, multiple operators, multiple machines.

• Shared fleet views across machines and across team members.
• Per-operator permissions. Per-project autonomy ceilings.
• 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.

One agent per user — the surface merge

Today's Ivy (FleetCrown) and Cat (OrangeCat) become one agent that sees the user's whole life. Two AIs is engineering convenience; one agent per user is the only interaction model that scales to nine billion builders.

• Memory layer unifies — the user's contacts, projects, goals, transactions, listings, and decisions live in one graph the agent reasons against.
• Reasoning loop unifies — when the user says "do X," the agent decomposes X across whatever surfaces are involved without the user choosing the surface.
• Autonomy ladder unifies — Manual → Queue → Beacon → Continuous → Mission applies across both products as one dial.
• Approval queue unifies — FleetCrown's Action Queue and OrangeCat's pending Cat actions become one inbox. The user lives in this queue.
• Surfaces (FleetCrown, OrangeCat) stay as engineering boundaries but stop being user-facing concepts. The user perceives "my agent."

See the Thoughts essay "From Two AIs to One" for the strategic argument. Convergence is engineering on top of two products that already work standalone, not a rewrite.

Stakeholder graph — the concrete first convergence

Every project has eight surrounding relationships — competitors, collaborators, investors, customers, employees, acquirers, acquisition targets, in-house dev projects. Track them as typed edges in OrangeCat's entity graph; surface them on FleetCrown; let the agent act on them.

• Storage in OrangeCat. The eight categories are edges between entities OrangeCat already has (projects, actors, groups, products, services, investments). One typed-edge schema covers all eight — no new entity tables.
• Operations in FleetCrown. /projects renders the eight stakeholder lanes per project, read from OrangeCat via the identity bridge. The Watch on /today surfaces signals derived from the graph.
• Ship competitors first — the most automatable category. Landing-page diffs, RSS, funding-event detection, hiring-page diffs. The other seven follow with the same primitives.
• Action loop: signal → Watch focus → "Brief Ivy on this" → agent drafts a response (pricing tweak, positioning post, feature pull-forward) → approve / disapprove.
• No second graph. FleetCrown does not duplicate OrangeCat's entity model. Two graphs are always wrong.

First concrete instance of the convergence — same data, two surfaces, one agent reasoning across both. See the Thoughts essay "Where Stakeholders Live" for the full design.

OrangeCat integration — the transaction half

Pair FleetCrown's production layer with OrangeCat's economic layer. The two halves of the individual singularity, settled to the same operator on the same terms.

• Identity bridge — FleetCrown users connect their OrangeCat actor through OAuth. One identity, two products, one settlement layer.
• Publish to OrangeCat — a project or agent output becomes a product or service listing with Lightning payments in one click.
• Agent costs as outflows — compute, API tokens, and third-party services route through the operator's OrangeCat Cat. The economy of the fleet becomes legible and auditable per project.
• Subscriptions as assets — FleetCrown's Money tab knows what the operator pays for; OrangeCat coordinates funding, lending, and shared-asset ownership so dragging subscriptions can be refinanced or sublet without leaving the platform.
• FleetCrown pricing on Lightning rails — FleetCrown's own revenue settles through OrangeCat. No Stripe in the path. Pseudonymous customers welcome.

The pieces exist in production today on both platforms (fleetcrown.orangecat.ch and orangecat.ch). FleetCrown is a customer of OrangeCat (via typed stakeholder 'customer' edge in the shared graph). See the live projects 'OrangeCat' and 'FleetCrown' on orangecat.ch under Mao Nakamoto. The integration is engineering, not invention. See the Thoughts essay "The Two Halves of the Individual Singularity" for the full strategic argument.

Physical robotic fleets

The same control patterns, applied to a different substrate.

• Per-fleet autonomy — the same dial: Manual → Queue → Beacon → Continuous → Mission.
• Handoff between human and robotic initiative.
• Queues, visibility, override — everything we shipped for software agents transfers.
• Robotics is a different execution surface bound to the same control plane.
• Not a separate product line bolted on later. The continuity is the point.

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.