Nadie confía en un compañero de equipo nuevo por su currículum. La confianza nace de la estructura: una responsabilidad bien delimitada, trabajo que ocurre donde el equipo puede verlo y una revisión antes de que nada salga a producción. Elimina cualquiera de esos elementos y hasta el colega más brillante se convierte en un riesgo. Con los agentes de IA como compañeros de equipo pasa lo mismo. La pregunta nunca es «¿es el modelo lo bastante inteligente?», sino «¿sé qué puede tocar esto, puedo ver lo que hizo y hay algo que salga a producción sin que una persona dé el visto bueno?».
Sharkly responde a eso con configuración, no con promesas. Un Agente en Sharkly es una configuración de trabajo guardada, no un prompt puntual: sus instrucciones, su Runtime, sus Skills, sus repositorios, su entorno y sus ajustes de ejecución definen cómo aborda el trabajo. Un prompt desaparece cuando se cierra la terminal. Una configuración se puede inspeccionar, compartir y se mantiene estable en cada ejecución.
Si prefieres empezar por la visión general de la plataforma, echa un vistazo a qué es Sharkly y luego vuelve.
TL;DR
Un Agente en Sharkly es una configuración de trabajo guardada y reutilizable para un actor de IA: instrucciones de funcionamiento, un vínculo con un Computer y un Runtime, Skills asociadas, repositorios Git, variables de entorno y ajustes de ejecución como la concurrencia, los tiempos de espera y el modo de directorio de trabajo. Confías en él igual que confiarías en un compañero de equipo: por su estructura, no por fe. Su alcance está explícito en la configuración, sus estados de ejecución y su traza son visibles, y sus resultados vuelven a la Tarea, donde una persona los revisa y los acepta. Los Agentes investigan, ejecutan, prueban e informan. Las personas marcan el rumbo, conceden autoridad y aceptan el resultado.
Qué es un Agente (y qué no es)
Un Agente es un actor de IA configurado para gestionar trabajo en Sharkly. Puede recibir Tareas asignadas, escribir comentarios, actualizar el estado de la Tarea mediante el flujo de trabajo disponible y generar una traza de ejecución. Como la configuración se guarda, un equipo puede mantener Agentes distintos para cambios de código, revisión, pruebas, documentación o triaje operativo sin tener que reescribir las mismas instrucciones en cada Tarea.
Hay dos límites que conviene dejar claros desde el principio.
Un Agente no es el host de ejecución. Su trabajo se ejecuta a través de un Runtime seleccionado en un Computer conectado. El Agente define cómo debe abordarse el trabajo; el Computer aporta el host; el Runtime lleva a cabo la sesión propiamente dicha; la Tarea sigue siendo el registro compartido. Cada rol tiene una única función, y por eso un mismo Computer puede dar servicio a varios Agentes.
Un Agente no elige su propio modelo. Sigue el modelo predeterminado del Runtime y no tiene selector de modelo ni control de profundidad de razonamiento. Para usar otro modelo, cámbialo en la configuración de herramientas del Runtime o del Computer, por ejemplo en el propio Claude Code o Codex.
La confianza es una propiedad del sistema, no del modelo
Este artículo se apoya en una idea: un agente es digno de confianza cuando su trabajo está delimitado, es visible y se puede revisar. No cuando el modelo impresiona.
Delimitado significa que la autoridad del Agente queda por escrito antes de que se ejecute: a qué repositorios puede acceder, en qué Computer se ejecuta, qué permiten sus instrucciones, cuántas Tareas puede ejecutar a la vez y cuánto puede durar una ejecución. Visible significa que los estados de ejecución, los eventos de la traza y los resultados vuelven a la Tarea, donde cualquiera puede inspeccionarlos, en lugar de desaparecer en una terminal privada. Revisable significa que hay una persona al final del circuito: un Agente puede dejar una Tarea a la espera de una respuesta humana o de una revisión humana, y esas señales llegan a la bandeja de entrada de la persona responsable.
Ese es el contrato entre personas y agentes llevado a la práctica. La automatización se detiene donde hace falta el criterio del equipo. Si todavía estás evaluando el flujo de trabajo en sí, nuestra introducción a la codificación agéntica repasa el cambio de escribir prompts a asignar trabajo.
La superficie de configuración del Agente
Un Agente puede incluir nombre, descripción, avatar y propietario; instrucciones de funcionamiento; visibilidad y ubicación en un Space; una conexión de Computer y un proveedor de Runtime; Skills asignadas; repositorios Git específicos del Agente; variables de entorno normales y secretas; argumentos adicionales del Runtime; ajustes del directorio de trabajo de las Tareas; y un máximo de Tareas en ejecución paralela junto con un tiempo de espera por Tarea. Cada pieza es una palanca de confianza.
Las instrucciones se incluyen en cada ejecución. Úsalas para el comportamiento que debe mantenerse en todas las Tareas: alcance y rol, cómo inspeccionar una Tarea antes de actuar, cuándo pedir intervención humana, las comprobaciones esperadas y el formato de los informes. La documentación traza una distinción útil en tres direcciones: los requisitos específicos de una Tarea van en la descripción o en los comentarios de la Tarea; un procedimiento reutilizable que varios Agentes pueden compartir va en una Skill; y las instrucciones propias del Agente recogen su identidad estable. «Lee la descripción de la Tarea y los comentarios recientes antes de editar. Limita los cambios al comportamiento solicitado. Ejecuta las comprobaciones relevantes más cercanas e informa de los fallos sin ocultarlos» corresponde al Agente, porque debe seguir siendo cierto el lunes y seguir siéndolo en marzo. La descripción sirve a otro lector: indica a las personas qué pueden asignar, mientras que las instrucciones le dicen al Agente cómo trabajar.
La visibilidad puede ser Personal, disponible solo para su propietario actual, o Space, disponible para las personas con acceso al Space del Agente. También controla quién puede asignarle Tareas al Agente, iniciar un Agent Chat con él o activarlo mediante un comentario o una mención. Empieza en Personal mientras lo ajustas; pásalo a Space cuando la configuración merezca la pena compartirla. Ese ascenso es el momento en que la forma de trabajar de un desarrollador se convierte en infraestructura del equipo.
Computer y Runtime se combinan para formar el destino de ejecución. Que un Computer esté en línea solo significa que su servicio local está enviando latidos; no significa que el Runtime seleccionado pueda ejecutar una Tarea. Si el Computer está desconectado, las nuevas ejecuciones normalmente esperan a que se vuelva a conectar; si el Runtime seleccionado ya no está, elige otro que sea válido. Toda la historia de la configuración está en Computers en Sharkly.
Las Skills empaquetan instrucciones reutilizables y archivos de apoyo: reglas de revisión, listas de verificación de entrega, un proceso de equipo. Las Skills locales del Runtime siguen disponibles automáticamente en ese Computer; las Skills compartidas del Space deben asignarse explícitamente. Una advertencia que merece la pena repetir: evita vincular muchas Skills que se solapen, porque las instrucciones contradictorias hacen que la ejecución sea menos predecible. Consulta Skills en Sharkly para profundizar.
Los repositorios son la palanca de delimitación más limpia que tienes. Asígnalos al Agente cuando necesite un alcance de código más estrecho que el predeterminado del Space; si no hay vinculaciones, Sharkly recurre a los repositorios configurados para el Space de la Tarea. Un Agente de documentación vinculado al repositorio de docs no tiene ninguna vía de acceso a tu servicio de pagos.
El entorno y los ajustes de ejecución delimitan lo que puede consumir una ejecución. Las variables de entorno normales y secretas, junto con argumentos adicionales del Runtime, permiten que una ejecución lleve configuración sin que nadie pegue credenciales en una Tarea. Nunca pongas tokens de repositorio, claves privadas ni tokens de instalación en la descripción de una Tarea, en un comentario, en las instrucciones de un Agente o en una Skill. La configuración de ejecución de la Tarea (Task Run Settings) controla las Tareas en paralelo, la duración máxima de las ejecuciones y el modo de directorio de trabajo:
| Modo temporal | Modo especificado | |
|---|---|---|
| Qué obtiene una ejecución | Un directorio aislado por Tarea; las ejecuciones respaldadas por un repositorio pueden preparar un worktree nuevo | Un directorio local absoluto configurado, del grupo de directorios del Agente |
| Concurrencia | Ejecución paralela más segura; el valor predeterminado es el 50 % del límite del Computer | Una ejecución por directorio a la vez; el valor predeterminado coincide con el número de directorios |
| Disponibilidad | Cualquier Computer conectado | Solo Computers locales |
| Ideal para | La mayor parte del trabajo con repositorios, y cualquier situación en la que varias Tareas puedan modificar el mismo código en paralelo | Repositorios muy grandes, cachés locales costosas o Tareas ligadas a servicios locales |
Si estableces un valor de concurrencia manual superior al número de directorios, el producto te avisa de que las escrituras pueden chocar. La mecánica de aislamiento es el tema de cómo Sharkly ejecuta Agentes en paralelo sin conflictos de fusión.
Conversaciones y Tareas: dos superficies, una regla
El Agent Chat es una conversación independiente para hacer una pregunta, investigar un tema o dar forma a un plan antes de que algo necesite una Tarea con seguimiento. El chat admite tres modos: Explore, para investigación de solo lectura; Plan, para propuestas que revisas y confirmas antes de que Sharkly cree la tarea y las subtareas planificadas; y Execute, para actuar directamente a través de la CLI configurada del Agente. Cada sesión pertenece a la persona que la creó.
Una Tarea es donde va el trabajo cuando necesita un responsable, un estado, un historial de ejecución o una revisión. El par de decisión: usa el chat para explorar, planificar o actuar antes de que el trabajo necesite una Tarea con seguimiento; usa la Tarea cuando el trabajo necesite un responsable asignado, un estado, criterios de aceptación o un registro duradero.
Hay un límite que evita que los equipos pierdan contexto. Enviar un mensaje en el Agent Chat no crea un comentario de tarea, y los mensajes del chat de Agente de una tarea no aparecen en Activity como comentarios. Si el equipo necesita ver una conclusión, cópiala en la descripción de la tarea o en un comentario. La confianza depende del registro compartido, y el registro compartido es la Tarea.
Qué te dicen los estados
Aquí la visibilidad es un conjunto concreto de estados que puedes leer, no un eslogan de panel de control.
La ejecución de una Tarea pasa por queued, dispatched, waiting for local directory, running, completed, failed y canceled. Los estados de ejecución son independientes del estado del flujo de trabajo de la Tarea: una ejecución puede fallar mientras la Tarea sigue abierta para un nuevo intento. El registro de ejecución documenta por qué se puso en cola una ejecución, cuándo empezó y terminó, las llamadas a herramientas y los eventos del Runtime, el origen del desencadenante y los detalles del fallo.
La disponibilidad del Agente es una tercera señal, independiente. Un Agente en línea puede tener trabajo en cola porque la concurrencia o la capacidad de directorios está completa. Y Backlog funciona como zona de aparcamiento: una Tarea asignada a un Agente espera mientras está en Backlog, y moverla a un estado listo para trabajar es lo que inicia la ejecución. Asignar un Agente nunca dispara trabajo por sorpresa.
Tu primer Agente: un recorrido en el que puedes confiar
La forma más rápida de generar confianza es el bucle útil más pequeño de la documentación de Sharkly: conecta un Computer, crea un Agente y asígnale una Tarea de bajo riesgo.
- Conecta un Computer. Abre Settings, luego Computers y elige Connect Computer. Espera hasta que aparezca como conectado con al menos un Runtime disponible.
- Crea el Agente con un rol acotado. Nombre: Code Reader. Descripción: lee un repositorio, explica la implementación actual e informa de los riesgos sin modificar archivos. Visibilidad: Personal.
- Escribe instrucciones que hagan cumplir el alcance: «Lee la Tarea completa y los comentarios relevantes antes de actuar. Limita el alcance a lo solicitado. Para la primera Tarea, no edites archivos. Informa de lo que inspeccionaste, de las pruebas que respaldan cada conclusión y de todo lo que siga siendo incierto».
- Vincula el código. Adjunta un repositorio Git o configura un directorio local especificado que ya lo contenga. Las Skills pueden esperar.
- Crea una Tarea pequeña, solo de texto: revisa la ruta de error de autenticación, identifica tres casos de fallo visibles para el usuario, cita el archivo relevante en cada uno y no cambies nada.
- Asígnala e iníciala usando un estado listo para trabajar en lugar de Backlog. Observa cómo el estado de ejecución pasa de queued a running y lee el resultado en la Tarea.
- Revisa de verdad. Comprueba que el Agente inspeccionó el código previsto, se mantuvo dentro del límite de no editar, aportó pruebas y registró la incertidumbre en lugar de suponer.
Ese último paso es lo esencial. Una primera Tarea de solo lectura permite que el Agente se gane autoridad antes de tener ninguna. Cuando el bucle funcione, amplía el alcance de forma deliberada. Toda la mecánica de asignación está en cómo asignar tu primera Tarea a un Agente de codificación con IA.
Y si un Agente deja de ganarse esa confianza, revocarla es limpio. Archivarlo lo elimina de las asignaciones y las menciones y cancela su trabajo en curso, mientras que sus Tareas anteriores, sus comentarios y su historial de ejecuciones siguen disponibles. Un compañero de equipo al que puedes dar de baja sin perder el registro de su trabajo es un compañero de equipo que puedes permitirte incorporar.
Preguntas frecuentes
¿Qué es exactamente un Agente en Sharkly?
Un Agente es un actor de IA configurado para gestionar trabajo en Sharkly: una configuración guardada de instrucciones, un vínculo con un Computer y un Runtime, Skills, repositorios, variables de entorno y ajustes de ejecución. Puede recibir Tareas asignadas, escribir comentarios, actualizar el estado de la Tarea y generar una traza de ejecución. Como la configuración se guarda, la forma de trabajar de una persona se vuelve reutilizable cuando el Agente se comparte con un Space.
¿Qué modelo usa un Agente de Sharkly?
El Agente sigue el modelo predeterminado del Runtime que tenga seleccionado, como Claude Code o Codex, y no muestra ni promete un nombre de modelo concreto. No hay selector de modelo ni control de profundidad de razonamiento en el Agente. Para cambiar de modelo, actualiza la configuración de herramientas del Runtime o del Computer.
¿Cuál es la diferencia entre chatear con un Agente y asignarle una Tarea?
El Agent Chat es una conversación independiente para explorar, planificar o actuar antes de que el trabajo necesite un registro con seguimiento. Una Tarea es la unidad de trabajo compartida, con responsable, estado, historial de ejecución y revisión. Los mensajes del chat no se convierten en comentarios de la tarea, así que las conclusiones que debe ver el equipo van en la Tarea.
¿Cómo limito lo que puede hacer un Agente?
El alcance se define en la configuración: las instrucciones definen el rol y las reglas de precaución, las vinculaciones de repositorios limitan qué código ve el Agente y la configuración de ejecución de la Tarea limita las Tareas en paralelo y la duración de las ejecuciones. El modo de directorio de trabajo temporal añade aislamiento al dar a cada Tarea su propio directorio. La aceptación final sigue siendo responsabilidad de una persona.
¿Por qué no arranca la Tarea que he asignado?
Comprueba tres cosas. Una Tarea en Backlog espera por diseño; muévela a un estado listo para trabajar. Que un Computer esté en línea solo significa que llegan latidos, así que confirma que el Runtime seleccionado aparece como disponible. Y un Agente en línea puede seguir poniendo trabajo en cola cuando su concurrencia o sus directorios especificados están llenos.
