Architecture
invisible-string is three services over Postgres and an object store, plus one optional search index.
Control plane
The API host (Bun + Elysia): authentication and organizations, agent and
workflow CRUD, connections and their health probes, the MCP OAuth broker,
compiler invocation with eve build and artifact upload, the scheduler,
trigger ingress, the pipeline runner — the interpreter that executes a
Workflow's steps against a durable per-step
ledger, calling MCP tools directly, making preset model calls, and
dispatching agent steps as child runs — outbound reply delivery, the SSE
tailer, and the copilot WebSocket loop. Its scheduler routes agent work by
session affinity first, then to an artifact-warm worker, then to any live
worker, with a dead-worker sweep and fencing.
Every outbound request the control plane makes on your behalf — probing an MCP server, discovering its authorization server, exchanging or refreshing tokens — goes through a guarded egress path that resolves and validates the address before dialing it.
Worker pool
A stateless Bun supervisor. It registers and heartbeats, pulls and extracts artifacts, boots each compiled agent under Node 24, reverse-proxies traffic to it, and reaps idle processes, idle sandboxes, and cold artifacts. Because workers hold no durable state, any of them can pick up a run.
Compiler
A pure function from an agent definition to an eve project. It is golden-digest-guarded and versioned, so any change to the emitted bytes is caught in CI and folded into the artifact content hash.
Search index
Community connector search runs against a Meilisearch mirror of the official MCP registry, refreshed on a timer. It is deliberately optional and entirely disposable: the registry remains the source of truth, an empty index rebuilds itself on the next sync, and if the index is absent or down, only community search degrades — the catalog and custom-URL lanes keep working, and installs are still verified against the live registry either way.
Life of a chat message
Your browser sends the message to the control plane, which resolves your session and, if this is a new run, asks the scheduler to place it — session affinity first (send it back to whatever worker is already running that session), then a worker that already has the Agent's artifact warm, then any live worker as a last resort. The chosen worker ensures the compiled agent process is running, booting it from a pulled-and-extracted artifact if it's cold, and the message is dispatched into eve's session API.
As the Agent works, its event stream is tailed by the control plane and
written durably, and your browser receives it live over resumable SSE —
reconnecting with a Last-Event-ID replays anything missed rather than
starting over. See Sessions & runs for
what that stream contains, and Durability for
what happens when the worker that was running it disappears mid-message.
Life of a publish
Publishing an Agent turns its definition — persona, resolved model and
reasoning effort, and context — into a compiled artifact. The compiler is a
pure function that takes that definition and emits an eve project; eve build
compiles the project into a runnable artifact; the artifact uploads to the
object store; and a row keyed by the definition's content hash records the
build.
A cache hit — an identical content hash — skips the compile-and-build step entirely and just confirms the existing artifact still exists. This is why republishing an Agent you haven't actually changed is instant: nothing was rebuilt, only reconfirmed.
Life of a workflow run
A trigger fires — a webhook lands, the schedule ticks, a Slack mention arrives — and the control plane starts a pipeline run: a run row plus a step ledger, before any step executes. The runner then interprets the published pipeline in order, writing each step instance to the ledger as it goes: tool steps call the connection's MCP server directly over the same guarded egress path the health probes use, infer steps call a workspace preset, and an agent step dispatches a child run through exactly the chat machinery above — scheduler, worker, eve session, tailer. Step events append into the same durable event stream, so the Runs tab's timeline streams and resumes exactly like a chat run does. No worker is involved except where an agent step needs one.
Where data lives
| Data | Lives in |
|---|---|
| Agents, Workflows, sessions, runs, step ledgers, workflow state, connections | Postgres (control-plane database) |
| Durable execution state for one agent version's runs | Postgres (that version's own world database) |
| Compiled artifacts, skill attachments | Object store |
| Mirror of the MCP registry, for community search | Search index (disposable) |
Deployment shape today
The shipped deployment is one control plane, one or more workers, and the supporting data services, all running as a single-host Docker Compose stack — see Deploy your own for the compose file and the environment variables it needs. See Durability for how the platform behaves when a worker in that stack goes away, and Security for how requests and credentials are handled along the way.