Jordi Amat

Work

Orbis

The console I run my studio from. It answers one question, which agent needs me, so I can delegate work to coding agents instead of watching terminals.

Verified: checked against the repository or the live deployInferred: my reading of that evidenceIllustrative: simplified for this page

Context

Verified

I build with Claude Code every day, often with many sessions running in parallel across client and studio projects. Each one is a terminal. Answering “what is the state of everything?” meant opening all of them.

The design principle came out of that: delegate, don't monitor. Work should be requested and received as outcomes, not watched scrolling past. The terminals become plumbing.

Approach

Verified
The Orbis console: navigation on the left, a glowing orb in the centre reading one agent waiting on you, a noticing panel, and a live feed of agent sessions completing responses on the right.
The overview. A real screenshot; live figures are deliberately blurred.

One loop runs the whole thing: an intent goes in, an agent is summoned with the context it needs, it does the work, and an outcome comes back into the view. The orb in the middle is the summary of the whole fleet. Its colour is computed from aggregate state: calm when everything is nominal, amber when a session is blocked and needs me, red when three or more are blocked or infrastructure is critical.

Everything that is mocked today sits behind a single function, so it can be swapped for the real source without a rewrite: files for a database, polling for realtime, terminal parsing for structured events.

Architecture

Five layers, built from the bottom up. Building toward the layer, not just the checkbox.

Verified layers Inferred state of each
  1. 5

    Surface

    The orb and module pages, voice, web and phone.

    Built
  2. 4

    Brain

    Intent routing, the pulse that sums up state, memory, standing orders.

    Partly built
  3. 3

    Delegation

    Summon an agent with context, let it work, receive an outcome card.

    Built in a sandbox, then switched off
  4. 2

    Runtime

    Real Claude Code sessions in tmux. The hands.

    Built: live fleet and terminal control
  5. 1

    Data spine

    Files today, a self-hosted database with realtime later.

    Files

Every action goes through gates

A console that can end an agent's session can do damage. Pick a request to see where it is let through or stopped.

Verified stages Illustrative requests
Orbis, a request through the control route
Four stages left to right: authorise, rate limit, confirm gate for destructive actions, then act. Every denial is written to an audit log.Authorisesame-origin requestpassesRate limitper routepassesConfirm gatedestructive onlystops hereActtmux / agentsevery denial is written to the audit logneed-confirm

Clear a session

Refused by the server with needsConfirm. A browser confirm() dialog alone is not enough; the server has to see the confirmation.

The hole I found in my own tool

Verified

In September, during an audit of my studio systems, I found that the switch allowing Orbis to spawn new agents had been left on for two months. On its own that sounds fine: the console sits behind a reverse proxy that only lets my devices in, and the control routes check that requests come from the console's own page.

Neither held. The app process was reachable on the private network without going through the proxy, and a same-origin check trusts headers that any non-browser client can set. Put together, a device on that network could have started a real coding agent with its permission prompts skipped.

I switched spawning off the next day and confirmed it on the running app: the route now reports that it is disabled. Everything else in the console still works. Spawning stays off until agents run in a sandboxed, low-privilege runtime with real authentication in front of it.

Three things I took from it, now written into the project's decision log:

  • A same-origin check is a defence against cross-site requests. It is not authentication.
  • A feature flag is a switch, not a safety mechanism. If the dangerous path exists, assume it will be on.
  • Anything that can act on the world needs a real perimeter before it gets a button.

Result

Verified

In daily use for the fleet view, the agent feed, infrastructure and studio modules, from desktop and phone. Destructive controls are gated on the server and audited. The orb answers “which one needs me” at a glance.

Not done

  • A sandboxed agent runtime, and with it, spawning agents from the console again.
  • Moving state from files to a database with realtime updates.
  • Replacing the remaining mocked modules with their real sources.

What I would do differently

Inferred

Build the perimeter before the power. I built the ability to start agents early because it was the exciting part. It should have waited until the runtime it launches into was sandboxed.

Audit my own tools on a schedule, not by accident. The hole was found during an unrelated audit. The same review, run monthly against anything that can act on the world, would have found it in weeks rather than months.