For teams that are already equipped
“We already have Agent HQ, Kiro, Cursor.” Good news.
Those tools do what they do very well, and Survol does none of it. This page says exactly what it adds — and how you will know you do not need it.
They govern the agent. We govern the product.
An orchestrator knows which agent may touch which repository, with which budget, on which branch. None of them knows what your application does, in which version, for which goal, and whether it worked.
A one-minute answer per tool
What they do, what stays open
“We already have GitHub Agent HQ.”Multi-agent mission control, branch-level permissions, enterprise governance.
Agent HQ orchestrates agents over repositories : who runs what, where, with which permissions. It is excellent, and Survol does not redo it. What it does not carry: the notion of a feature, its life cycle through to production, the version a human wrote by hand, traced product decisions, and what a delivery cost measured against what it was meant to produce. Its centre of gravity is the repository — and a repository tells you how it was built, not what it is.
✅ You keep Agent HQ. Survol sits above it: it describes the product, Agent HQ executes.
“We do spec-driven development with Kiro / Spec Kit.”Requirements, design and tasks written before the code, versioned in the repository.
That is the right practice, and we are not trying to talk you out of it — the argument about starting from a spec is won, and not by us. The limit is elsewhere: those specs are files in a branch. They describe an intention at a point in time, one feature at a time, with no status, no functional version history, no voted decision, no cost, and nobody to re-read them three months later. Ask your team what the application does exactly today: the answer is not in those files.
✅ You keep your specs. Survol gives them a lifespan, a status and an owner.
“Cursor Organizations is enough for our budget.”Consolidated spend, per-team budgets, threshold alerts.
For steering spend, honestly, yes. These tools tell you how much was consumed, by whom, on which model, in which team. They cannot tell you to deliver what — because they do not know what a feature of your product is. The leadership question is not “how much did we spend”: it is “what did it produce, and where did we spend for nothing”. That is product governance, not FinOps.
✅ You keep your caps. Survol adds the denominator the number is missing.
“We have Jira, and we can already assign a ticket to an agent.”Agents in Jira, Rovo Dev, Linear + Cursor.
The bridge is real and it is moving fast. But a ticket describes work, not a product: it is born, it is closed, it disappears. It carries no functional version, no life cycle through to production, no attached cost, and it says nothing about what the feature became. Closing a ticket proves nothing; a version in production that kept its promise does.
✅ You keep Jira. Your teams will not switch, and we will not ask them to.
“What if GitHub or our agent's vendor ships the same thing?”The honest question — one we ask ourselves too.
They would ship it for their own ecosystem — and a company with two repositories and two agents cannot be governed by one of its vendors. More importantly: their economic interest is that you consume more. Ours is that you consume less, since we take no margin on AI. Those two products cannot be written by the same company. And if it happens anyway, it will at least confirm the problem was real.
✅ What stays yours: specs, goals, decisions, history. That asset survives a change of agent, model or vendor.
The split, line by line
What each one covers
A table convinces nobody — a demonstration does. This one is only here to check we are talking about the same thing.
| Capability | Orchestrators Agent HQ, Devin, Factory | Spec-driven IDEs Kiro, Spec Kit | Project tracking Jira, Linear | Survol |
|---|---|---|---|---|
| Orchestrating several agents | ✓ | partial | partial | ✓ |
| Structured spec before code | partial | ✓ | partial | ✓ |
| A living spec, outside the repository, versioned | ✗ | ✗ | partial | ✓ |
| Feature tree + product life cycle | ✗ | ✗ | ✗ | ✓ |
| Manual and agent versions, same cycle | ✗ | ✗ | ✗ | ✓ |
| Goals, promises and verdicts | ✗ | ✗ | ✗ | ✓ |
| Cost attached to a delivered feature | ✗ | ✗ | ✗ | ✓ |
| AI quotas and spend tracking | ✓ | ✓ | ✗ | ✓ |
| Environments and promotion gates | ✗ | ✗ | ✗ | ✓ |
| Usable by someone who never opens an editor | ✗ | ✗ | ✓ | ✓ |
| Independence from the vendor | ✗ | varies | partial | ✓ |
Honestly
Three cases where Survol will be no use to you
A vendor claiming to serve everyone serves no one. Here are the situations where we would tell you not to call us.
You build alone
With no team, the product map fits in your head and it is up to date. Survol solves a collective memory problem — you do not have one.
You deliver a project, not a product
A one-off delivery you will never revisit has no life cycle to govern. Your tracking tool is enough.
Nobody will ever read a verdict
If your leadership will never ask what the AI produced, half of Survol's value will never be consumed. Wait until the question comes up.
The only demonstration that counts
Open your repository and ask your team: “what does our product do today, in which version, and what did the last delivered feature return?” If the answer comes in thirty seconds, you do not need us.