Más que un modelo
Un agente de RunMyDay es un sistema compuesto por instrucciones versionadas, contexto operativo, memoria, herramientas explícitamente habilitadas y controles de acceso.
La plataforma usa un gateway en Node.js para recibir eventos de canales autorizados, como WhatsApp o Slack, resolver la identidad y la sesión correctas, ensamblar el contexto y coordinar la ejecución de modelos y herramientas.
Qué ocurre en una interacción
- Se identifica el origen. El gateway asocia el evento con una ruta, una cuenta y una sesión válidas antes de construir contexto.
- Se arma un contexto acotado. El agente recibe sus instrucciones, políticas aplicables, memoria pertinente y los datos permitidos para esa solicitud.
- El modelo propone. Puede redactar una respuesta o solicitar una herramienta, pero no amplía por sí mismo sus permisos.
- La plataforma ejecuta. Las herramientas validan entradas, resuelven autorización y operan únicamente dentro de su contrato.
- El resultado vuelve estructurado. El agente interpreta el resultado, registra el estado que corresponda y responde por el canal de origen.
Decisiones que se toman por implementación
La arquitectura común no convierte todos los agentes en copias idénticas. Para cada caso se define qué identidades participan, qué información entra al contexto, qué herramientas se habilitan, qué operaciones son de lectura o escritura y cuáles necesitan aprobación humana.
Glosario mínimo
| Término | Significado en esta arquitectura |
|---|---|
| Gateway | Servicio Node.js que recibe eventos, resuelve rutas y sesiones, arma contexto y coordina la ejecución. Por ejemplo, dirige un mensaje entrante de Slack al agente y a la sesión correspondientes. |
| Runtime | Entorno que combina la definición del agente con una sesión, un modelo y las capacidades habilitadas para procesar una interacción. |
| Workspace | Conjunto versionable de identidad, instrucciones, políticas, habilidades y archivos de trabajo de un agente. |
| Sesión | Unidad que mantiene juntas las interacciones relacionadas y su historial inmediato. Puede corresponder, por ejemplo, a una conversación directa o a un hilo de Slack. |
| Contexto | Información seleccionada que el runtime entrega al modelo para una interacción: mensaje actual, identidad verificada, instrucciones, memoria pertinente y resultados de herramientas, entre otros datos permitidos. |
| Herramienta | Interfaz determinista que valida y ejecuta una operación concreta, como consultar un pedido por su identificador. |
| Integración | Configuración, autorización y contratos que conectan una herramienta con un sistema externo, como un CRM o un calendario. |
| Memoria | Información durable seleccionada para mantener continuidad útil, como una preferencia del usuario o una decisión operativa vigente. |
| Estado estructurado | Datos de tareas y flujos sometidos a reglas más precisas que el texto libre, como el estado y responsable de una solicitud. |
Principios de diseño
Estos principios describen cómo se construye y opera la plataforma. No son alternativas entre sí: se aplican juntos en cada agente.
- Comportamiento versionado
Rol, objetivos, políticas y procedimientos viven como configuración revisable. Cada cambio puede inspeccionarse, validarse y asociarse a una versión concreta.
- Capacidades explícitas
El modelo no obtiene acceso por inferencia. Cada herramienta e integración debe habilitarse de forma expresa para el agente que la necesita.
- Ejecución delimitada
Las tareas operan en entornos aislados y mediante interfaces controladas que acotan procesos, archivos, parámetros y sistemas disponibles.
- Entrega reproducible
Las versiones siguen rutas repetibles de validación, despliegue y verificación de salud, con mecanismos de recuperación cuando corresponde.