In less than a year we went from ten or more open terminals per engineer to a system that coordinates, checks, and reviews agent work. Our team defines the product direction and approves what gets shipped.

Lost between sessions

In December 2025 our engineers were trying to speed up how we build products. Each of them kept ten or more terminals open and followed a separate session in each one. Switching between windows or picking the work up the next day meant figuring out what had finished, what was stuck, and what was waiting.

We built a CLI first

The first version of Qell was a CLI that engineers ran locally. They could define the specification and implementation plan with an agent, then run the resulting tasks automatically.

Instead of juggling too many terminal sessions, the engineer had one list in the terminal interface: what was done, what was in progress, and what was waiting for their review.

RageCLI, the first version of Qell, in the terminal
The first version of Qell, then called RageCLI. One feature split into tasks, with a coordinator starting each one and tracking what's done, in progress, and waiting.

When the laptop closed

The work outgrew local execution. We moved Qell to our own dedicated server, so it could keep running independently of an engineer's laptop.

We brought the tracking we had been doing in Jira into the same system: features, which Qell calls entries, and the tasks that make them up. As Qell evolved, it outgrew the terminal too, so we moved it to a web app and added an MCP interface for agents to access the same project context and tools.

Planning starts with real context

We used to start with a specification in Confluence, split it into tickets in Jira, and hand it to engineering. Now planning starts in Qell with the code, earlier decisions, the roadmap, and notes from past discussions already in context.

The product manager brings the intent and product direction. The engineer brings the technical constraints and the parts of the system the work may affect. Together, they can ask the agent to explore the product, build a prototype, challenge an approach, or surface a missed constraint before agreeing the plan.

Faster work that stays easy to follow

How Qell takes a feature from the agreed plan to approval Entry The agreed plan Task Its own context and scope Automated checks and agent review loop Task Its own context and scope Automated checks and agent review loop Task Its own context and scope Automated checks and agent review loop Entry In Review Automated checks and agent review, as a whole loop Engineer review Our team approves the result loop Approved

Qell helps us coordinate multiple agents working on the same feature without losing track of dependencies, context, or progress. We built an algorithm that turns the plan into a dependency graph and determines which tasks can run in parallel and which need to wait.

Each agent gets a clear task, the context it needs, and a defined scope. The team can see what is done, what is in progress, and what is waiting without following individual agent sessions.

Review stays a full step

Agents can produce work faster than an engineer can properly review it, but speed does not remove the need for review.

Each task goes through automated checks and a separate agent review. That creates a feedback loop where problems are caught, sent back, and checked again.

Qell also acts as a quality guardrail across the whole entry. When all tasks are done, it reviews the result against the original plan and acceptance criteria. Anything that doesn't match what was intended goes back for another round.

Once all automated checks and reviews are complete, our team reviews the entry, checks the code, and gives the final approval.

Qell delivery view
An entry on the delivery view. All its tasks are done and the delivery is completed.

What this changes for our partners

Partners keep working with us the way they always have. They bring us ideas, problems, features, and priorities, and we work through them together before turning them into product decisions and working features.

What changes is what they get. Features arrive faster, more complete, and with fewer issues. We also hit our delivery estimates more often.