El instinto cuando montas algo multi-agente es darle el modelo bueno a todo el mundo. "Si Opus razona mejor, que todos los pasos sean Opus." Hasta que ves la factura.
Pathtrip — un motor que toma un objetivo en lenguaje natural y genera un script Playwright reusable — está hecho desde la pregunta opuesta: ¿dónde es imprescindible Opus, y dónde no?
La respuesta nos llevó a la arquitectura que estamos defendiendo.
La forma básica
Cuatro piezas:
- Orquestador (Opus 4.7, una pasada) — recibe el goal, lo descompone en sub-objetivos, decide qué subagente lanzar, mantiene el budget.
- Explorer (Sonnet 4.6, en loop) — abre la página, vuelca el accessibility tree, cataloga selectores con rating de estabilidad. No actúa nunca.
- Coder (Sonnet 4.6, en loop) — escribe o actualiza el script Playwright usando el catálogo del Explorer y la rúbrica del proyecto.
- Verifier (Sonnet 4.6, independiente) — valida que el estado final cumple el goal. Sin compartir contexto con Coder, para que no se autojustifique.
El loop entre Explorer/Coder/Verifier corre hasta que el Verifier dice "sí" o el budget se agota.
Por qué Opus arriba y Sonnet abajo
Dos razones, una técnica y una económica.
Técnica: los modelos premium razonan mejor sobre planes: descomponer "quiero el CSV de ventas de esta semana" en cinco pasos viables, elegir un orden, anticipar qué pieza va a romper. Eso es un trabajo que se hace una vez.
Los modelos baratos ejecutan mejor sobre operaciones acotadas: "léeme este DOM y dime qué selector usar para el botón submit". Eso es un trabajo que se hace muchas veces, con poco contexto cada vez.
Económica: si los cuatro fueran Opus, el coste sería proporcional al número de iteraciones del loop. Cinco iteraciones × Opus = $$$. Con el split, el plan se paga una vez (Opus) y la ejecución se reintenta varias (Sonnet). El coste pasa de exponencial a lineal.
El truco del Verifier separado
El Verifier no comparte contexto con Coder. Esto suena a rigidez burocrática pero resuelve un problema real: si Coder ve sus propias acciones y luego se evalúa a sí mismo, encuentra siempre razones para decir "creo que sí funcionó". Es el mismo agente convenciéndose de que su escritura es buena.
Cuando el Verifier es un agente fresco con el goal original y el estado final como inputs, no tiene apego al script. Si el goal era "descarga el CSV" y no hay CSV descargado, dice no. Le da igual cuánto trabajo costó.
Lo que no es Pathtrip
Hay tres cosas que Pathtrip no hace, y que conviene aclarar porque me las preguntan mucho:
- No es un crawler general. El input es un goal, no una lista de URLs. Si quieres rastrear un sitio entero, hay herramientas mejores.
- No es un wrapper de Playwright. El output puede ser Playwright, pero si el Explorer detecta endpoints REST estables, el Coder emite un cliente HTTP en su lugar. Más estable, menos brittle, menos detección anti-bot.
- No hace Level 4. Captcha solving, account farming, bypass de paywalls. Eso ni siquiera está en el roadmap. La discusión interna fue corta: si Pathtrip aprende a hacer eso, deja de ser un motor de utilidad y se vuelve un problema legal para nosotros.
Lo que aprendí montando esto
Tres cosas que no esperaba:
El plan tiene que ser explícito y guardarse. Si el orquestador piensa "hago A, B, C" pero solo emite "haz A" al Explorer, en la iteración siguiente el contexto se pierde y se reinventa el plan. Resultado: dos planes paralelos divergiendo. La salida fue forzar al Opus a escribir el plan completo en disco y que los subagentes lo lean.
El catálogo de selectores aprende rápido y hay que controlarlo. Después de tres ejecuciones, el catálogo de un host puede tener 200 selectores con ratings de estabilidad. Sin compactación, el contexto del Explorer se hincha. Decisión: el Explorer ignora cualquier selector con rating < 0.4 después de N usos.
Budget explícito o muerte. Sin un contador duro de iteraciones (default 5), el loop se queda enganchado en hosts mal diseñados durante horas. El budget es lo que separa un motor útil de un sumidero de tokens.
Si tienes una idea similar — un agente que coordina otros — la primera pregunta no es "qué modelo uso". La primera pregunta es "dónde puedo gastar barato y dónde necesito el modelo bueno". Si la respuesta es "Opus para todo", probablemente no has descompuesto el problema lo suficiente.