Runtime de agentes para trabajo coordinado | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Asistencia para agentes de codificación y operadores. Las métricas de demostración son ilustrativas.

Terminal, búsqueda, lint, pruebas, git y más.

Recuerda tu código base y el contexto del equipo.

Agentes especializados colaboran en distintos ámbitos.

Cada paso se registra con marcas de tiempo.

Las políticas, comprobaciones y pruebas siempre se ejecutan.

Revisa los diffs, solicita cambios, aprobación final.

Reproduce cualquier sesión bit a bit cuando algo necesita revisión.

Leer retry.ts, rastrear el error de tiempo de espera

Agentes autónomos que escriben código y dejan constancia

para manejar tiempos de espera de red, respuestas 5xx y condiciones seguras para operaciones idempotentes. Helper puro, completamente probado.

Entrada, política y razonamiento en un solo artefacto

formado en torno a una tarea, y muestra su trabajo

intención, alcance, contenido, ética, anomalía, tiempo de ejecución

objetivo obj-281 · equipo de 5 especialistas · ciclo 1/1

El tiempo de ejecución para organizaciones ejecutables · un objetivo, un equipo formado, un rastro

decisión de ejecución · retener pago al proveedor v-281

actuar · puerta de aprobación · decisión #4f9e2c

en cola para operaciones, esperando aprobador

firmar · M. Bos, ops-3 · 2026-04-12 09:14 CET

cuenta · rastro de restricciones sellado, reproducible de principio a fin

Base de conocimiento operativa, episódica, semántica y procedimental

agentes, modelos, herramientas, personas

Lleve a Nexus un objetivo que actualmente cruce personas, sistemas, reglas y aprobaciones. Vea cómo se descompone el trabajo, cómo se forma la organización, cómo se asigna la autoridad, cómo se contiene el fallo y cómo cada contribución vuelve a un único resultado responsable.

Canalización, abanico, delegación, pizarra, debate

Dweve Nexus, el runtime para organizaciones ejecutables

Nexus es un runtime multiagente en Python para trabajo que necesita más estructura que un bucle de indicaciones. Su implementación separa agentes, ciclo de vida de tareas, flujos de trabajo, memoria y enrutamiento basado en capacidades en componentes distintos. Los constructores en Python, DweveScript y una CLI definen y ejecutan ese trabajo.

Runtime en Python, componentes distintos

Coincidencia de capacidades, requisitos explícitos

Use los constructores en Python, DweveScript o CLI para definir agentes, tareas y flujos de trabajo para el trabajo que necesita coordinar.

Componentes para el trabajo coordinado de agentes

Constructores de Python, DweveScript y la CLI

De trabajo, episódica, semántica, procedimental y de conocimiento

Deductivo hasta híbrido, seleccionados para la tarea

Dweve Nexus, cada tarea tiene su propio equipo

La mayoría de las herramientas de IA asignan cada trabajo al mismo asistente. Nexus funciona de otro modo. Detrás de Fabric forma un equipo en torno a lo que has pedido, envía cada parte al especialista adecuado y devuelve un único resultado a través de la conversación que ya has abierto. Pides una vez. Nexus organiza todo lo que hay detrás.

Pide una vez. Deja que Nexus forme el equipo, divida el trabajo, reúna las piezas y devuelva un único resultado. La organización trabaja para ti. La autoridad sigue siendo tuya.

Las transferencias tipadas mantienen el runtime coherente. Quien firma el trabajo lee otra cosa.

La implementación actual ofrece constructores de Python para agentes y un compilador de DweveScript para definiciones declarativas de agentes y flujos de trabajo. Su CLI analiza, compila y ejecuta archivos DweveScript. Son interfaces complementarias a la misma implementación de Python, no afirmaciones de clientes equivalentes en Rust, TypeScript o Go. Una definición escrita en uno de ellos es la misma definición cuando se lee desde el otro, por lo que un equipo puede moverse entre el archivo declarativo y el constructor sin mantener dos descripciones de la misma organización.

Junto a los mensajes punto a punto funciona un bus de eventos tipado, que es aquello sobre lo que un grupo de agentes se coordina realmente: solicitudes y resultados de tareas, aceptación y rechazo, reclamaciones y liberaciones, y eventos de ciclo de vida y salud, con suscriptores capaces de filtrar, reenviar, descartar y transformar lo que reciben. Dos tipos de estado se mantienen deliberadamente fuera de los mensajes individuales. Un blackboard es una estructura declarada que los agentes leen y escriben, de modo que una contribución es legible para algo más que quien la escribió.

Eventos y el estado que se pretende compartir

Una transferencia en Nexus es un valor con una forma, no un párrafo que un agente espera que otro analice. La capa de protocolo transporta tipos compatibles con A2A para mensajes, tareas, artefactos, capacidades, habilidades, roles y estados, y JSON es una forma de ponerlos en el cable, no el sistema de tipos en sí. Las herramientas y los sistemas externos llegan mediante contrato, y Model Context Protocol se admite como uno de esos límites donde el cliente lo desea. Un componente receptor puede validar esa forma antes de actuar, y el rastro mantiene la transferencia inspeccionable. JSON es una elección de transporte; no sustituye al contrato.

Replay responde a qué ocurrió. Lo que las partes se entregan está tipado con la misma precisión.

Nexus tiene componentes separados para enrutamiento, ejecución de flujos de trabajo, comunicación, razonamiento, memoria, seguridad y recuperación. Esa separación permite inspeccionar el componente relevante cuando el trabajo se comporta de forma inesperada, en lugar de tratar cada fallo como un problema de prompt. Cada componente registra lo que decidió en el momento en que lo decidió, de modo que la pregunta tras un incidente es qué componente cambió, no qué frase estaba mal redactada. Ese registro es lo que un replay lee.

El replay capturado reutiliza las salidas registradas de cada llamada externa y reconstruye la ejecución original, lo que prueba las propias decisiones del runtime con el mundo exterior inmóvil. El replay en vivo vuelve a llamar a las dependencias y compara, que es la prueba que puede fallar y, por tanto, la que merece la pena ejecutar. El replay capturado responde si el runtime tomó las mismas decisiones con el mundo exterior inmóvil. El replay en vivo responde si las dependencias actuales siguen produciendo el mismo resultado. La comparación es, por tanto, una prueba del entorno, no una segunda copia de la historia.

Todo eso puede verse en vivo. Lo que el runtime decide por sí mismo se resuelve antes de ejecutarse.

Los eventos estructurados se emiten por entidad, y el despliegue decide qué almacén los recibe: memoria limitada en un entorno de desarrollo, un almacén persistente en producción y almacenamiento de solo añadido o a prueba de manipulación cuando el registro debe resistir a alguien externo. Cada uno se llama por lo que es. El runtime no llama inmutables a los registros mutables ordinarios, que es la diferencia entre una evidencia que alguien acepta y una afirmación que ponen a prueba. Los eventos conservan su entidad y su postura de almacenamiento.

Los tipos de entidad admiten preguntas distintas, y la asimetría es la parte útil. Preguntar a un agente cómo de sano está tiene sentido, y preguntarle lo mismo a una operación no lo tiene, porque una operación está bloqueada o no lo está, y su salud es solo la salud de quien está dentro de ella. Una unidad de trabajo tiene una fecha límite y un contador de reintentos, y un grupo no tiene ninguna de las dos: lo que tiene un grupo es una membresía y un registro de en qué ha trabajado. Como no coinciden dos de esos conjuntos, un único flujo plano de líneas responde mal a las cuatro.

Una pregunta de producción rara vez es lo que dijo un registro. Es qué unidad de trabajo incumplió su fecha límite, qué agente no está sano, qué parte de la operación está bloqueada y por qué. Nexus informa del estado sobre las mismas cosas que ejecuta, así que la pregunta va a quien tiene la respuesta en lugar de ensamblarse a partir de líneas que casualmente la mencionan. Eso hace que la pregunta sea abordable sin reproducir una conversación. El estado pertenece a la entidad que posee el trabajo, así que una fecha límite incumplida, un agente no sano o una operación bloqueada pueden investigarse a partir de su registro y su condición actual.

La recuperación es algo de lo que te informan. Observarla mientras se ejecuta es una exigencia distinta.

Dos consecuencias que un ingeniero puede aprovechar. Como la espera es un punto fijo determinista calculado a partir del número de intento y no un sorteo de una fuente aleatoria, el programa de una ejecución fallida forma parte de lo que se reproduce, así que una discusión sobre cuánto tardó ayer tiene una respuesta en lugar de una teoría. Y como el circuito pertenece al agente y no al tipo de trabajo, una dependencia que falla deja de enrutar a un lugar mientras el mismo trabajo sigue siendo enrutable en cualquier otro sitio. Cada sustitución se anota a medida que ocurre: el redireccionamiento nombra al agente de reemplazo y al estado que viajó con él, así que una ejecución rescatada se lee después como una única pieza de trabajo con una recuperación dentro.