Explorar el diseño del Super-agent: hacia un sistema de agentes más autónomo

1. Super-agent

En el último año, los agentes de tarea única — los coding agents a la cabeza — demostraron que los modelos saben usar herramientas para resolver problemas complejos, con cada vez menos monitoreo humano continuo e intervención paso a paso. A la vez, la capacidad de coordinar varios agentes mejora, volviendo viable la organización y el despacho entre sesiones. A medida que la participación humana en la ejecución se reduce, el rol de la persona sube hacia decisiones y aceptaciones de más alto nivel.

Ese salto de capacidad engendró nuevas formas de aplicación. Recientemente han brotado los agentes personales: conectados a la mensajería, la agenda, el correo y las plataformas de trabajo, observan el flujo de información y ayudan a gestionar asuntos. Este modo de trabajo permanentemente en línea y dirigido por eventos no se limita al escenario personal — el asistente personal es solo una clase de aplicación; en escenarios comerciales como el desarrollo de software vale igual.

Sin embargo, los diseños dominantes apenas sostienen este modo a escala de multitarerea y colaboración. El trabajo del agente sigue organizado en la sesión única; las sesiones son independientes entre sí. Quien avanza varios frentes en paralelo debe cambiar a mano y memorizar el contexto de cada una — y, según la observación del equipo, una persona sigue en la práctica de 3 a 5 sesiones activas. En este diseño, el techo de la tarea única es la capacidad del modelo; el de la multitarerea, la atención humana.

Extender un agente local monosesión con CLI, MCP o conectores externos le permite recibir mensajes, pero sigue atado al bloqueo síncrono de la sesión única, al contexto multitarea embrollado y a que el aparato desconectado detiene todo — con mucho mantenimiento manual.

Para romper estos límites hay que desatar al agente de su vinculación con la sesión manual única y hacerlo una entidad continua que conserva el contexto entre sesiones y adelanta varias tareas complejas en paralelo sin estorbarse. El equipo llama a esta forma — y a su arquitectura — Super-agent.

En la instancia interna sobre DeepSeek Harness, una misma tarea de desarrollo avanza sin cortes entre la mensajería y GitHub; la instancia además vigila los comentarios de los grupos públicos y, sin que nadie la mencione, localiza la causa raíz y abre un pull request de corrección.

Concretamente, el Super-agent tiene cuatro propiedades fundacionales:

• Continuo: el usuario interactúa en sus superficies habituales — chats, comentarios en GitHub — y siente un único agente siempre presente, sin preguntarse «¿el dato Y estaba en el contexto de la sesión X?». Puede proponer el plan A por mensajería y pasar al B en un comentario de PR, y el agente entiende y ajusta el rumbo.
• Eficiente: interacción rápida mientras varias tareas complejas avanzan en paralelo y con calidad; acepta la siguiente instrucción sin esperar el fin de la anterior.
• Proactivo: no espera instrucciones una a una; observa los eventos del entorno y adelanta lo que vale la pena, callado cuando no hace falta intervenir.
• Persistente: siempre en línea, enchufado a los entornos reales de trabajo, con auto-recuperación ante anomalías en la marcha larga.

Un único ReAct loop no sostiene las cuatro a la vez; hace falta arquitectura por debajo. Restricciones parecidas conducen a elecciones parecidas: asistente personal o agente comercial de desarrollo, un sistema permanentemente en línea y concurrente sobre eventos convergerá en cimientos semejantes. Y muchos de los problemas aquí se parecen mucho a los clásicos de los sistemas distribuidos, de modo que el pensamiento sistémico clásico aplica directo.

La implementación tiene variantes, pero cinco módulos forman el esqueleto: la arquitectura de dos niveles (§2) para continuidad y eficiencia; el diseño dirigido por eventos (§3) para la proactividad; la interacción orientada al humano (§4) continua y eficiente en la interfaz misma; la separación de cómputo, estado y entorno (§5) más un Watchdog (§6) para la persistencia entre dispositivos y la autocuración.

2. La arquitectura de dos niveles

Para lograr a la vez interacción continua entre canales y concurrencia multitarea eficiente, la organización de sesiones afronta una disyuntiva radical entre continuidad y rendimiento.

Todo a una sesión: contexto continuo al máximo, pero la velocidad serial del ReAct loop pone techo — tiempos largos, rendimiento bajo, y los detalles intermedios de varias tareas revueltos dañan la calidad.

Una sesión nueva por evento: concurrencia máxima, pero si las tareas no son del todo independientes, la falta de contexto global hace trizas los resultados, y varias sesiones contestando cada cual por su cuenta siembran caos.

Para equilibrar, se separan «mantener la continuidad global» y «ejecutar en alta concurrencia» en dos niveles: un nivel Router residente (2.1) que recibe toda la interacción humana y la coordinación global, y un nivel Worker de contexto aislado (2.2) que ejecuta tareas en concurrencia.

Con esta partición, el sistema asume abajo la gestión del contexto y la ejecución concurrente, desdibujando la sesión ante el usuario, que tiene siempre delante un solo Super-agent. Visto así, hacer que el usuario gestione sesiones a mano es en gran parte inercia heredada de la API del LLM; la sesión es detalle de implementación, no carga cognitiva.

«Dos niveles» es una división lógica de responsabilidades; ningún nivel se reduce a una sesión única y cada cual puede tener estructura interna. Van los niveles.

2.1 El nivel Router

El Router es el nivel residente de enrutamiento global que recibe toda interacción humana en todos los puntos de entrada. Toda la información y decisiones entre tareas confluyen aquí: punto de secuencia global, punto de coordinación y memoria. Para no volverse cuello de botella, el Router no ejecuta tareas — solo interacción y reparto; puede hasta prescindir de la herramienta Bash.

Un despachador central sobre varios ejecutores se parece en superficie a un Agent Team, pero el énfasis difiere. El Agent Team descompone pasos dentro de una tarea compleja; los subpasos van acoplados, el lead debe entender el detalle, planear y coordinar sin tregua — carga de razonamiento pesada. En el Super-agent, el Router solo trata vínculos de alto nivel entre tareas y el reparto. A la inversa, restringir por prompt la sesión principal de un Agent Team a no ejecutar nunca — solo interfaz externa y reparto — también produce esta arquitectura. En la práctica, las tareas del Router suelen ser menos complejas de lo pensado, y un modelo ligero equilibra velocidad y calidad.

Tampoco dentro debe el Router ser una sesión única; partes de su lógica quizá no llamen a ningún LLM. El equipo eligió el núcleo más directo — una sesión LLM residente — y halló que se atasca mucho menos de lo que aparenta: los eventos (los Trigger de la §3) llegados durante una ronda de inferencia se acumulan y se procesan juntos en la siguiente, formando el batching, de sobrecosto pequeño:

• Con el flujo tranquilo, los Trigger entran de uno en uno y la latencia unitaria se mantiene baja.
• Cuando los eventos se agolpan y la sesión hace cola, los Trigger acumulados se fusionan solos y se inyectan juntos en la siguiente llamada. Los pasos del Router son típicamente entrada larga, salida corta; fusionar en una llamada paraleliza el prefill y la latencia por petición crece mucho más despacio que el lote. En cierto rango, cuanto mayor el represamiento, menor el tiempo de inferencia por decisión — con tope en la longitud de contexto y en cuántos Trigger procesa el modelo con exactitud por ronda.

La §7.2 cuantifica el batching. Sumados la suscripción/pass-through y la cadena de recuerdo (3.2, 3.3), una única sesión Router residente alcanza a la escala actual del equipo.

Más allá, el Router puede estructurarse en filtros de varias capas o sharding horizontal en varias sesiones. El diseño interno del Router se vuelve él mismo la disyuntiva continuidad/rendimiento: shards más finos, más concurrencia, menos continuidad de memoria entre fragmentos. Hasta resolver la memoria global, la disyuntiva sigue.

2.2 El nivel Worker

Los Worker son las sesiones de ejecución: contexto mutuamente aislado, herramientas completas, foco en una sola tarea. Como deciden resultado y calidad del código, suelen querer el modelo más capaz.

Los Worker no hablan con humanos; su razonamiento y llamadas no salen a los canales externos. Reportan al Router, que responde al usuario unificadamente — concurrencia y calidad sin el caos de respuestas múltiples.

En multitarerea, los Worker avanzan independientes y normalmente no se hablan entre sí. Los conflictos surgen sobre todo en entornos compartidos, el mismo PR por ejemplo; mientras ambos estén suscritos al mismo Thread (3.2) reciben los mismos eventos y pueden descubrir y resolver el conflicto solos, con el Router retransmitiendo las raras coordinaciones cruzadas.

Como el Router, un Worker puede no ser una sesión única por dentro: en una tarea compleja puede engendrar subagentes o ser él mismo un Agent Team, en transparencia hacia arriba. Sirve a la colaboración de código — reproducciones, revisiones y features en paralelo sin bloquearse — y al asistente personal: una sola ventana de chat que, con varios temas, mantiene la continuidad arriba mientras abajo asigna un Worker por tema, avanzando en paralelo y borrando respuestas.

3. Dirigido por eventos

La proactividad empieza cambiando lo que impulsa el sistema. La entrada principal ya no son prompts tecleados por el humano en sesión, sino eventos semiestructurados del entorno. Mensajes de grupo, recordatorios de correo y agenda, comentarios de revisión, resultados de CI: todo eso son Trigger. Escuchando y respondiendo Trigger, el agente ya no ejecuta una vez por orden como en monosesión.

En torno al ciclo de vida de un evento, cuatro preguntas progresivas: filtrar el ruido con una política de dos niveles programa+modelo (3.1); enrutar hacia los worker por suscripción y pass-through (3.2); inyectar y traer contexto en alta densidad con Inline & Spill y la cadena de recuerdo (3.3); y adelantarse con la ejecución especulativa (3.4).

3.1 Filtrado de eventos

Conectados a chats y plataformas reales, los flujos son vistosamente «mucho ruido, poca tasa de disparo»: la gran mayoría de mensajes no requiere al agente. Juzgar cada evento con llamada fresca al modelo arruina latencia y costo. Del Fast Path / Slow Path de los sistemas: la inferencia LLM es una Slow Path flexible pero cara; fijar en código determinista los juicios claros, estables y frecuentes forma una Fast Path barata.

Primer paso tras la entrada: filtrar — colar el ruido con política determinista antes de toda llamada, pasando al modelo solo los candidatos que exigen semántica. Filtro de dos niveles:

• Política de programa (Fast Path): admisión determinista en código — fuente, perímetro de grupo, listas blancas de usuarios/bots; por fuente, p. ej., «responder solo a peticiones explícitas», «candidato» o «ignorar» — la mayor parte de lo irrelevante cae antes del modelo.
• Política semántica (Slow Path): los candidatos pasan al LLM, que decide actuar o no según políticas escritas en prompt y contexto. La capa semántica es además el punto de extensión en lenguaje natural: activar o añadir política es editar un prompt.

3.2 Enrutamiento de eventos

El Router sostiene la continuidad entre canales, pero si cada evento posterior de una tarea ya asignada pasara por él, el nodo global cargaría mucho y la latencia subiría. Fast/Slow aplica también al enrutamiento: el Router solo atiende arranques en frío de tareas nuevas y coordinación entre tareas; los eventos posteriores de dueño conocido los envía el programa directo a la sesión worker.

En flujos reales, los eventos consecutivos bajo un mismo PR, un mismo tema de mensajería o un mismo hilo de correo forman un flujo — un Thread. Creada una sesión worker para el evento inicial de un Thread, el worker se suscribe al Thread, y el enrutamiento se bifurca:

• Suscrito (Fast Path): los eventos siguientes del mismo Thread van directos al worker suscrito, sin reenvío del Router. Si un evento excede el alcance de la tarea, el worker puede desuscribirse o devolverla al Router.
• No suscrito (Slow Path): el Router sigue observándolo todo para la visión global, pero solo juzga y reparte lo aún sin suscripción.

La suscripción Thread-worker es muchos-a-muchos: un worker sigue varios Thread relacionados; un Thread, varios worker. Cuando varios worker se cruzan en un mismo entorno, los nuevos eventos llegan a todos los suscritos, que se enteran de las acciones ajenas y resuelven conflictos sin mensajes punto a punto. En salida, los worker elevan las conclusiones al Router, que responde unificado y actualiza la memoria global.

3.3 Organización del contexto

Filtrado y enrutado el evento, queda cuánto inyectar en la ventana. La entrada pasó de prompts humanos acotados a un flujo incesante de eventos semiestructurados: el diseño de inyección y llamadas pesa más. Inyectar de más llena la ventana y diluye la atención; de menos, multiplica los recorridos de lectura. Desperdiciar la ventana de contexto es desperdiciar la inteligencia del modelo.

Gestiónese la ventana finita como caché. De la optimización de compiladores y los sistemas, dos operaciones bastan: Inline sube a la ventana lo que pronto hará falta, ahorrando recorridos de herramientas; Spill deja fuera la información completa que excede presupuesto o es de uso raro, guardando dentro solo referencia o resumen para leer a demanda.

Con la localidad clásica:

1. Empezar al mínimo: solo ID del objeto y resumen del contenido.
2. Inline por localidad: primero los ID de objetos estrechamente ligados, luego lo contiguo en tiempo y espacio — los primeros 50 caracteres, los mensajes vecinos y el respondido, los comentarios vecinos del hilo de revisión.
3. Spill sobre el tope: techo pequeño de longitud para lo no inlinable entero; el exceso sale de la ventana con un punto de reanudación que el modelo leerá con herramienta.

Con tantos eventos pasando directos a los worker y un sistema que acumula historia en la marcha larga, el Router no puede traer toda la historia de todas las tareas a su ventana, pero debe recuperar el contexto cuando el usuario retoma una tarea vieja por otro canal. Aplicar Inline & Spill parejamente a los objetos del sistema da la recuperación multihop a demanda — la cadena de recuerdo —, que mitiga la pérdida de información lejana del Router.

En concreto: Trigger, Thread y sesiones worker reciben ID únicos, y las inyecciones inlinean los ID de los objetos estrechamente ligados, formando abajo un grafo de referencias. Como todo objeto recuperado por herramienta sigue Inline & Spill, su resultado trae resumen e ID del siguiente salto: del mensaje actual se lee el Thread, del Thread se sigue hasta la sesión worker ligada, y de allí al otro Thread de revisión.

3.4 Adelantarse

Con la ejecución especulativa de los sistemas, el agente puede intentarlo en segundo plano antes de saber si el resultado servirá: cómputo extra detrás para recortar espera e intervención humanas. Lo valioso se entrega; lo que no, se descarta.

Asistente personal: llegada una invitación o tarea, el agente revisa en segundo plano conflictos de agenda, reúne antecedentes y prepara el borrador de respuesta — el usuario vistea y envía. Ingeniería: en el grupo interno de usuarios de DeepSeek Harness corre la política «reproducir y corregir en silencio» — cuando alguien reporta un problema o discute un cambio, el agente reproduce y busca el arreglo en segundo plano; entrega solo con problema confirmado y arreglo simple; si no, calla de principio a fin.

4. Interacción orientada al humano

El dos niveles asegura continuidad a nivel de contexto; para serlo también en la experiencia quedan dos problemas: quitar el bloqueo de operaciones largas con un ReAct loop asíncrono (4.1) y adecuar la salida al ancho de banda y las costumbres de cada canal (4.2).

4.1 Interacción full-duplex

En el ReAct clásico, una llamada síncrona run() bloquea el loop hasta que la herramienta devuelve, y la sesión no responde nada nuevo mientras tanto. Quitar el bloqueo es pasar del half-duplex pregunta-respuesta al full duplex.

El equipo volvió asíncronos los comandos y subtareas largas con start() y stop() — el ReAct loop asíncrono. start() devuelve en el acto «Started» y el loop no espera; al acabar la herramienta, el sistema deposita el resultado en la sesión como evento nuevo; y el modelo puede stop() comandos que se eternizan.

Diálogo en primer plano y ejecución en el fondo se desacoplan: el agente responde mientras las tareas largas corren. La entrada nueva se procesa justo tras el paso de inferencia en curso, nunca detrás de una herramienta pendiente. Implementado en DeepSeek Harness, aún sin activar por defecto.

4.2 Interacción multicanal

Los canales difieren en densidad y costumbres; la salida debe acomodarse. Trasplantar la interacción de terminal única al grupo — razonamiento verboso y ráfagas de llamadas en crudo — satura la colaboración.

El dos niveles ya aísla buena parte: razonamiento y llamadas quedan dentro de los worker; el Router solo habla afuera. Encima, el sistema se enchufa a los entornos reales y calibra normas por canal vía prompt:

• Mensajería instantánea: trato ligero y poco intrusivo — como el colega que avisa solo para decidir o aceptar, pregunta directo y responde corto. Regla dura simple y validada: máximo 100 palabras por respuesta.
• GitHub, correo, documentos (canales asíncronos): entregas estructuradas y densas — PR escritos a norma con contexto, descripción y verificación; para el asistente, borradores de correo y resúmenes estructurados.

5. Separar cómputo, estado y entorno

Los agentes locales ligan por defecto a un aparato el cómputo que empuja el loop, el estado de sesión a persistir, y el entorno de ejecución — repos y cadenas de herramientas. El aparato duerme o se desconecta, el agente se detiene, y los entornos de otras máquinas quedan fuera. Para la permanencia y el acceso flexible se toma la separación cómputo-almacenamiento en dos pasos: separar el cómputo del loop del estado persistente, librándolo del ciclo de vida de la máquina única (5.1); luego separar el loop nube del entorno pesado, dejando los entornos reales en su sitio con acceso entre dispositivos (5.2).

5.1 Cómputo y estado

El cómputo del loop puede no tener estado; lo persistente es el estado de sesión. Primera separación: cómputo en contenedores elásticos nube sin estado, sesiones en base de datos. Los contenedores escalan, reinician y se reemplazan; el almacenamiento persistente garantiza la continuidad — el agente escapa al ciclo de vida de una máquina.

5.2 Cómputo y entorno de ejecución

Loop y estado en la nube, queda el acceso a los entornos. Buena parte del contexto que el modelo necesita llega por herramientas desde repos, archivos locales y servicios — en sentido amplio, el entorno mismo es contexto.

Dos caminos comunes: sandbox en la nube que baja el código e intenta reconstruir y sincronizar el entorno — caro y propenso a omisiones, porque los entornos reales cargan cambios sin commit, credenciales privadas, dependencias de intranet y hardware o cadenas específicas; o pedirle al usuario abandonar lo local por la nube — migración demasiado cara para muchos.

Si lo incopiable es el entorno mismo, no lo subamos a la nube. Segunda separación: el loop corre en la nube, el entorno pesado se queda donde está, y en el extremo vive solo un daemon ligero, sin estado de sesión, que ejecuta comandos y devuelve resultados — el entorno fuera de la nube, leído por el agente a demanda.

Eso espeja el «desacoplar el cerebro de las manos» de Anthropic: harness sin estado, registros de sesión afuera, entornos enchufados por interfaz unificada. Difiere el escenario — aquel texto describe servicios administrados, sandbox a demanda y recursos en el VPC del cliente; aquí lo primero es enchufar las máquinas personales de uso diario, quizá intermitentemente en línea, con cambios sin commit y credenciales locales. De ahí el soporte a BYOM (Bring Your Own Machine), además de máquinas administradas y cómputo a demanda.

El agente deja de estar atado a una máquina: elige dispositivo de ejecución por tarea, ordena donde hace falta y de allí saca el contexto. Aguanta hasta aparatos intermitentes: cuando la máquina personal vuelve, el agente en la nube dispara y completa lo que tocaba correr allí.

6. Watchdog

A la separación se suma la curación: un sistema de larga marcha difícilmente se sostiene solo con su lógica interna; hace falta un lazo de control externo — el Control Loop.

Y en sistemas de agentes no bastan sondas de proceso ni scripts: muchas anomalías no son caídas sino bucles inútiles o desvíos del modelo. Un sistema de larga marcha vigila la vida de la infraestructura y el avance de las tareas.

Fuera del sistema principal corre una Watchdog Session independiente, impulsada por mensajes temporizados. Trata fallos de infraestructura — errores de API, recuperaciones fallidas — y encarga al modelo juzgar si cada worker progresa de verdad y si el rumbo sigue fiel al objetivo; interviene y repara al detectar anomalía, y reexamina los fallos pasajeros hasta que pasan. Siendo ella misma una sesión de agente con herramientas completas, se le puede preguntar en natural por qué falló algo, o hacerle retocar en vivo el sistema principal — prompts añadidos o quitados, reglas de disparo ajustadas.

7. Experimentos preliminares

Para evaluar la orquestación y el enrutamiento núcleo, dos capas de experimentos: punta a punta comparando dos niveles con suscripción/pass-through contra esquemas monosesión (7.1); y un estrés aparte del batching del Router (7.2). Cargas sintéticas y entornos simplificados: resultados preliminares.

7.1 Ablación

Flujos de chat grupal y CI GitHub impulsan cuatro esquemas: ~300 mensajes por corrida, ~20 peticiones de trabajo, el resto charla, seguimientos, cancelaciones y CI. El trabajo de código se sustituye por una herramienta que solo gasta tiempo: se mide orquestación y coordinación, no la ejecución de la tarea única. Cinco corridas por esquema.

Los cuatro: el Super-agent; el Super-agent sin pass-through; y la sesión única + herramienta subagent bajo dos prompts. Neutro: "Use a subagent for a piece of work when appropriate...". Delegar-primero: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

Tiempos de término: p50 y p95 del Super-agent en 12,4 y 15,7 minutos, netamente sobre la monosesión con subagent. Ésta es muy sensible al prompt: la sesión principal suele ejecutar ella misma — tiempos largos e inestables. Con el neutro, ni una llamada al subagent en 5 corridas: todo en la principal, interrumpido sin parar, p95 en 29,5 minutos. Con delegar-primero delega en 4 de 5 — mejor, aún bajo el Super-agent — y en la quinta juzga el trabajo «pequeño», lo hace sola y forma la cola violeta del gráfico. Antes que confiar el reparto del trabajo a la ingeniería de prompts y al tino del modelo, el dos niveles lo zanja estructuralmente: el Router nunca ejecuta; los worker solo reciben los mensajes de su Thread suscrito.

Costos: mantener varias sesiones encarece los tokens de lectura en caché por corrida frente a la monosesión — más tokens por tiempos más cortos y estables. Sin pass-through, los tiempos quedan casi iguales, pero las decisiones del Router suben ~30% y los tokens de caché pasan de 23,23M a 31,77M (+37%). Bajo esta carga el pass-through no mejora calidad ni velocidad: ahorra al Router tokens e inferencia considerables.

7.2 Batching del Router

Para sondear el techo de la sesión Router residente, estrés dedicado: modelo real en el Router, mock en los worker, subiendo la tasa de llegada de Trigger a decidir de ~1 a ~40 por minuto, observando lote medio, latencia por petición e inferencia por decisión.

De ~1 a ~40 por minuto, el lote medio va de 1,0 a 2,8 mientras la latencia solo sube de 2,5s a 3,9s — más despacio que el lote —, y la inferencia por decisión baja de 6,4s a 1,6s. Ante ráfagas, el Router alza el rendimiento efectivo fundiendo el represado. Explica también que en 7.1, sin pass-through y con el pico de carga en el Router, el techo nunca se tocara — de ahí no shardar a destiempo sacrificando la continuidad del contexto global.

8. Preguntas abiertas

Las §2–6 forman la base; la §7 validó orquestación y enrutamiento bajo carga. El sistema sigue simple gracias a simplificaciones deliberadas. Más allá quedan: escalar el dos niveles (8.1), colaborar tras las sesiones (8.2), fronteras de contexto y A2A (8.3), seguridad y privacidad (8.4).

8.1 Escalar el dos niveles

«Un Router residente + pass-through + worker sin comunicación directa» cubre la mayoría del día a día a bajo costo. Pasado el umbral no hay doctrina para el interior: cuándo shardar y con qué grano; cuándo dar voz directa a los worker y con qué topología. El codesign sistema-modelo es otra veta: entrenar a medida la discriminación de eventos, el reparto por lotes y la recuperación de contexto del Router podría subir rendimiento y calidad de decisión.

Y el Router residente con cadena de recuerdo resuelve sobre todo el recuperar lo reciente. A meses vista, la memoria de largo alcance se vuelve el cuello de la escalabilidad.

8.2 Colaborar tras las sesiones

Ocultada la gestión multisesión, la sesión dejó de ser la cuestión primera del producto; pero cuando las sesiones de ejecución ya no corresponden a las conversaciones visibles, cómo presentar tareas y ofrecer interacción y gestión naturales es la pregunta nueva. La centralidad de la ventana de chat es en parte dependencia del camino. La interacción puede irse a superficies especializadas — como en los ejemplos, el Super-agent trabajando directo en issues y pull requests. La sesión puede quedarse por costumbre, pero una conversación vista no equivale abajo a una sola sesión.

Y el texto trató al humano al inicio y a la aceptación; en el tránsito, muchas tareas aún requieren participación intermedia — entrar, tomar el mando o colaborar en vivo con la ejecución de fondo: todo por explorar. La forma final de gestión e interacción será con probabilidad muy hecha a la medida del dominio y del estilo; la arquitectura abierta de DeepSeek Harness la facilita.

8.3 Fronteras de contexto y A2A

El texto versó sobre una instancia, suponiendo que todo su perímetro confluye en un contexto global. Del individuo al equipo chico a la organización mayor, decidir cuántas instancias tener es trazar las fronteras de compartir y aislar contexto: quien comparte, comparte instancia; quien aísla, instancia propia.

Y con varias instancias aisladas — los asistentes personales junto al Super-agent del equipo —, la cooperación fronteriza pasa a ser comunicación entre agentes (A2A, sin protocolo fijo). Lograr A2A seguro y fiable entre partes que no comparten contexto y representan permisos distintos sigue abierto.

8.4 Seguridad y privacidad

El diseño por eventos amplía quién puede impulsar al agente — y la exposición a entradas no confiables. Sin buenas respuestas de seguridad y privacidad, el Super-agent solo funciona en un recinto pequeño y de confianza.

La §5 — loop en la nube, daemon ligeros en los aparatos — presupone confianza mutua. Pero un loop que ingiere eventos externos sin parar, enganchado a máquinas con código privado, datos sensibles y credenciales locales, introduce riesgos reales: una vulneración del lado servidor o una inyección de prompt en el loop pondría en jaque el control de todos los aparatos conectados.

Y aun sin vulneración, mientras las credenciales entren al contexto del modelo, la fuga acecha en la operación normal; se necesitan mecanismos para usar credenciales sin tocarlas jamás. Para un alcance amplio, la arquitectura debe traer contexto de entornos diversos y resolver a la vez estos problemas.

9. Conclusión

En retrospectiva, el equipo no propuso teoría nueva: aplicó la ingeniería clásica de sistemas a construir agentes. Las implementaciones evolucionarán; el pensamiento de diseño conservará valor de referencia. La instancia interna construida sobre estas ideas y DeepSeek Harness sigue corriendo, participando a diario en reproducir y corregir, responder revisiones e iterar el propio Harness.

Como se dijo al abrir: a medida que el modelo exige menos intervención por tarea, el cuello de la productividad se muda a la atención humana. Con el dos niveles, el diseño por eventos, la interacción asíncrona multicanal, la separación cómputo-almacenamiento y el Watchdog externo, el sistema se hace cargo abajo de la tediosa gestión de sesiones y sincronización de contextos, y el humano sube a decidir y aceptar.

En esta forma, el agente ya no es la ventana que espera órdenes, sino un colaborador autónomo permanentemente en línea en el entorno digital: para las personas, un asistente entre dispositivos; para los equipos, un integrante del flujo de desarrollo que toma y empuja tareas concretas. Con la capacidad del modelo y la arquitectura avanzando juntas, esta manera más autónoma de trabajar puede volverse la norma de la colaboración humano-máquina.

Como el original: parte del diseño vive en dsh-superagent-prototype; el plugin es un prototipo para validar la ruta, no un producto oficial de DeepSeek. Autoría y gracias: el texto nace de la práctica compartida del equipo DeepSeek Harness; Yujia Qiao realizó el sistema y el texto, con Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang y F. Zhou en la revisión y el debate.

Fuentes

• DeepSeek 产品部 (WeChat oficial) — el texto original chino, 1 nov 2026
• deepseek-ai/dsh-superagent-prototype — el prototipo MIT (README, docs 000–008)
• Referencias internas: traducción inglesa íntegra · original chino · cobertura de dsh-superagent