--- title: "Breve historia de los agentes de sesión única · Blog de Comma" description: "Una sesión principal persistente, Workers independientes y la ingeniería de una conversación para todo el equipo." url: https://comma.surf/es/blog/a-brief-history-of-single-session-agents language: es --- [Volver al blog](https://comma.surf/es/blog) Comma Team · 1 de noviembre de 2026 · 7 min de lectura # Breve historia de los agentes de sesión única Una sesión principal persistente, Workers independientes y la ingeniería de una conversación para todo el equipo. [Empezar](https://app.comma.surf/) Imagina un equipo con cuarenta conversaciones abiertas. En una, alguien pide a un agente que prepare una propuesta para un cliente. En otra, una compañera solicita una estimación de entrega. Una tercera persona comprueba si esa misma función puede salir este mes. Cada conversación empieza con una explicación. Este es el cliente. Esto es lo que prometimos. Esto es lo que decidimos ayer. Los agentes se ponen a trabajar, pero cada uno ve una parte distinta. Al final, alguien descubre que la propuesta promete una fecha que la conversación de ingeniería ya había descartado. Entonces termina una Task. Su conversación se queda en silencio. Una semana después, otra persona empieza un trabajo relacionado y vuelve a explicar los antecedentes. Al construir nuestros agentes, volvíamos una y otra vez a esta escena. Queríamos que el siguiente trabajo partiera de lo que el equipo ya había aprendido. Eso nos llevó a un diseño de sesión única: una conversación principal persistente, con Workers independientes que ejecutan las distintas Tasks. Los subagentes ayudan a repartir el trabajo. La sesión única responde a otra pregunta: ¿dónde vive, con el tiempo, la comprensión de ese trabajo? Usamos ambas ideas. La conversación principal da continuidad al equipo; los Workers dan espacio a cada trabajo para avanzar. ## De una persona a un canal y a un equipo [Poke](https://www.webwire.com/ViewPressRel.asp?aId=343533) dio al agente personal un hogar sencillo: una persona, una conversación (septiembre de 2025). Conectaba el correo, el calendario y los archivos de una persona con una conversación de texto. Pedir un borrador de respuesta o cambiar una reunión podía empezar en el mismo lugar que la petición anterior. A lo largo del día, esa conversación se convertía en un lugar al que volver. La relación personal era el centro de la experiencia y nos dio un ejemplo concreto de continuidad entre trabajos distintos. [Claude Tag](https://www.anthropic.com/news/introducing-claude-tag) llevó un Claude a un canal (23 de junio de 2026). Cualquiera podía mencionar al mismo agente, ver su trabajo y continuar donde lo había dejado un compañero. Claude recordaba información relevante con el tiempo y utilizaba las herramientas que habilitaban los administradores. El anuncio también describía el aprendizaje a partir de otros canales y fuentes, cuando estaba permitido. Nos interesaba la conversación compartida: las personas podían delegar trabajo allí donde ya lo discutían. Nuestro diseño toma la conversación principal del equipo como punto de retorno para las distintas discusiones y Tasks que la alimentan. Elegimos explorar un equipo, una conversación. El alcance sigue el trabajo del equipo entre discusiones. Una decisión sobre la entrega puede informar la propuesta, aunque esos trabajos empezaran en lugares distintos. De conversaciones personales y canales compartidos a la conversación principal del equipo. El 28 de abril de 2026 publicamos nuestro primer [artículo relacionado con Bridge](https://bridge.surf/blog/introducing-bridge), nuestro producto anterior. Esa parte de nuestra exploración vino después de Poke y antes de Claude Tag. Continuamos el trabajo en nuestro producto actual, Comma (1 de octubre de 2026), donde hoy funciona este diseño. DeepSeek Harness presentó otra exploración el 31 de octubre de 2026: [Super-agent](https://www.straitstimes.com/asia/east-asia/deepseek-drops-enhanced-coding-agent-with-aim-to-rival-anthropic). Su trabajo proactivo en chats de grupo apunta en la misma dirección: trasladar la coordinación de las personas al sistema. El prototipo de investigación sigue su propio diseño. El [artículo de diseño de DeepSeek, §8.4](https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg), deja abiertas dos cuestiones: una intrusión en la nube o una inyección de instrucciones que comprometa dispositivos conectados, y la filtración de credenciales a través del contexto del modelo. Nuestra respuesta en funcionamiento para el contenido es IFC: declarar fuentes, comprobar los lectores del destino, rechazar envíos no permitidos y solicitar autorización humana acotada cuando haga falta. Las credenciales siguen otra vía. El modelo indica una referencia; la capa de ejecución resuelve e inyecta su valor sin devolvérselo al modelo. ## Lo que conserva el equipo Pensemos en una nueva compañera que se incorpora a la propuesta. Entra en la misma conversación principal que utiliza el equipo. Puede ver las decisiones compartidas, preguntar por qué cambió una fecha y seguir el trabajo sin pedir tres resúmenes a tres personas. Ser miembro del espacio de trabajo le da acceso a esa conversación; el acceso al material detrás de una decisión sigue sujeto a los permisos de ese material. Una Task terminada conserva su resultado y su historial. Quizá el equipo descubrió que un cliente necesita un formato de exportación poco habitual. El informe vuelve al Router y una propuesta posterior puede consultar ese hallazgo y su fuente. La Task termina, pero el equipo conserva un lugar al que volver para recuperar lo aprendido. El trabajo en paralelo hace importante esa vuelta. Un Worker puede leer los requisitos del cliente mientras otro investiga un límite técnico. Si los hallazgos llegan tras una cadena de relatos, puede desaparecer una condición importante. Cada Task devuelve sus hallazgos con sus fuentes. El Router los recibe en el mismo contexto principal. Eso nos dio un motivo para dividir el arnés de agentes en dos roles. Uno sigue la conversación continua del equipo. Los demás realizan los trabajos individuales. ## Cómo colaboran el Router y los Workers Damos a cada espacio de trabajo un Router residente. Mantiene el contexto principal del equipo y sigue la conversación mientras llegan peticiones, cambian decisiones y vuelven resultados. Una petición sobre la propuesta llega al mismo contexto que la discusión de entrega ya iniciada. Cada mensaje de entrada lleva la identidad de su conversación y mensaje de origen. El Router comparte contexto entre discusiones y conserva la procedencia de cada entrada. El Router entrega un trabajo definido a un Worker. Cada Task abre una nueva sesión de Worker con las instrucciones y el traspaso para ese trabajo. Los historiales de otros Workers permanecen en sus propias sesiones. Varios Workers pueden investigar preguntas distintas al mismo tiempo. Definimos cada Task con un objetivo, el contexto para perseguirlo y un entregable esperado. «Investiga este cliente» deja demasiado sin concretar. «Comprueba los requisitos de exportación y devuelve un formato propuesto, con fuentes y preguntas pendientes» da al Worker algo que puede terminar y al Router un resultado que puede usar. Supongamos que la propuesta requiere comprobar la exportación y estimar la entrega. Podemos asignarlo a Workers distintos. Uno devuelve los requisitos del cliente. El otro devuelve una estimación y sus supuestos. El Router lleva los resultados a la conversación principal, donde el equipo puede decidir. El trabajo terminado tiene un camino de vuelta. Cada Task abre una nueva sesión de Worker. Los resultados vuelven con fuentes a la conversación principal. Toda respuesta visible es un envío explícito, incluida una respuesta en la conversación principal. El Router nombra el destino y pasa sus comprobaciones. La salida del modelo y el final de un turno no publican una respuesta. La misma regla se aplica cuando un Worker informa o se dirige a otro participante. Leer material para una Task proporciona contexto al Worker; enviar se trata como una acción aparte. ### Control del flujo de información Las Tasks paralelas reúnen fuentes con públicos distintos. Cada envío declara las fuentes que utiliza. El control del flujo de información, o IFC, comprueba si los lectores del destino pueden leer esas fuentes. Con la aplicación de controles activada, un envío rechazado devuelve un motivo. El agente puede retirar el material restringido y reintentarlo, o solicitar la autorización humana necesaria para ese ámbito. El reintento debe modificar tanto el contenido como la declaración de fuentes. IFC ofrece al equipo un paso comprobable entre preparar una respuesta y compartirla. Toda respuesta visible es un envío explícito, incluidas las de la conversación principal. De vuelta en la propuesta, el Router puede presentar la estimación al equipo, pedir la decisión pendiente y enviar la respuesta acordada por el canal adecuado. El trabajo del Worker tiene un alcance delimitado. La conversación del equipo continúa a través del traspaso. Empezar una Task abre una nueva sesión de Worker. Cuando cambiamos de sesión, trasladamos el trabajo pendiente y sus referencias a la siguiente. El equipo sigue necesitando una forma de volver a sus decisiones anteriores. ## Lo que aprende el equipo en conjunto Los procedimientos reutilizables se convierten en skills compartidas por el grupo: instrucciones y recursos editables. El agente creador controla las modificaciones de los agentes. Los demás pueden usar la skill sin reescribirla; una skill integrada de solo lectura se puede copiar para personalizarla. Las sesiones reciben el catálogo de su ámbito y abren las instrucciones pertinentes. El Router mantiene memoria duradera sobre personas, entornos, hechos generales y episodios fechados. La lee o busca en ella cuando hace falta. Los Workers normales trabajan con los traspasos de las Tasks; los Triage Workers asignados tienen acceso de lectura vinculado a la fuente. La escritura en memoria corresponde al Router. Cuando está habilitado, Condensed Workspace da a cada sesión interna de Router y Worker la misma lista breve de hechos actuales del grupo. La persona propietaria del espacio de trabajo puede editarla directamente. Las actualizaciones de agentes reciben una comprobación orientativa de su relevancia como hechos actuales útiles para otros agentes. Se registran las revisiones y el último autor. La persona propietaria puede corregir o eliminar afirmaciones para que las premisas compartidas sean visibles y editables. Una actualización rechazada se puede reintentar con su ID de rechazo para anular explícitamente la comprobación. ## El coste de mantener una conversación Esta organización pone presión sobre la sesión principal. Los Workers pueden ejecutar en paralelo, pero el Router aún debe reunir sus resultados. Una petición nueva puede llegar mientras atiende otra anterior. Las personas lo experimentan como una cola, por muchos Workers que haya detrás. Seguimos trabajando en las colas en serie. Delegar una investigación larga deja al Router más espacio para responder, pero el equipo sigue necesitando un orden para decisiones que se afectan entre sí. En la propuesta, alguien debe fijar la fecha de entrega antes de enviar la promesa final. Una conversación compartida hace más visible esa dependencia y da al Router más responsabilidad para que el trabajo avance. El historial tiene su propio coste. Cada Task terminada añade algo que quizá valga la pena consultar después, junto con mucho que nunca volverá a importar. A medida que crece el historial, encontrar la decisión correcta y sus razones exige más trabajo. Queremos que resulte fácil encontrar una decisión antigua sin pedir a un compañero que reconstruya toda la discusión. Sus razones ayudan al equipo a reconocer cuándo debe cambiarla. Hasta aquí ha llegado nuestra exploración. Elegimos una conversación principal compartida porque los equipos vuelven al mismo trabajo a través de personas y Tasks diferentes. La próxima vez que alguien abra una discusión relacionada, queremos que el esfuerzo anterior del equipo siga allí. Ingeniería [Volver al blog](https://comma.surf/es/blog) Compartir ## Artículos relacionados 19 de octubre de 2026 ### [SSH nativo para los agentes de Comma](https://comma.surf/es/blog/native-ssh) 1 de octubre de 2026 ### [Bucles de eventos programables para nuestro arnés distribuido de agentes](https://comma.surf/es/blog/agent-programmable-event-loops) 31 de octubre de 2026 ### [Agentes personales alojados frente a autoalojados: ¿quién gestiona qué?](https://comma.surf/es/blog/hosted-vs-self-hosted-personal-agent) ## Try Comma, Now. [Empezar](https://app.comma.surf/)