Todo sistema de agentes se enfrenta al mismo dilema incómodo. Quieres una base de conocimientos profunda y bien organizada que sobreviva a

Cada sistema de agentes se enfrenta al mismo dilema incómodo. Uno desea una base de conocimientos profunda y bien organizada que sobreviva a las revisiones de código y al historial de git. Pero también se necesita que el tiempo de ejecución sea rápido y se mantenga enfocado. Estas dos necesidades trabajan en contra la una de la otra. Cuantas más instrucciones se preserven, más tentador resulta volcarlo todo en el prompt y esperar lo mejor. Esa esperanza es costosa.

En el ecosistema Agent Project Context, esta tensión se divide claramente en dos capas. APC se encarga de la durabilidad. APX se encarga de la velocidad. Comprender cómo interactúan —y por qué APX se niega a precargar cada definición de habilidad— revela más sobre la ingeniería de prompts de lo que la mayoría de las guías de optimización te dirá.

El archivo y el motor

El trabajo de APC es la permanencia. Almacena archivos de habilidades reutilizables en .apc/skills/ como documentos Markdown simples. Debido a que estos archivos residen dentro de tu repositorio, viajan junto con el control de versiones. Puedes abrir un pull request que cambie un procedimiento de despliegue. Puedes comparar (diff) un rollback de una política de seguridad de hace seis semanas. Puedes auditar exactamente qué se suponía que el agente debía saber y cuándo. Esa capacidad de revisión es vital cuando un despliegue erróneo entra en producción o cuando un auditor de cumplimiento empieza a hacer preguntas.

APX, por otro lado, vive el momento. Gestiona la conversación real entre tú y el modelo. Su objetivo no es archivar conocimiento, sino utilizarlo con precisión. Cuando APX trata las habilidades como equipaje permanente, todo el sistema se ralentiza. La ventana de contexto se llena. Los costes de tokens aumentan. Peor aún, la atención del modelo se dispersa entre instrucciones que no tienen nada que ver con la solicitud actual.

Es por esto que el cuerpo de las habilidades se carga bajo demanda.

El verdadero coste de un prompt saturado

La mayoría de los equipos entiende que los tokens cuestan dinero. Menos equipos comprende que los tokens irrelevantes cuestan precisión.

Cuando APX inyecta cada habilidad disponible en cada turno, el prompt se vuelve ruidoso. El modelo recibe el runbook de despliegue, la guía de seguridad, la referencia de estilo de la API, la lista de verificación de pruebas y las FAQ de incorporación, todo a la vez. Incluso con una ventana de contexto amplia, la calidad del razonamiento se degrada cuando el modelo debe primero filtrar el ruido para encontrar la señal. Podría aferrarse a un requisito de seguridad destinado a despliegues de producción mientras responde una pregunta sobre la configuración de pruebas locales. Podría alucinar pasos de una lista de verificación de lanzamiento en una simple corrección de errores. Cada párrafo extra de texto no relacionado es una distracción latente.

La matemática es sencilla. La mayoría de los turnos no necesitan la mayoría de las habilidades. Si estás pidiendo una solución rápida para un registro de errores, no necesitas el texto completo de un runbook de despliegue o una guía de endurecimiento de seguridad. Necesitas que el modelo vea el error, comprenda las convenciones de tu proyecto y edite el archivo correcto. Cargar cuerpos de habilidades irrelevantes no ayuda al modelo a hacer esto. Obliga al modelo a filtrar datos inútiles antes siquiera de empezar a trabajar en tu problema real.

Cómo funciona la carga bajo demanda

El mecanismo es simple pero deliberado. APC continúa manteniendo la fuente de verdad. Tus definiciones de habilidades permanecen donde pertenecen: en .apc/skills/<name>.md.

APX no replica esos archivos en la memoria activa. En su lugar, compila un registro compacto de nombres de habilidades. El modelo ve esta lista y comprende que existe un catálogo. Si necesita explorar o confirmar qué capacidades están disponibles, puede invocar una llamada a list_skills. Esto le otorga visibilidad sin volumen.

Cuando la tarea requiere realmente la sintaxis exacta, los pasos detallados o las restricciones específicas codificadas en un archivo de habilidad, el modelo llama a load_skill. En ese momento, y solo en ese momento, APX recupera el cuerpo Markdown completo desde APC y lo inyecta en el contexto. La instrucción llega lista para su uso inmediato, se utiliza una vez para su propósito previsto y el sistema evita cargarla como peso muerto.

Piensa en la diferencia entre importar una librería y pegar cada definición de función en tu archivo principal. Un enfoque mantiene tu código navegable. El otro crea un desastre que solo compila por accidente.

Quién gana cuando las habilidades colisionan

APX también impone un orden de prioridad claro cuando carga habilidades. No todos los entornos son iguales, y los consejos genéricos nunca deberían invalidar el conocimiento local.

Las habilidades del proyecto tienen la máxima prioridad. Estos archivos residen en su repositorio actual bajo .apc/skills/. Capturan las convenciones específicas de su equipo, sus wrappers personalizados, sus estándares de nomenclatura heredados y su cadena de herramientas particular. Si su proyecto define su propia forma de manejar las migraciones de bases de datos, esa definición prevalece.

Las habilidades globales son las siguientes. Estas cubren patrones de toda la organización que se aplican cuando el proyecto mismo no especifica nada. Actúan como una biblioteca estándar.

Las habilidades de tiempo de ejecución integradas (built-in runtime skills) se encuentran en la base como respaldo. Manejan capacidades genéricas que todo agente debería entender, pero que ningún proyecto específico se ha molestado en redefinir.

Este enfoque por capas significa que su repositorio mantiene el control sobre su propio comportamiento. Una habilidad global o integrada no puede secuestrar accidentalmente un flujo de trabajo que su equipo haya personalizado intencionalmente.

Cómo se ve esto en la práctica

Imagine una tarea de mantenimiento típica. Un compañero de equipo pega un registro de errores en el chat. El traceback apunta a una única referencia nula en un módulo de utilidad. La solución probablemente sea de dos líneas de código defensivo.

En un sistema sin carga bajo demanda, APX saturaría el contexto con cada habilidad que conoce. El modelo ahora tiene cuarenta páginas de texto para considerar antes de tocar esas dos líneas. Ve la lista de verificación de lanzamiento (release checklist) y se pregunta si debería aumentar una versión. Ve la guía de seguridad y contempla la validación de entradas en una función que solo necesita una comprobación de nulos. Ve el manual de despliegue (deployment runbook) y comienza a pensar en entornos de staging. El modelo se dispersa. La respuesta tarda más. El contador de tokens se dispara.

Con el diseño bajo demanda de APX, el modelo solo ve los nombres. Sabe que existen [release-checklist], [security-guide], [deployment-runbook] y [error-handling]. Ignora los tres primeros. Podría cargar [error-handling] si las convenciones de su proyecto para la seguridad de nulos son específicas. Corrige el error. Las habilidades no relacionadas nunca entraron en la ventana de contexto. El modelo se mantuvo enfocado porque el prompt se mantuvo limpio.

La misma lógica se aplica cuando la tarea es realmente compleja. Si más tarde le pide al agente que prepare un despliegue de producción, este puede cargar el manual de despliegue, consultar la guía de seguridad y seguir la lista de verificación de lanzamiento exactamente cuando esos pasos resulten relevantes. El conocimiento siempre estuvo allí. Simplemente esperó el momento adecuado.

La disciplina del prompt como arquitectura

La separación entre APC y APX no es solo un detalle de implementación. Es una filosofía de disciplina de prompt. APC preserva el conocimiento para siempre, haciéndolo revisable, versionado y seguro. APX decide qué parte de ese conocimiento merece un lugar en el contexto activo en este momento.

Un catálogo de habilidades rico es un activo. Un prompt sobrecargado es un pasivo. El objetivo es mantener su contexto portátil sin que esté siempre activo. Su repositorio debe contener cada instrucción que su equipo haya escrito alguna vez, pero el agente solo debe leer aquellas que ayuden con la tarea inmediata.

Si su sistema obliga al modelo a cargar el cuerpo de cada habilidad en cada turno, no está construyendo un asistente inteligente. Está construyendo un bibliotecario que arrastra todo el archivo a cada pregunta en el mostrador de referencias. Guarde todo. Cargue lo que importa. Así es como mantiene a los agentes rápidos, el contexto limpio y el razonamiento agudo.