Getting StartedSolveBuildIntelligenceLearnHelpWhat's New
EDITOR

Advisor Agent

Rocket's built-in senior architect that diagnoses root causes, resolves error loops, and makes architectural decisions so the coding agent never gets stuck.

Every AI coding agent has a failure mode. It tries to fix a bug, fails, tries again, and starts recycling the same approaches. It gets stuck and it doesn't know it.

The Advisor Agent is a senior architect sub-agent built into Rocket's code generation pipeline. It runs on the most capable model available (Claude Opus), operates in read-only mode, and is invoked specifically in the moments where the coding agent's reasoning is not enough.


What the Advisor does

The Advisor never writes a line of code. It returns structured analysis: root causes, a recommendation, numbered implementation steps, and a trade-off table. Then the coding agent executes.

Error loop resolution

When the coding agent has failed to fix a bug after 2+ attempts, it escalates. The Advisor identifies the root cause rather than the symptom the coding agent was already chasing.

Architectural decisions

When multiple valid approaches exist with real trade-offs, the Advisor reads the project structure, weighs the options, and recommends the one that fits your codebase.

Large scale refactoring

Before sweeping changes, the Advisor maps what breaks. It identifies what needs to change, in what order, and what the risks are.

Code review

Before finalizing complex generated code, the Advisor checks it for correctness, edge cases, and failure modes.


How it helps you


How it helps the coding agent


Real example: Supabase auth fix

A user asked to make their app fully dynamic with Supabase auth. The coding agent created demo accounts by writing directly to auth.users and auth.identities via SQL migrations.

Login returned "Invalid login credentials". The agent tried two fixes. Both failed.

On the third attempt, the Advisor was invoked. It read both migration files in full and identified four root causes:

The auth.identities.id field must be a new UUID, not the user's UUID. The provider_id for the email provider must be the user's UUID, not their email address. Both migrations got both fields backwards. GoTrue v2.116.0 restructured the identities table in late 2023.

The ON CONFLICT clause targeted (provider, provider_id) but PostgreSQL's constraint matching is column order sensitive. The actual constraint is (provider_id, provider). The conflict clause silently failed to match.

Both migrations wrapped everything in EXCEPTION WHEN OTHERS THEN RAISE NOTICE. Every SQL error was swallowed silently and reported as a successful "skip".

The entire SQL approach was fragile. Supabase updates GoTrue independently. The correct approach is supabase.auth.admin.createUser() which routes through GoTrue's own logic and is always schema correct regardless of version.

The coding agent followed the steps. Login worked. Not another attempt at the same fix, but a fundamentally different diagnosis.


What's next?

On this page