Arquitectura pública de ALLAN

Tres planos para una misma capacidad

La arquitectura puede leerse como la relación entre tres planos:

1. Definición. Describe qué trabajo representa el agente, qué contexto necesita, qué herramientas puede solicitar y cómo debe evaluarse.
2. Ejecución. Convierte una petición en un run con estado, presupuesto, trazas, herramientas, delegaciones y posibles pausas.
3. Gobierno. Decide quién puede utilizar o modificar la capacidad, qué políticas se aplican, cuánto consume y cómo se publica una nueva versión.

La separación evita que una decisión de producto quede escondida en un prompt, que un permiso dependa de la buena voluntad del modelo o que la interfaz de chat se convierta en la fuente de verdad del trabajo.

El agente como paquete declarativo

En ALLAN, un agente se define mediante un directorio de artefactos Markdown y YAML. El paquete puede declarar, entre otros elementos:

• el propósito y las instrucciones de trabajo;
• el manifiesto y los metadatos de ejecución;
• las herramientas permitidas y denegadas;
• las capacidades reutilizables o skills;
• los flujos aplicables a determinadas peticiones;
• los criterios de evaluación;
• la memoria mantenida deliberadamente.

Los artefactos no son equivalentes entre sí. Una instrucción establece el marco de actuación; un manifiesto delimita capacidades; un flujo restringe una ejecución; una evaluación observa el resultado. Declarar un artefacto tampoco implica que el runtime lo inyecte de forma pasiva: cada tipo necesita un ciclo de vida explícito que determine cuándo se descubre, valida y utiliza.

Esta fuente de verdad pertenece al proyecto y al runtime de ALLAN; no es un formato de intercambio de instrucciones con sistemas externos.

Un único motor y una responsabilidad raíz

Cada run tiene un agente raíz que conserva la responsabilidad sobre el trabajo. Puede responder directamente, utilizar herramientas o delegar tareas acotadas a agentes trabajadores. Varias delegaciones independientes pueden ejecutarse en paralelo, pero sus resultados vuelven al agente raíz, que debe integrarlos y responder.

El motor vigente reúne esos comportamientos en un solo ciclo de ejecución. Así, conversación, uso de herramientas y delegación comparten las mismas reglas de presupuesto, pausa y trazabilidad, sin producir estados incompatibles entre rutas de ejecución distintas.

La delegación no transfiere autoridad ilimitada. El trabajador recibe una tarea, un presupuesto y un conjunto de herramientas que solo puede ser igual o más estrecho que el del agente que delega. La revisión de un trabajador puede asesorar; no borra la responsabilidad del agente raíz.

Extracto. Delegar distribuye trabajo, no diluye responsabilidad. El agente raíz sigue siendo propietario del run, del presupuesto y de la respuesta que se entrega.

Flujos que restringen una ejecución

Los flujos declarativos permiten asociar instrucciones, herramientas y límites a determinados tipos de petición. Se seleccionan por disparadores y se compilan a una representación intermedia cacheada por contenido.

Cuando coinciden varios pasos, ALLAN los combina en una configuración restringida para un único run. No los trata como una cadena de ejecuciones independientes que se pasan estado implícito. Las puertas o gates se evalúan al terminar el trabajo real.

Esta diferencia es relevante: un flujo describe condiciones para ejecutar y evaluar un trabajo; no crea por sí solo una orquestación distribuida durable.

Herramientas bajo policy

Las herramientas conectan el razonamiento con efectos observables: consultar un recurso, buscar información, editar un artefacto o solicitar una operación externa. ALLAN utiliza Model Context Protocol (MCP) como contrato de conexión con herramientas propias y externas.

MCP proporciona interoperabilidad, no autorización empresarial. La declaración de una herramienta y sus anotaciones no bastan para conceder permisos. Antes de una operación, el runtime aplica una policy que puede:

• permitirla;
• exigir aprobación;
• denegarla.

La definición del agente, un flujo o una delegación pueden reducir el conjunto disponible, nunca ampliarlo en tiempo de ejecución. Las herramientas sin una anotación fiable de solo lectura se tratan de forma conservadora como potencialmente mutantes.

El run debe sobrevivir a la conexión

Una conversación y un run no tienen el mismo ciclo de vida. La primera es el contexto de interacción; el segundo es una unidad de trabajo con estado propio. Cerrar una pestaña o perder una conexión de eventos no debería decidir si el trabajo continúa.

ALLAN persiste el estado operativo, las trazas, los pasos, las llamadas a herramientas, las aprobaciones y las solicitudes de intervención humana. Una petición humana puede pausar la ejecución y conservar el contexto necesario para reanudarla sin fingir que la acción pendiente llegó a ejecutarse.

La persistencia no elimina por sí sola los problemas distribuidos. Los efectos externos necesitan idempotencia; las reanudaciones deben reconocer el motor y el alcance que originaron el estado; y la gestión completa de ejecuciones asíncronas requiere leases, cancelación y reconciliación de trabajos huérfanos. Estas últimas capacidades se mantienen como arquitectura en evolución.

Sesión, memoria y espacio de trabajo

ALLAN distingue tres formas de continuidad:

• Sesión. Conserva el diálogo y el estado de interacción.
• Memoria. Mantiene hechos o experiencias que deben influir en trabajos posteriores, con procedencia y alcance definidos.
• Espacio de trabajo. Proyecta artefactos duraderos —documentos, decisiones o resultados— que las personas pueden consultar y revisar.

Confundirlas produce efectos indeseados. Un mensaje antiguo no se convierte automáticamente en memoria; una memoria interna no es un documento aprobado; y un fichero visible no sustituye el estado durable del run que lo produjo.

El diseño de memoria individual añade varias resoluciones y temporalidad para distinguir qué se afirmó, cuándo era válido y cuándo lo conoció el sistema. La memoria colectiva, la consolidación entre agentes y sus derechos de privacidad permanecen como línea de investigación explícita.

Comunicación y conversaciones con varios agentes

La colaboración interna utiliza mensajes con identidad, propósito, hilo de conversación y trazabilidad. El vocabulario se inspira en la tradición de actos comunicativos de FIPA, pero ALLAN no declara conformidad formal con FIPA ACL.

Los compromisos y las respuestas forman un estado público auditable. Cuando un agente delega, se conserva la genealogía del trabajo y su atribución de coste. Cuando varios agentes participan en una conversación humana, el turno sigue teniendo un coordinador visible: la multiplicidad de especialistas no debe convertir la interfaz en una carrera de respuestas.

Agent2Agent (A2A) y MCP cumplen papeles complementarios en el ecosistema: A2A normaliza interacciones entre agentes; MCP, interacciones con herramientas y fuentes de contexto. Ninguno sustituye la policy, la identidad del tenant ni el registro durable de ALLAN.

Del borrador a una capacidad publicada

El ciclo de vida separa creación, evaluación, publicación y retirada. La herramienta de creación —Forge— produce un paquete revisable; el registro mantiene identidad, versiones y estado de publicación; el runtime ejecuta la versión que corresponde.

Una puntuación no basta para promover autonomía. Deben considerarse el riesgo de las herramientas, la reversibilidad de las acciones, el historial de incidentes, la calidad de las trazas y la capacidad de supervisión. La publicación humana y el rollback son fronteras de gobierno, no detalles de la interfaz.

La mejora automática de instrucciones o capacidades no forma parte de la arquitectura consolidada. Los diseños exploratorios separan al agente que detecta oportunidades del que puede escribir, congelan las evaluaciones y mantienen la decisión de publicación en una persona.

Multi-tenancy y fronteras de plataforma

Cada tenant constituye una frontera lógica de aislamiento. Distintos tenants pueden compartir infraestructura, pero nunca estado de ejecución —agentes generados, sesiones, tareas, memoria o buzones— salvo mediante un contrato explícito y autorizado.

La interfaz de plataforma tampoco administra directamente ese estado. Accede a él mediante el servicio responsable del workspace y de las decisiones de autorización. Esta frontera permite mantener separados:

• roles humanos y permisos sobre recursos;
• derechos de uso asociados a planes o contratos;
• policy de herramientas durante un run;
• identidad de servicios y trazabilidad hasta la petición original.

Plano de control, ejecución y economía

El catálogo de modelos, las credenciales, la policy comercial, las tarifas y los límites pertenecen al plano de control. La solicitud al modelo y la recepción de tokens pertenecen al plano de ejecución. Una ruta crítica no debería depender de una consulta remota al plano de control por cada fragmento generado; necesita una resolución local, versionada y auditable.

El usuario puede trabajar con alias estables, pero el registro operativo debe conservar proveedor, modelo efectivo, versión de tarifa y motivo de fallback. La resolución vigente aplica una cascada de asignaciones y valores predeterminados entre opciones elegibles. Como objetivo económico todavía en investigación, el routing debería escoger después el modelo elegible de menor coste que satisfaga capacidad, contexto, herramientas, calidad, residencia y policy; no el modelo más barato sin condiciones.

El consumo se registra en un ledger idempotente. Medir, atribuir, mostrar y cobrar son decisiones distintas, y la tarifa efectiva debe conservarse con el evento porque el precio actual no reconstruye el coste histórico. El modelo económico objetivo propone corregir errores mediante movimientos compensatorios; ese contrato general todavía está en transición.

Observabilidad y evaluación

Una respuesta final no explica por sí sola cómo trabajó el agente. La traza debe poder relacionar el run raíz con pasos, herramientas, delegaciones, aprobaciones, uso de modelos, consumo y evaluaciones.

Las evaluaciones se ejecutan sobre la respuesta real del turno y anotan el resultado; no se inyectan como contexto oculto ni alteran la respuesta ya producida. Para afirmar calidad empresarial hacen falta además escenarios representativos, revisión de trayectorias, calibración humana y observación en producción. Un juez basado en un modelo produce una estimación, no una verdad de referencia.

Estado público de los componentes

Área	Estado editorial	Alcance de la afirmación
Agentes declarativos y motor único	Consolidado	Contrato central del runtime
Policy restrictiva de herramientas	Consolidado	Las capas pueden estrechar, no ampliar
Pausa y reanudación por intervención humana	Consolidado	Persistencia del contexto de reanudación
Flujos fusionados en un único run	Consolidado	Diseño definitivo del motor actual
Memoria individual temporal	En evolución	Diseño e implementación por fases
Comunicación entre agentes	En evolución	Contratos centrales presentes; alcance creciente
Sesiones de grupo sobre el chat principal	Consolidado	Una única ruta conversacional con varios participantes
Gestor completo de runs asíncronos	En evolución	Diseño de leases, cancelación y reconciliación
Economía por uso y routing multi-proveedor	Investigación aplicada	Modelo objetivo, no tarifa ni garantía comercial
Memoria colectiva, improvers y eventos	Investigación	Hipótesis con salvaguardas, no disponibilidad

Qué no afirma esta arquitectura

Este documento no certifica seguridad, cumplimiento normativo, durabilidad equivalente a un motor de workflows determinado ni autonomía fiable en todos los dominios. Tampoco convierte una propuesta en capacidad disponible.

La arquitectura pública describe invariantes y fronteras. Los detalles de despliegue, credenciales, rutas internas, cuotas y controles operativos se mantienen fuera de esta edición. Las garantías reales deben demostrarse en la versión desplegada mediante pruebas, auditoría y evidencia operacional.

Referencias

Fuentes editoriales de ALLAN

• Guía de arquitectura del repositorio (AGENTS.md).
• Platform Server/docs/agent-forge-design.md y Platform Server/docs/agent-registry-service-design.md.
• Platform Server/docs/v2-approvals-and-run-manager-design.md.
• Platform Server/docs/agent-communication-design.md y Platform Server/docs/group-sessions-design.md.
• Platform Server/docs/agent-memory-v2-design.md y Platform Server/docs/session-workspace-design.md.
• docs/authz.md, docs/model-provider-management-design.md y Platform Server/docs/metering-and-subscriptions-design.md.

Fuentes externas

• Wooldridge, M. y Jennings, N. R., Intelligent Agents: Theory and Practice, The Knowledge Engineering Review, 1995.
• NIST, Artificial Intelligence Risk Management Framework 1.0, 2023.
• Model Context Protocol, Specification 2025-11-25, especificación estable consultada en 2026.
• A2A Protocol, Specification 1.0.0, especificación consultada en 2026.
• FIPA, ACL Message Structure Specification, estándar de 2002.
• W3C, PROV-O: The PROV Ontology, Recomendación del W3C, 2013.
• Temporal, Workflow Execution, documentación técnica consultada en 2026.
• OpenTelemetry, Generative AI attributes, especificación en desarrollo consultada en 2026.