Agent Profiles and Custom Agent Configuration
Qué problema resuelven
Un Agent Profile es configuración reutilizable que especializa un agente para un rol, dominio o clase de tareas mediante las características que admita su implementación. Puede seleccionar instrucciones, herramientas, skills, modelo u opciones del runtime. La definición de trabajo del Atlas no impone una lista de campos obligatorios ni identifica un perfil con un formato de proveedor.
La especialización puede reducir decisiones repetidas. Un equipo que investiga migraciones .NET puede querer una orientación consistente sobre compatibilidad y evidencia. Configurar ese foco resulta distinto de repetir todo en cada encargo. También introduce mantenimiento: si cambian herramientas, restricciones o contratos del proyecto, el perfil puede seguir orientando trabajo con supuestos que dejaron de ser válidos.
El problema no exige multiplicar especialistas. Un agente general con contexto suficiente puede resolver muchas tareas. Crear perfiles solo por tecnologías o roles nominales puede fragmentar instrucciones y generar selección confusa. Un perfil aporta valor cuando sus diferencias ayudan a realizar una clase reconocible de trabajo; el nombre del rol no demuestra esa utilidad.
Profile vs Agent
agents describe un sistema que persigue un objetivo mediante interacción y feedback. Un perfil es configuración que puede utilizar ese sistema. No ejecuta trabajo, mantiene un loop ni produce resultados por existir en un directorio. Varias ejecuciones pueden usar el mismo perfil y obtener resultados diferentes según tarea, contexto, herramientas y estado del entorno.
Esta separación permite preguntar qué se reutiliza. El perfil puede conservar instrucciones de un especialista; la ejecución concreta conserva observaciones y progreso de una tarea. Cambiar la configuración no reescribe automáticamente decisiones ya tomadas ni modifica sesiones activas de forma uniforme. Ese comportamiento depende del runtime y de cuándo carga o actualiza la configuración.
Un archivo llamado «reviewer» puede definir un perfil, pero no prueba que haya ocurrido una revisión. Para afirmar eso hacen falta una ejecución y evidencia de lo que contrastó. También es posible configurar un rol mediante código o un servicio, sin un archivo visible con ese nombre. La representación no decide por sí sola la categoría conceptual.
Profile vs Skill e Instruction
agent-skills conserva un procedimiento reutilizable. El perfil configura un especialista que puede tener acceso a varias skills. Una skill de análisis de migraciones puede servir a un agente general o a un especialista; no queda ligada por definición a un único perfil. La configuración tampoco tiene que contener una skill para poder considerarse perfil.
persistent-instructions aporta guía reutilizable. Un perfil puede incluir o referenciar instrucciones, pero también definir otras dimensiones soportadas, como herramientas disponibles. A su vez, la guía de un repositorio puede aplicar a varios perfiles. Tratar ambos como sinónimos oculta si una diferencia proviene de orientación textual o de capacidades efectivas de la ejecución.
task-prompts mantiene el encargo concreto. Seleccionar un perfil para migraciones no solicita todavía ninguna migración. La tarea debe identificar versión, componente, resultado esperado y límites relevantes. Un perfil que conoce convenciones del equipo no puede inventar la decisión de actualizar una dependencia ni ampliar el scope hacia cambiar arquitectura porque su descripción mencione modernización.
Profile vs Subagent
Subagents and Delegation desarrolla la ejecución delegada a la que se encarga trabajo dentro de una coordinación. Puede utilizar un perfil, pero no es ese perfil. Crear una definición de especialista y delegar una tarea son operaciones distintas. La primera conserva configuración; la segunda inicia trabajo con contexto, recursos y condiciones de terminación.
Un perfil también puede aplicarse al agente principal, sin delegación. No requiere jerarquía, concurrencia ni aislamiento. Cuando un producto llama «custom agent» a una definición y «subagent» a una ejecución, su terminología puede aproximarse a estas distinciones; otro puede usar nombres diferentes. Conviene identificar configuración y actor antes de deducir comportamiento del nombre comercial.
El contexto de una delegación tampoco se deduce del perfil. Puede recibir un resumen limitado o material más amplio según el sistema. Sus permisos y sandbox necesitan revisión independiente. Una configuración de «especialista seguro» no demuestra que la ejecución tenga aislamiento técnico, credenciales diferentes o una frontera de aprobación distinta.
Dimensiones posibles de configuración
Los perfiles pueden combinar varias dimensiones. La tabla enumera posibilidades, sin exigirlas ni afirmar que todos los clientes permitan configurarlas. Un host puede limitar opciones, heredar valores del agente padre o impedir cambios sobre capacidades sensibles.
| Dimensión | Qué puede especializar | Qué no demuestra |
|---|---|---|
| Instrucciones | Foco, criterios y forma de reportar. | Cumplimiento automático. |
| Tools | Capacidades expuestas o restringidas. | Autorización sobre todos sus destinos. |
| Skills | Procedimientos disponibles o recomendados. | Activación en cada tarea. |
| Modelo / runtime | Opciones admitidas de ejecución. | Mejor resultado para cualquier encargo. |
| Contexto | Fuentes y preparación soportadas. | Información actual y completa. |
Configurar herramientas no equivale a especializar por sí solo el razonamiento. Una lista de APIs puede delimitar capacidades sin expresar qué revisión debe realizarse. A la inversa, una instrucción detallada puede orientar a un especialista sin reducir herramientas. Interesa examinar ambas dimensiones, porque sus efectos y garantías son diferentes.
Las opciones de modelo también requieren contexto. Un perfil puede seleccionar una configuración admitida, pero no convierte esa elección en una propiedad durable del concepto. Disponibilidad, costos y características cambian; no se necesita fijar aquí un catálogo ni una recomendación de producto. El resultado debe evaluarse respecto de la tarea y de las restricciones reales.
Algunos hosts permiten expresar restricciones de permisos o preferencias del entorno dentro de la configuración; otros las heredan o las definen fuera del perfil. Son dimensiones posibles, no campos universales ni garantías de aislamiento. Para un especialista .NET puede ser importante conocer el SDK disponible y carecer de autorización de deployment. Hay que comprobar ambas condiciones en la ejecución efectiva: describirlas en el perfil no instala el SDK ni elimina una credencial expuesta. Esta separación permite revisar configuración deseada y realidad del entorno sin confundirlas.
Scope, reutilización y autoridad
El scope de un perfil puede ser un proyecto, equipo, usuario o clase de encargos según su distribución y selección. No existe una jerarquía universal de perfiles globales, locales y temporales. Una configuración de repositorio puede combinarse con guía de otra procedencia; los conflictos se resuelven bajo el contrato efectivo de la ejecución.
Especializar no concede autoridad. agent-permissions-and-approval-boundaries delimita acciones autorizadas y decisiones adicionales. El perfil puede reducir capacidades cuando el host lo permite, pero no debe interpretarse como una forma general de saltar restricciones heredadas. agent-execution-environment y agent-sandboxing conservan recursos y límites técnicos que un nombre de rol no cambia.
Reutilizar requiere controlar vigencia y compatibilidad. Copiar un perfil de otro repositorio puede introducir comandos inexistentes o supuestos de dominio equivocados. Si un procedimiento estable merece mantenerse como unidad independiente, puede ubicarse en una skill en vez de duplicarse en muchos perfiles. La separación ayuda cuando reduce divergencias; no obliga a diseñar una biblioteca genérica antes de necesitarla.
La especialización excesiva puede introducir otro fallo: interpretar toda tarea desde el rol seleccionado. Un perfil de rendimiento podría privilegiar latencia cuando el encargo exige legibilidad o compatibilidad. Sus instrucciones deben orientar la contribución sin sustituir el objetivo actual. Evaluar un perfil requiere observar si ayuda en tareas apropiadas y reconoce encargos fuera de su alcance, además de comprobar que la configuración carga. Si varios perfiles repiten guía o difieren solo en el nombre, puede ser más simple consolidarlos. Mantener una colección grande tiene costo de revisión y selección aunque cada archivo sea pequeño.
Routing hacia especialistas
Routing decide a qué perfil, actor o ruta enviar una tarea. La definición del especialista y el mecanismo que lo selecciona son responsabilidades separadas. agentic-workflow-patterns organiza esa selección junto con otras familias de composición, sin exigir un sistema multiagente. Un usuario puede elegir directamente un perfil y continuar con una única ejecución.
La descripción del perfil puede informar la selección, pero no elimina ambigüedad. Dos especialistas pueden coincidir sobre una migración que afecta datos y APIs. No corresponde delegar por defecto a ambos ni asumir que sus conclusiones se integrarán sin conflicto. El sistema necesita conservar el objetivo común, los límites de cada encargo y la forma de revisar resultados.
Una ruta equivocada puede producir trabajo formalmente correcto pero poco pertinente. Un especialista en rendimiento podría sugerir mediciones cuando el problema es una regla de autorización. La recuperación empieza por reconocer el desajuste y conservar observaciones útiles, sin convertir la preferencia del perfil en un requisito del producto.
Terminología y formatos de producto
Los ejemplos fueron consultados el 2026-10-26. Muestran implementaciones; sus nombres y campos no forman un schema común del Atlas.
| Producto | Ejemplo actual | Distinción que conviene conservar |
|---|---|---|
| Codex | Definiciones de agentes personalizados mediante TOML. | Configuración del especialista frente a ejecución delegada. |
| Claude Code | Definiciones Markdown con frontmatter para subagents. | Archivo de definición frente a trabajo que se inicia con él. |
| GitHub Copilot | Agent profiles en Markdown con configuración. | Perfil reutilizable frente a capacidades admitidas por cada superficie. |
La documentación de Codex describe restricciones heredadas que la definición no puede ampliar libremente. Ese ejemplo demuestra por qué un perfil no debe presentarse como fuente universal de permisos. Los otros productos tienen sus propios campos, scopes y límites; similitud de formato no prueba paridad de comportamiento ni portabilidad directa de la configuración.
Custom Agent puede nombrar una función de producto, una definición o el sistema resultante. Specialist expresa un rol; Subagent expresa delegación en el modelo conceptual del Atlas. Profile permite hablar de configuración sin afirmar que toda especialización se ejecuta como subagent. El término conserva esa utilidad aunque los productos cambien filenames o superficies de selección.
Ejemplo de especialización acotada
Un equipo usa un perfil de revisión de migraciones de Commerce.Api. Su foco es identificar cambios incompatibles, revisar contratos y comunicar evidencia pendiente. Puede tener lectura del repositorio y acceso a herramientas de pruebas permitidas. Una skill aporta el procedimiento de análisis; la tarea concreta identifica la dependencia y la versión objetivo. No se crean esos artefactos aquí: el ejemplo explica responsabilidades.
Si la investigación descubre que una migración exige alterar el contrato de cobros, el perfil no decide aceptarlo. Puede documentar el impacto y la alternativa. Si faltan recursos para ejecutar una prueba, debe conservar esa limitación en development-context-and-execution-records. El propósito del especialista es ayudar a tomar una decisión informada, no producir una apariencia de cierre mediante su nombre.
El perfil tampoco necesita convertirse en dueño permanente del área. La responsabilidad del equipo, la revisión de cambios y la autorización de release conservan sus contratos. Una mejor configuración puede facilitar trabajo consistente, pero su utilidad debe verse en tareas reales y no solo en una descripción exhaustiva del rol.
Relaciones y fuentes
Una Agent Card de A2A anuncia interfaces y capacidades de un sistema para interoperar; el perfil configura su especialización. Una descripción puede relacionarse con la otra, pero anunciar una capacidad no instancia un agente ni concede autoridad. ACP define otra frontera de comunicación, sin convertirse en la configuración del especialista.
agent-harness puede cargar perfiles y mediar las capacidades de una ejecución. agent-extension-packages puede distribuirlos cuando el host los admite. coding-agent describe al sistema que realiza el encargo y ai-assisted-software-engineering organiza la navegación. Este canonical no configura especialistas reales ni prescribe una arquitectura de delegación.
Fuentes primarias consultadas el 2026-10-26. La definición, las distinciones y Commerce son síntesis editorial del Atlas; los formatos y restricciones pertenecen a cada producto.