La ubicación del estado es el mecanismo, no la etiqueta del agente

Una lectura del Arquitecto Honesto de Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, publicado el 2026-07-24 por Iván Palomares Carrascosa en MachineLearningMastery.com.

La afirmación de superficie del artículo es una taxonomía: agentes sin estado versus agentes con estado, con ejemplos de código para cada uno. El Arquitecto Honesto la lee por el mecanismo bajo la taxonomía, y encuentra seis. El que lleva la carga es la ubicación del estado: el encuadre del artículo es que «¿dónde reside la memoria del agente?» es la pregunta que «tiene que responderse antes de configurar cualquier balanceador de carga». La etiqueta del agente (sin estado o con estado) es la capa de marketing; la ubicación del estado es la capa de mecanismo. Theorem 3 en el HAI Engine de Everythink afirma la misma forma: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Aquí la propiedad es «escala horizontalmente a cualquier instancia»; el mecanismo es «no existe estado del lado del servidor.»

Este post extrae seis formas de mecanismo del artículo de MachineLearningMastery, aplica Theorem 3 a cada una y traza paralelos transversales a la plataforma Everythink. Cada paralelo desde nuestra plataforma está marcado ⚠️ — Everythink opera en previsión civil y defensiva, el artículo de MachineLearningMastery opera en educación de desarrolladores y arquitectura de agentes, así que el paralelo es estructural, no una afirmación de que nuestros sistemas sirvan al mismo mercado. Las seis formas de mecanismo mismas son ✅ — son extraíbles de la propia evidencia del artículo.

Mecanismo 1 — La ausencia de estado es el mecanismo de escalado horizontal

El artículo afirma que «las arquitecturas basadas en agentes sin estado pueden escalarse horizontalmente con notable facilidad. Dado que no se almacena memoria de usuario en un servidor backend, las solicitudes entrantes pueden reenviarse a cualquier instancia disponible». El Arquitecto Honesto lee esto como una afirmación de mecanismo: el escalado horizontal a cualquier instancia está garantizado por la ausencia de estado del lado del servidor, no por un balanceador de carga más inteligente. El mecanismo que produce «cualquier instancia puede servir cualquier solicitud» es «ninguna instancia contiene estado que otra instancia no tenga». Si el estado es cero, el ruteo es trivial; si el estado es distinto de cero, el ruteo debe respetarlo. ✅ Producción — el artículo nombra el mecanismo (sin memoria de usuario en el backend) y la propiedad (cualquier instancia puede servir).

El artículo es honesto de que esto es un tradeoff, no una victoria. La misma ausencia de estado del lado del servidor que hace fácil el escalado horizontal también hace difícil la continuidad multi-turno, que es el siguiente mecanismo. La ausencia de estado compra escalado; cuesta continuidad.

El paralelo transversal al HAI Engine de Everythink es solo estructural. El HAI Engine ejecuta Sisters que retornan SisterOutput y nunca escriben a Postgres ellas mismas — el Loom persiste. Las Sisters son workers de cómputo sin estado; el Loom es la capa de persistencia con estado. El «agente sin estado escala horizontalmente porque no hay estado del lado del servidor» del artículo de MachineLearningMastery y el «Sisters sin estado escalan porque retornan output y no persisten» de Everythink comparten la misma forma: el nodo de cómputo es sin estado, la persistencia está en otra parte. ⚠️ Parcial — el paralelo es estructural; las Sisters sin estado de Everythink sirven previsión civil y defensiva, el agente sin estado de MachineLearningMastery sirve educación de desarrolladores. Dominios diferentes, misma forma: el nodo de cómputo no contiene estado, así que puede reemplazarse o replicarse libremente.

Mecanismo 2 — El historial provisto por el cliente es el mecanismo de continuidad sin estado

El artículo afirma que en un diseño sin estado «el frontend debe reenviar todo el historial de conversación junto con cada nueva solicitud. Como resultado, la ventana de contexto crece con un efecto bola de nieve, aumentando rápidamente el uso de tokens». El Arquitecto Honesto lee esto como una afirmación de continuidad: la continuidad multi-turno en un diseño sin estado está garantizada por el cliente que carga el historial, no por el agente que lo recuerda. El mecanismo que produce continuidad es el payload provisto por el cliente, no la memoria del agente. El costo se nombra honestamente: el payload crece como bola de nieve, y el uso de tokens crece con él. ✅ Producción — el artículo nombra el mecanismo (el cliente reenvía el historial) y el costo (ventana de contexto bola de nieve).

El artículo es honesto de que este costo es un techo, no una molestia. Un agente sin estado que maneja conversaciones arbitrariamente largas debe recibir payloads arbitrariamente largos, así que el costo de tokens crece con la longitud de la conversación. Esto es un mecanismo con un techo nombrado, no un almuerzo gratis: funciona hasta que el payload excede la ventana de contexto o el presupuesto, y entonces deja de funcionar.

El paralelo transversal al Eye Key de Everythink es solo estructural. El Eye Key es la credencial propia del usuario — el HMAC y la huella se registran, el texto plano nunca toca disco, y la llave es la frontera de límite de tasa del usuario. El «el cliente carga el historial, el servidor no carga ninguno» del artículo de MachineLearningMastery y el «el usuario carga la llave, el servidor almacena solo el HMAC» de Everythink comparten la misma forma: el artefacto que lleva la soberanía vive con el cliente, el servidor almacena solo un verificador. ⚠️ Parcial — el paralelo es estructural; Eye Key rige la soberanía de API para previsión civil y defensiva, el historial-cliente de MachineLearningMastery rige la continuidad multi-turno para educación de desarrolladores. Dominios diferentes, misma forma: el cliente carga el artefacto load-bearing, el servidor carga un derivado.

Mecanismo 3 — La base de datos del lado del servidor es el mecanismo de continuidad con estado

El artículo afirma que en un diseño con estado «el agente toma sobre sí mismo la carga de memoria. El cliente, mientras tanto, solo necesita enviar el nuevo prompt del usuario junto con un identificador único. El agente entonces recupera el historial de sesión o contexto de una base de datos y añade el nuevo mensaje a él». El Arquitecto Honesto lee esto como una afirmación de continuidad: la continuidad multi-turno en un diseño con estado está garantizada por una base de datos del lado del servidor indexada por identificador de sesión, no por el cliente reenviando el historial. El mecanismo que produce continuidad es la búsqueda en base de datos, no el tamaño del payload. El payload del cliente se mantiene pequeño; el servidor almacena el historial creciente. ✅ Producción — el artículo nombra el mecanismo (base de datos indexada por identificador de sesión) y la propiedad (continuidad con payload de cliente pequeño).

El artículo es honesto de que esto mueve el costo, no lo elimina. El diseño con estado intercambia costo de payload por costo de base de datos: «escalar esta solución se vuelve mucho más difícil, comenzando con la necesidad de una capa de base de datos persistente en la arquitectura». La con-estadidad compra payloads pequeños y recorte del lado del servidor; cuesta una capa de base de datos y escalado más difícil.

El paralelo transversal a la persistencia del Loom de Everythink es solo estructural. El Loom persiste simulaciones y foresight a través de su puerto LoomStore propiedad de la slice, y las Sisters retornan SisterOutput sin persistir — el Loom es la capa con estado, las Sisters son los workers sin estado. El «el agente recupera el historial de una base de datos y añade el nuevo mensaje» del artículo de MachineLearningMastery y el «el Loom recupera estado previo, hace fan-out a las Sisters, persiste el resultado fusionado» de Everythink comparten la misma forma: el orquestador posee el estado, los workers poseen el cómputo. ⚠️ Parcial — el paralelo es estructural; el Loom sirve previsión civil y defensiva, el agente con estado de MachineLearningMastery sirve educación de desarrolladores. Dominios diferentes, misma forma: la capa de persistencia es la portadora de continuidad, la capa de cómputo es la productora sin estado.

Mecanismo 4 — El identificador de sesión es la llave de ruteo

El artículo afirma que «el identificador de sesión se usa para consultar la información relevante de interacciones pasadas en la conversación en curso». El Arquitecto Honesto lee esto como una afirmación de ruteo: la recuperación de memoria con estado está garantizada por el identificador de sesión como llave de ruteo, no por el recuerdo del agente. El mecanismo que hace al historial recuperable es la llave session_id, no la memoria interna del agente. Sin la llave, la base de datos es una pila sin indexar; con la llave, la base de datos es un historial recuperable. ✅ Producción — el artículo nombra el mecanismo (identificador de sesión como llave de consulta) y la propiedad (historial recuperable).

El artículo es honesto de que el identificador de sesión es un asunto de ruteo, no un asunto de memoria. Un agente con estado que pierde el identificador de sesión pierde el historial, incluso si el historial sigue en la base de datos. El diseño con estado depende de que la llave de ruteo esté presente y sea consistente, no de que la base de datos exista.

El paralelo transversal al «the space is the router» de Everythink es solo estructural. La topología de Everythink es red → comunidad → sala: una solicitud se enruta a una sala antes de que algo responda, y la llave de sala es la llave de ruteo que hace al estado correcto recuperable. El «el identificador de sesión enruta la solicitud al historial correcto» del artículo de MachineLearningMastery y el «la topología enruta la consulta a la sala correcta» de Everythink comparten la misma forma: la llave de ruteo precede a la respuesta, y la llave de ruteo decide qué estado es recuperable. El World Monitor de Everythink encarna la misma forma a escala planetaria: las geo-señales se rutean por prefijo de geohash, los clientes leen la caché no los upstreams, así que la llave de ruteo (el geohash) decide qué estado de tile es recuperable antes de cualquier respuesta de viewport. ⚠️ Parcial — el paralelo es estructural; el router de Everythink es una topología de salas públicas y tiles de geohash, el router de MachineLearningMastery es un identificador de sesión. Dominios diferentes, misma forma: la llave de ruteo es la portadora de recuperabilidad, y la decisión de ruteo precede a la respuesta.

Mecanismo 5 — La amnesia localizada es el modo de falla de escalado con estado

El artículo afirma que «en infraestructuras que escalan horizontalmente, estrategias como el caché de memoria centralizada con Redis pueden también volverse necesarias para evitar "amnesia localizada", donde el historial de una sesión queda varado en la única instancia que happened to serve los turnos anteriores». El Arquitecto Honesto lee esto como una afirmación de modo de falla: la falla de escalado con estado está garantizada por estado local a la instancia en una flota escalada horizontalmente, no por la base de datos siendo lenta. El mecanismo que produce amnesia localizada es «el estado vive en la instancia que lo escribió, y el balanceador de carga no enruta por session_id». La solución se nombra honestamente: caché de memoria centralizada con Redis, así que el estado se comparte entre instancias. ✅ Producción — el artículo nombra el modo de falla (amnesia localizada), el mecanismo (estado local a la instancia en una flota escalada) y la solución (caché centralizada).

El artículo es honesto de que este es un modo de falla específico con un mecanismo específico, no un vago «escalar es difícil». La amnesia localizada ocurre cuando el estado es local a la instancia y el ruteo es ciego al estado; no ocurre cuando el estado se comparte o el ruteo es consciente de la sesión. La falla tiene un mecanismo, y el mecanismo tiene una solución.

El paralelo transversal a los puertos hexagonales basados en traits de Everythink es solo estructural. Los repositorios AppState de Everythink son Arc así que los tests intercambian mocks, y la persistencia se alcanza a través de un puerto, nunca un PgPool concreto — el estado está detrás de un trait compartido, no varado en una instancia concreta. El «caché centralizada así que el estado se comparte entre instancias» del artículo de MachineLearningMastery y el «trait compartido así que el estado es alcanzable a través de cualquier adaptador» de Everythink comparten la misma forma: el estado se comparte a través de una abstracción, no varado en un portador concreto. ⚠️ Parcial — el paralelo es estructural; el trait compartido de Everythink sirve previsión civil y defensiva, la caché centralizada de MachineLearningMastery sirve educación de desarrolladores. Dominios diferentes, misma forma: el estado se comparte, así que ninguna instancia es la portadora única.

Mecanismo 6 — La coincidencia de flujo de trabajo es el mecanismo de selección

El artículo afirma que «la elección entre un diseño arquitectónico con estado y sin estado se reduce a emparejar apropiadamente la infraestructura con el flujo de trabajo», y da los criterios: sin estado para «pipelines simples orientados a tareas muy específicas, como extracción de texto, resumen o chatbots de clasificación de un solo turno»; con estado para «asistentes de larga duración, asistentes de código, o bots multi-turno en aplicaciones como servicio al cliente». El Arquitecto Honesto lee esto como una afirmación de selección: el modelo de estado correcto está garantizado emparejando la ubicación del estado con la demanda de continuidad del flujo de trabajo, no eligiendo el diseño más sofisticado. El mecanismo que produce la elección correcta es la coincidencia de flujo de trabajo, no la preferencia de tecnología. ✅ Producción — el artículo nombra el mecanismo (emparejar infraestructura con flujo de trabajo) y los criterios (un-turno vs multi-turno).

El artículo es honesto de que ningún diseño es universalmente superior. Un agente sin estado forzado en un flujo de trabajo multi-turno acumula payloads como bola de nieve; un agente con estado forzado en un flujo de trabajo de un-turno paga un costo de base de datos que no necesita. No hay ganador global: el mecanismo correcto depende del flujo de trabajo, y el flujo de trabajo es el criterio de selección.

El paralelo transversal a los puertos hexagonales basados en traits de Everythink es solo estructural. La arquitectura de Everythink es un conjunto de puertos donde cada puerto responde una pregunta diferente, y los crates de caso de uso dependen del trait, nunca del adaptador concreto — el puerto correcto se selecciona por la pregunta, no por la preferencia de implementación. El «empareja el modelo de estado con el flujo de trabajo» del artículo de MachineLearningMastery y el «empareja el puerto con la pregunta» de Everythink comparten la misma forma: la selección es por la demanda, no por la oferta. ⚠️ Parcial — el paralelo es estructural; la selección de puerto de Everythink sirve previsión civil y defensiva, la selección de modelo de estado de MachineLearningMastery sirve educación de desarrolladores. Dominios diferentes, misma forma: el mecanismo de selección es la coincidencia de demanda, no la preferencia de oferta.

Qué implica esto para alcance y límites

El artículo de MachineLearningMastery trata sobre educación de desarrolladores y arquitectura de agentes. La plataforma de Everythink trata sobre previsión civil y defensiva. Los paralelos transversales en este post son estructurales — comparten formas de mecanismo, no mercados. El Arquitecto Honesto marca los paralelos ⚠️ por esta razón.

El go-to-market propio de Everythink para herramientas de agentes comerciales es 🔵 Roadmap — la plataforma es pre-revenue, y cualquier aplicación comercial de los paralelos trazados aquí está sujeta a ese estado Roadmap y a la revisión Howey antes de poder ofrecerse. Los paralelos arquitectónicos se sostienen independientemente; las afirmaciones comerciales no.

Lo que el artículo no afirma merece también una marca. No afirma que sin estado es superior — nombra el costo de payload bola de nieve. No afirma que con estado es superior — nombra el costo de capa de base de datos y la falla de amnesia localizada. No afirma que el tradeoff es resoluble — nombra el criterio de coincidencia. Estos límites de alcance son la honestidad del artículo, y este post los preserva.

Puntos clave

• El escalado horizontal a cualquier instancia está garantizado por la ausencia de estado del lado del servidor, no por un balanceador de carga más inteligente. La ubicación del estado es el mecanismo de escalado. ✅ Producción.
• La continuidad multi-turno en un diseño sin estado está garantizada por el cliente que carga el historial, con un costo de payload bola de nieve. El payload del cliente es la portadora de continuidad. ✅ Producción.
• La continuidad multi-turno en un diseño con estado está garantizada por una base de datos del lado del servidor indexada por identificador de sesión, con un costo de capa de base de datos. La base de datos es la portadora de continuidad. ✅ Producción.
• La recuperación de memoria con estado está garantizada por el identificador de sesión como llave de ruteo. La llave de ruteo es la portadora de recuperabilidad. ✅ Producción.
• La falla de escalado con estado está garantizada por estado local a la instancia en una flota escalada horizontalmente; la solución es estado compartido o ruteo consciente de la sesión. La falla tiene un mecanismo, y el mecanismo tiene una solución. ✅ Producción.
• El modelo de estado correcto está garantizado emparejando la ubicación del estado con la demanda de continuidad del flujo de trabajo. El flujo de trabajo es el mecanismo de selección. ✅ Producción.
• Los paralelos transversales al HAI Engine de Everythink (Sisters sin estado, Loom con estado), «the space is the router» (la llave de ruteo precede a la respuesta), World Monitor (caché como capa con estado, pollers como alimentadores sin estado), Eye Key (el cliente carga el artefacto load-bearing) y los puertos hexagonales (trait compartido, selección por coincidencia de demanda) son solo estructurales — mercados diferentes, mismas formas de mecanismo. ⚠️ Parcial.
• El go-to-market de Everythink para herramientas de agentes comerciales es 🔵 Roadmap — pre-revenue, sujeto a revisión Howey; los paralelos arquitectónicos se sostienen, las afirmaciones comerciales no.

Sources

• Iván Palomares Carrascosa, Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, MachineLearningMastery.com, publicado el 2026-07-24. https://machinelearningmastery.com/stateful-vs-stateless-agent-design-tradeoffs-for-scalable-agentic-systems (recuperado el 2026-08-23).
• Arquitectura de la plataforma Everythink: HAI Engine en producción desde 2016; Theorem 3 (una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo); topología «the space is the router» (red → comunidad → sala); World Monitor (geo-señales ruteadas por prefijo de geohash, los clientes leen la caché no los upstreams); normalización del ensemble del Oracle con entropía en nats estampada en cada merge; Sisters tipadas (analyst, contrarian, disruptor, historian, institutionalist) retornando SisterOutput sin persistir, Loom como capa de persistencia con estado; puertos hexagonales basados en traits con adaptadores intercambiables; soberanía del Eye Key (HMAC y huella registrados, el texto plano nunca toca disco, la llave del usuario es la frontera de límite de tasa).