Agents and Roles: Why the Engine Uses a Team of Specialists

In short

You can ask a single all-purpose agent to "build the feature and check it." The problem is that it checks itself — and it almost always approves its own work. It's like an author acting as their own editor: the obvious mistakes stay invisible, because they were written with confidence.

Quest, our vibe coding engine, takes another route: it splits the work into specialist roles, each with its own temperament, its own area of responsibility and its own system prompt. The core principle: one does the work — ANOTHER checks it.

Who's on the base engine's team (Quest)

The base engine assembles a team of 8 roles (all of them ship in every package; which ones "switch on" for a given task is decided by the target model reading the routing text — there's no separate runtime router yet, that's roadmap):

• Product owner — digs out the real intent and value, holds scope firmly (anything extra → backlog).
• Analyst — writes requirements in EARS form, covering the happy path, edge cases and errors.
• Architect — reads the existing code and dependency map BEFORE any edits, follows reuse-first, holds the invariants.
• Designer — the concept and every UI state, accessibility, distinctive typography (not the stock "purple gradient").
• Engineer — takes a step to green without breaking what's next door; TDD; verify after every step.
• Senior reviewer — concrete feedback in the form file:line — what's wrong — how to fix it.
• Security auditor — looks for ways to break it: injections, leaked secrets, holes in data isolation.
• Skeptical verifier — arrives AFTER the step with one job: prove the step broke something or is unfinished.

(Specialized roles for video, presentations and data live in the themed templates and modules that extend the engine — not in base Quest. Debugging, refactoring and release work is distributed across these eight roles — the engineer fixes and refactors, the reviewer and verifier check — rather than spawning a separate debugger or DevOps role.)

Why a team and not a single agent

Three reasons, all about reliability:

1. Division of labor beats self-deception. The skeptical verifier treats the engineer's work with suspicion by default and runs the checks itself — it has no interest in being liked.
2. Different angles of view. The security auditor asks "how do I break this," the designer asks "how does this feel to a person," the architect asks "what falls apart at scale." One agent physically can't hold all those lenses at equal strength at once.
3. Veto power for the critical angles. Five invariant angles (security, tenant isolation, the paid gate, regressions, data integrity) carry a veto: a critical finding from any of them is a BLOCK, even if every other vote says go.

How it works in practice: input → what the engine does → result

Input:

"Add a CSV export of the client list, with a button in the dashboard."

What the team does:

1. The product owner clarifies scope: only visible clients or all of them? Respecting the active filters? (recommends: with the current filters). Anything extra ("also Excel, and on a schedule") → backlog.
2. The analyst writes the EARS requirement: WHEN a user clicks "Export", THE SYSTEM SHALL return a CSV containing only the clients belonging to their organization + edge cases: an empty list, thousands of rows, special characters in a name.
3. The architect checks whether an export service already exists to reuse instead of writing a new one (reuse-first).
4. The engineer implements it, adding the organization filter to the query — otherwise someone else's clients get exported.
5. The security auditor catches exactly that class of bug: "does the query really filter by organization_id? does sorting from user input open an SQL injection?"
6. The skeptical verifier runs two independent "done" votes and launches the checks itself.

Result:

An export that returns only your own clients (not someone else's — the most expensive mistake in a multi-tenant product), behaves correctly on both an empty and an enormous list, and is proven so by verification.

Honestly

• All 8 roles ship in every package. "Smart routing — only the roles you need get activated" is done today by the target model reading text, not by a separate routing engine. A real router is roadmap.
• The full system texts of the roles arrive with the package. Before purchase you can see the team composition and each role's specialization; the full prompts open up after payment — and then the whole team sits in front of you in plain text: read it, tune it for your project.
• Roles are discipline in text, not magic. The value is that the team is already assembled, debugged and tuned for an Opus-class model on judgment-heavy tasks — weeks of work folded into a single install.