TL;DR: El enrutamiento consiste en decidir qué agente de código se encarga de una tarea determinada. Enruta según las propiedades de la tarea, no según la clasificación de la semana pasada: qué modifica, cuán reversible es, si se solapa con archivos que otro agente está tocando, cuánto tiempo se ejecuta sin supervisión y qué suscripción lo cubre. Haz coincidir esas propiedades con el agente cuyo comportamiento en tu base de código encaje. Eso funciona de memoria con uno o dos agentes. A partir de tres, la decisión de enrutamiento necesita un lugar compartido donde vivir. Esta guía te da las reglas y una lista de verificación.
Tienes Claude Code en un terminal, Codex en otro, quizá Gemini CLI en un tercero. Llega una tarea: arreglar una prueba inestable, añadir un endpoint, refactorizar un módulo que otros tres archivos importan. ¿Qué agente la recibe? La mayoría respondemos por costumbre, o por la ventana que ya tiene el foco. Eso funciona hasta que no recuerdas a qué agente le entregaste la migración, o hasta que dos de ellos editan el mismo archivo.
Elegir al «mejor» agente es una decisión única que envejece el día en que se lanza un modelo nuevo. Decidir qué agente recibe esta tarea es una decisión que tomas decenas de veces por semana, y depende mucho más de la tarea que de la clasificación. En cuanto tienes más de un agente, el enrutamiento es donde se va tu tiempo.
Sharkly está construido en torno a esa decisión. Sharkly es una plataforma todo en uno de gestión y comando de agentes: conectas tu propio ordenador, defines un agente una sola vez como un rol vinculado a un entorno de ejecución y le asignas una tarea. Se sitúa por encima de los agentes de código que ya usas, no al lado de ellos. Este artículo explica cómo enrutar bien una tarea, primero como reglas que aplicas a mano, y luego hasta el punto en que la decisión de enrutamiento necesita un lugar compartido donde vivir.
El enrutamiento es una decisión, no una preferencia
Empecemos con una definición clara. Enrutar es emparejar una tarea con el agente que debería ejecutarla. No es lo mismo que elegir tu agente favorito, ni que elegir un modelo. Qué modelo para qué tarea de código es una cuestión aparte y más acotada que se sitúa una capa por debajo; aquí decidimos qué agente (Claude Code, Codex, Gemini CLI, OpenCode y el resto) recibe el trabajo.
Una tarea lleva propiedades que determinan su ruta antes de que la capacidad entre en escena:
- Qué modifica. Un arreglo de un solo archivo, una refactorización transversal, una funcionalidad desde cero, pruebas, documentación. Cada uno tiene un radio de impacto distinto.
- Cuán reversible es. Corregir una errata y migrar una base de datos producen ambos un diff. Solo uno te arruina la tarde si el agente se equivoca.
- Solapamiento de archivos. ¿Toca archivos que otro agente está editando ahora mismo?
- Horizonte de autonomía. Una edición rápida e interactiva, o una ejecución larga sin supervisión que tiene que planificar, ejecutar y autoverificarse.
- Techo de coste. Qué suscripción o presupuesto de API debería absorberla.
Lee una tarea a través de esas cinco propiedades y la ruta suele elegirse sola. El error es saltar directamente a «qué agente es el mejor», una pregunta que no tiene respuesta fija y que cambia cada vez que un laboratorio lanza algo.
Enruta por la forma de la tarea, antes de enrutar por capacidad
Los agentes de código difieren de verdad. Uno puede planificar bien tareas largas de varios pasos; otro puede ser más preciso en ediciones quirúrgicas o más rápido en bucles cortos. Pero la versión honesta es esta: difieren en tu base de código, y la única forma de saberlo es verlos trabajar en ella. Los benchmarks miden un conjunto fijo de problemas en un momento fijo, que no es ni tu repositorio ni el mes que viene. Compara agentes en tu propia base de código antes de fiarte de una clasificación.
Así que enruta primero por la forma. Un par de decisiones para anclarlo: usa un agente rápido e interactivo cuando la tarea es pequeña, está bien delimitada y vas a estar mirando; recurre al agente más autónomo cuando la tarea es lo bastante grande como para que prefieras describirla una vez y revisar el resultado en lugar de vigilar cada paso.
| Forma de la tarea | Enrutar a | Por qué |
|---|---|---|
| Pequeña, bien delimitada, estás mirando | Tu agente interactivo más rápido | Poca sobrecarga, bucle ajustado |
| Grande, de varios pasos, describir una vez | Tu agente autónomo más fiable | Planifica y se autoverifica sin supervisión |
| Toca archivos que otro agente tiene abiertos | Cualquier agente, en un worktree aislado | Evita la colisión de fusión |
| Alto riesgo o irreversible | El agente cuya salida revisas de cerca, con permisos estrictos | Domina el radio de impacto, no la velocidad |
| Barata y repetitiva | La que prefiera tu presupuesto | El techo de coste decide |
Nada de eso nombra a un ganador, porque no lo hay. Existe un encaje entre una tarea y el comportamiento observado de un agente, y ese encaje es lo que usas para enrutar.
Las restricciones que deciden el enrutamiento antes que la capacidad
Dos restricciones anulan la capacidad siempre, y ambas tienen que ver con la coordinación, no con la habilidad.
La primera es el solapamiento de archivos. Cinco agentes editando un mismo repositorio suena eficiente hasta que dos tocan los mismos archivos y estás resolviendo un conflicto de fusión que creaste a propósito. La solución es el aislamiento: dale a cada tarea su propio checkout para que los agentes no puedan chocar. Worktrees de agentes de código, un checkout por tarea cubre el mecanismo, y ejecutar varios agentes en un mismo repositorio cubre qué se rompe sin él. Cuando dos tareas tocarían los mismos archivos, la ruta no es «el mejor agente», sino «el agente que sea, en un worktree aparte».
La segunda es el riesgo. Una tarea que migra datos, cambia la autenticación o reescribe una ruta crítica debería enrutarse allí donde tu revisión sea más estrecha y los permisos del agente más limitados, sin importar qué agente sea técnicamente más fuerte. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. Enrutar una tarea arriesgada al agente más rápido optimiza la variable equivocada.
Dónde el enrutamiento mental deja de escalar
Con un agente, no hay problema de enrutamiento. Con dos, mantienes la tabla en la cabeza y va bien. El problema empieza hacia los tres agentes y varias tareas abiertas: la decisión de enrutamiento no tiene dónde vivir salvo en tu memoria a corto plazo.
No recuerdas qué agente recibió la migración. Una ejecución terminada se pierde por la parte superior del terminal antes de que la leas. Vuelves a decidir la misma ruta tres veces porque no hay constancia de que la decidiste una vez. Dos agentes editan el mismo archivo porque nada le dijo a ninguno que el otro estaba ahí. Nada de esto son fallos de los agentes. Es el coste de llevar una tabla de enrutamiento en la cabeza mientras los terminales se multiplican. Demasiados terminales es un coste real, y el enrutamiento es donde se nota primero.
Aquí es donde un tablero de tareas se gana su sitio, porque saca la decisión de enrutamiento de tu cabeza y la lleva a un registro compartido. Sharkly lo hace con tres sustantivos. Una Task (tarea) es la unidad de trabajo compartida. Un Agent (agente) es un rol vinculado a un entorno de ejecución, definido una sola vez para que la decisión de enrutamiento se vuelva reutilizable en lugar de rehacerse en cada terminal. Asignas una Task a un Agent, y la ejecución, los bloqueos y los resultados vuelven a esa Task en lugar de perderse de vista. Ves qué agente está en qué sin cambiar de ventana, y el diff y la salida de las pruebas esperan tu revisión en un solo lugar. Asignar, hacer seguimiento y revisar el trabajo de los agentes es lo que sustituye a este juego de memoria.
No necesitas nada de esto para usar bien un solo agente. También puedes ejecutar Claude Code y Codex juntos en una misma base de código a mano, y para dos agentes eso es razonable. La ecuación cambia cuando las decisiones de enrutamiento superan lo que puedes retener en la cabeza: varios agentes, varias tareas, varios repositorios, un equipo que necesita ver el mismo tablero.
Una lista de verificación de enrutamiento que puedes aplicar hoy
Antes de entregarle una tarea a un agente, pásala por estos puntos:
- Nombra la forma de la tarea. ¿Arreglo de un archivo, refactorización, algo desde cero, pruebas o documentación? Esto fija el radio de impacto.
- Comprueba la reversibilidad. ¿Difícil de deshacer? Enrútala a tu revisión más estrecha y tus permisos más limitados, no a tu agente más rápido.
- Comprueba el solapamiento de archivos. ¿Hay otro agente ya en estos archivos? Si es así, aísla esta tarea en su propio worktree primero.
- Ajusta el horizonte de autonomía. ¿Corta y vigilada, o larga y sin supervisión? Enrútala al agente cuyo comportamiento encaje en tu repositorio.
- Fija el techo de coste. Decide qué suscripción o presupuesto absorbe la ejecución.
- Registra la ruta en algún lugar compartido. A partir de dos agentes, escríbela donde tú y tu equipo podáis verla: una Task, no un terminal que vas a cerrar.
- Devuelve los resultados a un solo lugar. El diff, la salida de las pruebas y la revisión deben volver al registro de la tarea, no dispersarse entre ventanas.
Enruta según la tarea, no según la clasificación. El mejor agente para una tarea es el que encaja con el trabajo que tienes delante, y la decisión de enrutamiento solo se mantiene barata si vive en algún lugar donde puedas verla.
Si ya ejecutas varios agentes de código, Sharkly te da un único lugar para enrutar sus tareas y leer sus resultados. Puedes descargar Sharkly y conectar los agentes que usas.
Preguntas frecuentes
¿Es lo mismo enrutar que elegir el mejor agente de código? No. Elegir el mejor agente es un juicio único que envejece rápido. Enrutar es decidir qué agente se encarga de cada tarea, según su forma, su riesgo, el solapamiento de archivos y el horizonte de autonomía. Enrutas decenas de veces por cada vez que eliges.
¿En qué se diferencia de elegir un modelo? Elegir un modelo ocurre una capa por debajo, dentro del agente. El enrutamiento decide qué agente recibe la tarea; la cuestión del modelo decide qué se ejecuta dentro de la sesión de ese agente. Consulta qué modelo para qué tarea de código para la decisión más acotada.
¿Cuándo necesito realmente una herramienta para esto? Cuando las decisiones de enrutamiento superan lo que puedes llevar en la cabeza, normalmente hacia los tres agentes y varias tareas abiertas, o cuando un equipo necesita ver las mismas decisiones. Para uno o dos agentes, una tabla mental y terminales separados son suficientes.
¿Sustituye Sharkly a Claude Code o Codex? No. Sharkly no es un sustituto de Claude Code, Codex ni otras herramientas de ejecución. Añade la capa compartida de tareas, ordenador, contexto y revisión en torno a los agentes de código que tu equipo ya usa.
