Why I built it
Chat is a bad fit for work that takes a while.
Every AI tool ships the same interface. You type, it types back, and the file or the query or the running job lives somewhere else entirely. Most of your effort goes into moving context between the thing that reasons and the thing that does — you end up working as a courier.
That's fine for questions. It breaks down when the agent is doing something that takes ten minutes, touches nine files, and needs you to redirect it partway through. By the time you read the summary, the work is already done and you're reviewing a decision instead of shaping it.
How it works
Rooms, activities, and traces.
Three ideas replace the message timeline. Everything else in the product follows from them.
Where a piece of work lives
A room holds members, state, and history — humans and agents together. You don't post into it and wait. You go there because that's where the thing you're working on is.
The interface follows the task
A room is always doing one specific thing: editing a document, running a query, tailing logs, executing a tool. The composer, the panels, and the controls all change to match whatever that is.
History that stays readable
When an activity finishes it collapses into a single line of scrollback that you can reopen, link to, and search. Ninety seconds of tailing logs becomes one row instead of four screens.
Where it stands
It's a real system and I use it daily.
Vectrium runs on my own infrastructure and it's the surface I built Vectrium in. Everything below is counted from the repository, not estimated.
- 99k
- lines of Rust, Svelte, and JavaScript
- 636
- commits since the first push in May 2026
- 3
- AI agents that use it as their main surface
- 0
- third-party services in the data path
Counted 2026-08-06 across tracked source files, excluding dependencies and the performance harness.
Architecture
Conservative where it matters.
Realtime collaboration punishes you for guessing, so the pieces that touch shared state are the strict ones: a Rust backend whose SQL is checked against the live schema at compile time, one database, and no distributed state to reconcile.
Backend
Rust, axum, Postgres
One service, one database. Queries are checked against the real schema when the code compiles, so a wrong column name fails the build instead of a request at 2am.
Frontend
SvelteKit 5, built for phones first
One room shell that survives navigation, swapping editors as the activity changes — Tiptap for prose, CodeMirror for code and SQL.
Realtime
One WebSocket, typed events
Presence, activity changes, and streaming agent output share a single channel. Event shapes are defined in Rust and generated for the client.
Agents
Members, not bots
Agents connect through a bridge and drive activities directly, under the same membership and permission checks as a person.
Deploy
Push to main, verified rollout
GitLab CI builds and deploys on every push. A release only counts as good once the container answers a health check that takes a real write lock.
Agents
The agent is a member of the room.
It joins over the same connection a person does, with the same permissions, and it works on the surface you're both looking at.
- It sees what you see
- Open a SQL file and the agent has the file, the schema, and the last few queries run against those tables. You never paste context in.
- It edits in place
- Changes land in the document already on your screen. Query results appear in the result pane. Nothing gets handed back as a block of text to copy.
- You can stop it
- A running tool is live state in the room, so you watch it happen and redirect while it still matters — rather than reading about it afterward.
- It remembers
- Long sessions get condensed as they go, so an agent can pick up a thread from three weeks ago without re-reading everything that happened since.