vibeq

I needed a queue I could trust

On 5 March 2026 I needed a task board that Veniamin and I would actually use for Sirv Studio. Enough structure to stop work disappearing into chats and terminal windows. The first version had a pinned backlog and GitHub login.

Asking an agent to write code was already easy. Knowing what it did, who approved it and whether the result ever reached GitHub is what turned a board into a product.

The agent part arrived on day one. VibeQ could turn rough text into tasks, attach screenshots and videos through Cloudflare R2 and expose the queue through MCP so coding agents could read and update the same work as the humans. Within the first week it had the ordinary board furniture: search, due dates, checklists, dependencies. That was never going to be the hard part.

It was briefly called VibeQueue. I renamed the interface to VibeQ before discovering that renaming deployed Workers, databases and secrets for aesthetic consistency is a fine way to break a working system. The repository is still called vibequeue. The product is VibeQ. Both are correct.

Why not Linear

Linear is a good product. So is Height. Jira exists. The honest answer has three parts, and none of them is “I can build a better board”.

I did not want to pay per seat. We are two humans about to be outnumbered by agents, and seat pricing punishes exactly that experiment. Every agent identity on the roster would be another subscription line for the privilege of running my own workers.

I wanted the freedom to customize everything. A promised-branch card, a QA staleness monitor, an MCP surface for coding agents and a Slack-facing runtime in the same repository are not feature requests any vendor would take seriously. Here they are a normal week of work, wired exactly the way we operate.

And I wanted to own the data. Every task, event, session, approval and artifact sits in my own D1 database and R2 bucket. The ledger is the whole point of the system. Renting it from someone else’s API, behind someone else’s rate limits and export rules, puts the most valuable byproduct of the work in the one place I cannot fully reach.

The board grew eyes

A normal task board tells you what somebody wrote on a card. I needed it to tell me what was actually happening.

By April, the home screen had Who’s working on what, a Needs attention radar, domain views and a triage queue. Tasks could show that work had gone quiet, that a review had stalled, that a blocker chain had formed. The one that earns its place on the home screen is the promised branch: a task moves to done, the summary says the fix is in and no pull request ever appears. On a normal board that gap stays invisible until somebody goes looking for the diff. Here it becomes a card with a name on it.

The Activity view became a chronological record of people and agents creating, moving, discussing and shipping work.

Then the QA Monitor moved into the same interface, with Veniamin behind the QA side too. Instead of a green badge that says “tests passed”, it tracks how old the proof is and which product areas have none. It exists to make weak proof visible before it gets mistaken for confidence.

That changed the unit of work. A task stopped being a title, status and assignee. It started carrying the branch, the pull request and whatever a reviewer would need to argue with the result.

I do not need a prettier Jira. I need to know what changed while I was looking somewhere else.

Today reduces the queue to one next move, then shows the work that is stuck, failing or still missing a receipt.

Then the agents moved in

VibeQ treats agents as workers, not integrations hanging off the side of the real system.

The MCP server lets Codex, Claude and other agent runtimes search the queue, create tasks, claim work, record progress, attach artifacts and close the loop. A human and an agent see the same task ID, same blockers, same unpushed branch. Agents appear in the activity roster beside us, because an agent’s work in a separate console is work nobody reviews.

That paid off once I started running the improve-codex workflow: audit a mature codebase, scrutinize the plans, execute them in isolated worktrees, attack the diffs and land only the work that survives. The execution muscle is the Clanker Army, the batch runner that lives inside the Sirv Studio repository. It compiles vetted plans into batches, polls VibeQ for orders and runs several isolated worktrees at once. VibeQ holds the queue around that machinery. It remembers which plans exist, who is doing what, which branches are real and what still needs a human decision.

The important boundary is that an agent seeing a task does not grant it authority. Creating, claiming, changing or closing work must follow the user’s instruction and the task’s approval state. VibeQ is the record of that authority, not an excuse to infer it.

The Activity ledger puts people and Sirvant in the same roster, then records the task, comment, branch and commit events underneath. Designed by Veniamin Krachun.

Sirvant is the front door

In June, VibeQ changed category. Sirvant, the agent runtime with a public Slack identity, landed in the same repository.

Sirvant is not a slash-command bot or a chat skin over the task API. It is a durable, open-ended work partner in the Sirv Slack workspace. Someone can ask a product question, send a voice note, continue an old thread, point at a bug, request a report or ask for a scoped fix. Sirvant is expected to understand the request, inspect the available systems and either answer or act.

That includes more than repository work. The profile can use VibeQ itself, authenticated Basecamp access, Sentry, the internal Outline knowledge base and Sirv Marketing Machine data when those tools are available. It can triage the queue, reproduce an issue in a browser, inspect a codebase, prepare a report, schedule real automation or open a pull request. A voice message is transcribed and treated as the instruction. A thread reply continues the existing conversation instead of starting an amnesiac new chat.

The useful distinction is between thinking and hands. Sirvant does not start a worker for every message. Hermes or OMP owns a short-lived thinking session, loads the relevant history and decides whether the request can be answered directly. Only work that needs a repository, browser, tests, files or command-line tools gets a disposable execution cell.

Slack is the cockpit. VibeQ is the logbook and source of truth. Every meaningful request, decision, tool result, approval, failure, artifact and closeout should be recoverable there. A Slack retry, supervisor restart or vanished work cell should not erase the history or make a second job look like the first one.

Sirvant also has a real authority boundary. Read-only inspection is cheap. A requested implementation can produce a pushed branch and pull request. Direct pushes to shared branches, merges, deploys, production writes and destructive actions still need explicit approval. The point is not to remove humans from the loop. It is to make the loop visible and precise.

One system, three ways in

Interactive Slack work, scheduled automation and batch jobs all enter the same underlying system. The mode changes how work starts and where the result returns. It does not create a separate bot, memory or approval model.

Cloudflare receives signed ingress and guards the Slack and API secrets. VibeQ records session and task state in D1 and keeps larger artifacts in R2. A profile-matched Hermes or OMP supervisor claims the durable work item and starts the thinking session. If hands are needed, the normal path is a short-lived Cloudflare work cell with only the identity and permissions required for that job. A Hetzner Docker worker remains as a pinned fallback and cleanup lane. The risky environment can disappear when the work ends while VibeQ keeps the durable record.

That split matters more than the choice of model. One agent can plan while another executes. The ledger records both identities, because “Claude planned it and Codex typed it” is useful information when billing, permissions or a failure needs to be traced later.

Profiles give that substrate a job without forking the whole architecture. Sirvant uses the open-ended vibeq-codex profile. Documentation sweeps and pull-request reviews have narrower profiles, tools and approval rules. A GitHub webhook can go straight to a disposable clone-and-review job. A scheduled docs sweep can use the same ledger and still return through Slack.

The pull-request path can run a bounded review-to-fix loop. It stops on a clean review, refuses a moved or unsafe branch, never force-pushes and has a three-round limit. Autonomy is useful when the exit conditions are part of the design.

Memory follows the same rule as the work itself: useful recollection must have provenance. Search can point back to the session, event or artifact that supports an answer. Reusable lessons can be promoted and deduplicated, while task state stays in VibeQ instead of dissolving into a model’s private memory.

Sirvant's control room: supervisor and runner health above, the durable Hermes-to-Cloudflare execution path below and warnings where scheduled work can strand.

A local commit is not delivery

Most of the difficult VibeQ work begins where an agent demo normally ends.

An agent finishes a fix inside a disposable Cloudflare work cell. Tests pass. It writes a clean local commit, reports success, and the summary reads beautifully. Ten seconds later the work cell is destroyed on schedule and the commit goes with it. Nothing errored, so nothing alerted. The task says done and the branch does not exist.

So implementation counts only when the commit exists on the remote as a pushed branch and pull request, or when an explicitly requested landing reaches the named shared branch. A worker that prints plausible handoff JSON without a real job behind it does not count either. Everything short of that is a story about code. VibeQ is deliberately rude about the difference, because a polished summary cannot rescue work that vanished with its container.

The other lessons arrived the same way. A token expires halfway through a two-hour run. A Cloudflare deploy restarts the coordinator while the container is still working. GitHub delivers the same webhook twice. One poisoned Slack event blocks everything queued behind it.

A job cannot be claimed only because a worker can see it. Approval, live parent session, provider, profile, lease and current run state must agree in one guarded transition. Long Cloudflare runs have three ways to return a result so a coordinator restart does not automatically eat the answer. Webhook retries adopt the existing work instead of creating a second review. Dead sessions and stuck ingress lanes have explicit reapers and alerts.

This is the part of VibeQ I find most valuable. It does not ask me to trust that an agent probably did the work. It keeps making the agent, runtime and delivery path produce receipts.

What exists now

The repository snapshot on 9 August 2026 looked like this:

Those count surface area, which is the least interesting thing a repository can tell you. The board’s own ledger is better evidence: since 5 March it has taken in 6,228 tasks and closed 4,936 of them, from humans and agents working the same queue. The more useful inventory is what the system keeps together:

• a board, Today view, Activity ledger, cycles, triage and QA Monitor
• task, branch, pull request, commit, dependency and artifact state
• MCP, API, Slack, GitHub and scheduled ingress
• replayable sessions, approvals, memory, search and evidence
• profile-aware supervisors and disposable execution cells
• browser push for the moments when a human is genuinely needed

VibeQ is private and tailored to the way we build Sirv Studio. It is also far more infrastructure than a normal two-person task board needs. Cloudflare Workers, D1, R2, Durable Objects, Containers and external supervisors are justified by the agent runtime, not by draggable cards.

I would rather keep it specialized and honest than sand it into a generic SaaS product.

What I learned

The board was the first interface. The ledger became the product.

When implementation gets cheap, coordination does not disappear. It becomes more important. Someone still has to preserve intent, choose the next problem and decide whether a technically valid result makes any product sense. That last one is not a small residue of the job. It is most of it.

VibeQ externalizes the parts my brain should not be trying to retain across a dozen parallel sessions. The task says what should happen. The event trail shows what did happen. The artifact carries the proof. The human still decides what matters.

Which is the theory of the programmer applied to plumbing. An agent fleet is not a pile of models. It is a work system that lets one person’s judgement operate at a scale they cannot hold in their head, without quietly giving up control of it.

“Can the model make this change?” is no longer the interesting question. The interesting one is what will know that it did, challenge it when it lies and put the result where another person can inspect it.