El modelo de agentes

¿Qué es un agente?

Un agente es un actor con nombre que tiene una personalidad, un conjunto de skills y un adaptador sobre el que ejecutarse. Los agentes son sujetos de pleno derecho igual que lo son las personas: escriben mensajes, son responsables de tickets, dejan revisiones y aparecen en la misma lista de presencia. Son las entidades que hacen el trabajo.

Cada agente pertenece exactamente a un espacio de trabajo. Es un invariante estricto — agent.workspaceId no admite nulos, el propio espacio de trabajo del agente es lo que determina en qué archivo de base de datos acaban sus filas, y crear un agente sin espacio de trabajo se rechaza.

Un agente es también un directorio. Su definición vive en agents/<slug>/AGENTS.md, dentro del directorio de datos del espacio de trabajo, con las skills que tiene enlazadas simbólicamente en agents/<slug>/.agents/skills. La fila de la base de datos y el archivo se escriben juntos. El sembrado es idempotente: si la fila del agente ya existe, los archivos en disco y los enlaces de skills se reescriben de todos modos. El llamador de producción es la creación del espacio de trabajo, no cada arranque del servidor.

Qué lleva consigo un agente

Atributo	Qué hace
`name`	Identificador corto tipo slug (`architect`, `qa`). También es aquello con lo que se resuelven las `@mentions`
`title`	Puesto de trabajo legible para personas
`persona`	Personalidad e instrucciones de comportamiento en texto libre, inyectadas como una sección del prompt
`systemPrompt`	Instrucciones adicionales opcionales, inyectadas como una sección “Agent instructions” — no reemplazan al resto del prompt ensamblado
`skills`	Conjunto de nombres de skills que no distingue mayúsculas de minúsculas, replicado como enlaces de skills en disco
`adapterId`	A qué ejecutor despacha el agente. Si es nulo, se recurre al bucle integrado
`modelId`	Qué modelo dentro de ese adaptador
`effort`	Nivel de razonamiento, tomado del vocabulario propio del modelo seleccionado
`contextSize`	Anulación de la ventana de contexto
`silenceTimeoutMinutes`	Anulación por agente (1–240) del vigilante de silencio
`reportsTo`	Id del agente superior — la cadena de mando que dibuja el organigrama

Puedes editar todo esto en Ajustes → Espacio de trabajo → Agentes. Nuevo agente crea un agente sin nombre que después completas.

Skills

Las skills son nombres en la entidad del agente que no distinguen mayúsculas de minúsculas. Con ellas ocurren dos cosas distintas:

Los nombres se listan en el prompt ensamblado bajo un encabezado “Skills”. Eso es todo lo que hace por sí solo el conjunto de la entidad — no hay ninguna biblioteca de prompts por skill que dependa de él.
El directorio de cada skill con nombre (skills/<slug>/SKILL.md en el espacio de trabajo) se enlaza en la carpeta del propio agente. En el arnés integrado, el frontmatter de las skills enlazadas se carga automáticamente en el prompt del sistema y el agente lee un cuerpo cuando lo necesita; escribir /skill:<name> en una conversación carga ese cuerpo como directiva para el turno.

Las skills que se obtienen del exterior pasan un análisis fail-closed de la cadena de suministro entre la descarga y la escritura — ningún contenido de skill llega al disco ni a un prompt sin un veredicto. El exterior son repositorios de GitHub que tú mismo registras como fuentes de skills: no hay una tienda curada, así que los metadatos del propio repositorio (su descripción, sus estrellas, el nombre de la skill) son datos de visualización que no son de confianza y el veredicto del análisis es la única señal de seguridad. Una instalación descarga el directorio completo de la skill, la fija al commit del que provino en skills-lock.json, y una actualización posterior vuelve a pasar la compuerta antes de reemplazar nada. El procedimiento está en instalar y administrar skills.

Skills con alcance de repositorio

Un repo puede incluir sus propias skills, en cualquiera de los lugares convencionales (.agents/skills/, .claude/skills/, .opencode/skills/). Un espacio hace el checkout de cada repo vinculado uno al lado del otro bajo repos/<name>/, pero un agente trabaja en un solo repo a la vez — así que lleva solo las skills de ese repo, y estas cambian cuando se mueve.

Qué repo está activo se infiere de los archivos que toca el agente: escribir un archivo bajo repos/<name>/ convierte ese repo en el activo, mientras que solo leer entre repos no lo hace, así que perseguir un símbolo hasta un servicio hermano nunca cambia el conjunto bajo los pies de una tarea. En un espacio de un solo repo, la respuesta se conoce antes del primer turno.

El alcance es una decisión de presupuesto de contexto. El índice de skills está en el prompt en cada turno mientras que los cuerpos no, así que listar las skills de todos los repos a la vez cuesta tokens de forma continua — y una skill testing de un servicio induce a error cuando el trabajo está en otro. El mismo razonamiento explica por qué el índice de un agente lleva un solo repo pero el compositor no tiene ese alcance: nombrar tú mismo una skill es un acto explícito, así que /skill:<repo>:<name> llega a cualquier repo del espacio.

Las skills de un repo se cargan para todos los adaptadores, no solo para el arnés integrado. Las skills del repo activo se materializan en el directorio de trabajo del agente, que es la ruta que Claude Code ya examina; el mismo índice se compone en el AGENTS.md que lee el arnés integrado. Las skills de un repo pasan el mismo análisis fail-closed que una skill instalada antes de que ocurra nada de eso — un repo del que se hizo checkout es contenido clonado, y su frontmatter llega a un prompt.

Permisos

Un agente no lleva indicadores de permisos propios. Si puede crear un commit, hacer push, abrir una pull request, escribir en un rastreador o llegar a la red lo deciden las barandillas de acciones —permitir, preguntar primero o denegar, en el ámbito del espacio de trabajo, del agente o del espacio—, y las mismas reglas se aplican sea cual sea el adaptador que lo ejecute.

Lo que se le entrega a una ejecución no cambia con esas reglas. Una ejecución en un worktree de GitHub recibe siempre un token de GitHub de solo lectura, y un push se pregunta en el momento en que ocurre: la configuración de git del agente envía cada push a GitHub a través de Control Center, que aplica la regla Enviar a un remoto antes de reenviarlo.

Consulta Sandbox y seguridad para ver cómo funciona, incluido qué se aplica y qué no a nivel del sistema de archivos.

El adaptador decide qué se puede aplicar

El campo más determinante de un agente es su adaptador, porque el transporte del adaptador determina cuánta de la política de Control Center es realmente aplicable.

Transporte	Adaptadores	Qué aplica Control Center
Arnés integrado	Control Center (integrado)	Todo. La superficie de herramientas se construye a partir del modo, así que una herramienta no permitida es invisible en lugar de simplemente denegada; cada llamada pasa por la compuerta de aprobación y por las barandillas de acción; el contrato de finalización puede instar al agente y luego hacer fallar una ejecución que termina sin su entregable
Claude CLI	Claude Code	Las herramientas `mcp__*` que se le sirven, más sus comandos `Bash`, que un hook envía a la política de acciones antes de que se ejecuten. Las propias herramientas de lectura, escritura y edición de Claude viven en su proceso y se ejecutan sin que nadie las vea — y se lanza con `--dangerously-skip-permissions`, porque `claude -p` en modo no interactivo se bloquearía para siempre en su propio prompt

En concreto, solo el arnés integrado admite subagentes, orientación a mitad de ejecución, pausa y reanudación (y por tanto la toma de control) y la aplicación estructural de modos. Claude Code no recibe nada de eso.

La matriz anterior trata de lo que Control Center puede ver y filtrar. Por debajo, cc_server envuelve la CLI de Claude Code en el sandbox del sistema operativo del host cuando existe — Seatbelt en macOS, bubblewrap en Linux y WSL2 —, así que un rm que no se ve o una escritura que no se ve siguen limitados por el sistema operativo. En Windows no hay ningún backend en absoluto y en Linux o WSL2 sin bwrap y socat la sonda no informa de ninguno, así que allí esas ejecuciones recurren a la sanitización del entorno, las credenciales intermediadas, las barandillas sobre las llamadas que Control Center sí puede ver y el worktree propio de la conversación (copia en escritura donde se distribuye rift; git worktree en Windows).

Lo que el sandbox no es es una compuerta. Delimita dónde puede un proceso leer, escribir y conectarse — un modo de solo lectura sí llega a él, en forma de montajes bind de solo lectura —, pero no puede interceptar una llamada, levantar una aprobación ni decirte después qué intentó la CLI. Eso, más las cuatro capacidades que acabo de mencionar, sigue siendo lo que tiene el arnés integrado y los demás no. Consulta Sandbox y seguridad.

Un agente sin adaptador recurre a Control Center (integrado) — el bucle dentro del servidor, así que no hay ninguna CLI que instalar — y su registro de ejecución anota cc-harness. Todos los agentes sembrados se crean sin adaptador ni modelo, así que los cinco agentes de un espacio de trabajo recién creado se ejecutan ahí, con el modelo predeterminado de Anthropic, hasta que definas un adaptador y un modelo por agente. La elección de “adaptador predeterminado” de la incorporación inicial es una preferencia del cliente que el servidor nunca lee y no se aplica retroactivamente a los agentes ya creados.

De dónde vienen los agentes

Se siembran con el espacio de trabajo. Todos los espacios de trabajo — no solo el primero — reciben un CEO más cuatro especialistas (qa, architect, engineer, librarian) que le reportan, creados de forma idempotente en segundo plano cuando se crea el espacio de trabajo. Consulta Espacios de trabajo y aislamiento.
Se agregan a mano en Ajustes → Espacio de trabajo → Agentes. Pedirle a un agente que contrate a un colega no crea ninguna fila; usa esa pantalla.

Estado en vivo

Un agente no tiene ninguna columna de estado almacenada. Su estado en vivo se deriva de sus registros de ejecución más recientes cada vez que se lee:

Estado	Significado
`neverRun`	No existe ningún registro de ejecución
`running`	Hay al menos una ejecución en curso
`failed`	La última ejecución dio error, o su estado de actividad es failed o dead
`blocked`	El estado de actividad de la última ejecución es blocked, stalled o looping
`idle`	Todo lo demás — el agente ya se ejecutó antes y no tiene nada en curso

Existen dos estados más, queued y succeeded, para ejecuciones individuales dentro del árbol de ejecuciones de la conversación; la lista de presencia nunca los produce, porque que una ejecución terminada esté en verde es un hecho sobre la ejecución, no sobre el agente.

La lista de presencia muestra una imagen paralela y más gruesa, sintetizada del lado del servidor a partir de los eventos de ejecución en vivo — Pensando, En curso, Bloqueado, Listo —, que es lo que hace que los agentes aparezcan junto a las personas. Consulta Multijugador y presencia.

Conceptos relacionados

Ciclo de vida del despacho de un agente: qué ocurre cuando un agente se ejecuta de verdad
Modos: el ajuste por conversación que da forma a la superficie de herramientas de un agente
Multijugador y presencia: los agentes como sujetos de pleno derecho, la presencia y el dial de autonomía
Sandbox y seguridad: qué limita hoy una ejecución
Configuración de agentes: la lista completa de campos