model: inherit, la convención para que un agente no arrastre tu modelo

La especificación APC recomienda dejar el campo del modelo en inherit en los ficheros que definen agentes, en vez de fijar ahí un proveedor y un identificador concretos. El razonamiento: un rol es conocimiento del proyecto, mientras que la cuenta del proveedor y el catálogo de modelos disponibles dependen de cada máquina.

El rol viaja, el modelo no

APC es la capa de contexto propiedad del repositorio: AGENTS.md y el directorio .apc/ describen lo que un colaborador o un agente necesita saber de un proyecto. APX es el runtime de uso diario que lee ese contexto y ejecuta los agentes. La distinción importa aquí porque el rol es conocimiento del proyecto, y en cambio la cuenta del proveedor y el modelo que hay instalado cambian de una máquina a otra.

El formato recomendado para el frontmatter queda así:

name: reviewer
model: inherit
skills: release-checklist

Lo duradero es la responsabilidad del reviewer: revisar cambios de comportamiento y riesgos de migración. Ese texto tiene que seguir teniendo sentido para un compañero que use otra herramienta compatible. Si el fichero fija un modelo concreto por comodidad, cada clon del repositorio hereda una suposición operativa que puede no cumplirse en su máquina.

inherit es explícito, pero no nombra ningún modelo: dice que la definición del agente no impone ninguna elección y deja que el runtime aplique la suya. El código de resolución de APX trata inherit y un campo vacío como "sin modelo forzado", y resuelve en este orden: primero un override por llamada, después el modelo forzado por el fichero del agente y por último el enrutado activo del runtime. El marcador no se envía a ningún motor como identificador literal.

También facilita las revisiones: cualquier valor distinto de inherit señala una decisión deliberada del proyecto y no un ajuste copiado del portátil de alguien.

Cuándo sí tiene sentido forzar un modelo

A veces el modelo forma parte del contrato. Un agente que evalúa el comportamiento de un modelo concreto, o un flujo que depende de una capacidad que solo tiene uno. En ese caso conviene dejar el motivo escrito junto a la definición y documentar qué pasa si ese modelo no está disponible. "Era mi default en ese momento" es un argumento flojo para imponérselo a todo el equipo, y genera trabajo de mantenimiento cada vez que un proveedor renombra un modelo o alguien usa otro runtime.

La propuesta incluye una auditoría pequeña: leer .apc/agents/*.md, localizar cada valor de modelo concreto y preguntarse por qué está en control de versiones. Los que respondan a un requisito real se quedan, los incidentales pasan a inherit y el modelo efectivo se configura en el runtime. Todo el material está en el repositorio de APC.

Nada de esto promete que haya un modelo instalado, sano o barato: solo saca esa decisión de la definición compartida. El resultado es un rol estable con una frontera operativa clara, y cada uno pone sus credenciales y sus valores por defecto donde le corresponde. La convención solo demuestra su valor cuando son varias las herramientas que leen el mismo repositorio.