A localização do estado é o mecanismo, não o rótulo do agente

Uma leitura do Arquiteto Honesto de Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, publicado em 2026-07-24 por Iván Palomares Carrascosa na MachineLearningMastery.com.

A afirmação de superfície do artigo é uma taxonomia: agentes stateless versus agentes stateful, com exemplos de código para cada um. O Arquiteto Honesto a lê pelo mecanismo sob a taxonomia, e encontra seis. O que carrega o peso é a localização do estado: o enquadramento do artigo é que «onde reside a memória do agente?» é a pergunta que «tem que ser respondida antes de qualquer balanceador de carga ser configurado». O rótulo do agente (stateless ou stateful) é a camada de marketing; a localização do estado é a camada de mecanismo. Theorem 3 no HAI Engine da Everythink afirma a mesma forma: uma propriedade é garantida exatamente quando seu mecanismo está implementado e medindo. Aqui a propriedade é «escala horizontalmente para qualquer instância»; o mecanismo é «não existe estado do lado do servidor.»

Este post extrai seis formas de mecanismo do artigo da MachineLearningMastery, aplica Theorem 3 a cada uma e traça paralelos transversais à plataforma Everythink. Cada paralelo desde nossa plataforma é marcado ⚠️ — Everythink opera em previsão civil e defensiva, o artigo da MachineLearningMastery opera em educação de desenvolvedores e arquitetura de agentes, então o paralelo é estrutural, não uma afirmação de que nossos sistemas servem ao mesmo mercado. As seis formas de mecanismo mesmas são ✅ — são extraíveis da própria evidência do artigo.

Mecanismo 1 — A ausência de estado é o mecanismo de escalonamento horizontal

O artigo afirma que «arquiteturas baseadas em agentes stateless podem ser escalonadas horizontalmente com notável facilidade. Como nenhuma memória de usuário é armazenada em um servidor backend, requisições recebidas podem ser encaminhadas a qualquer instância disponível». O Arquiteto Honesto lê isto como uma afirmação de mecanismo: o escalonamento horizontal para qualquer instância é garantido pela ausência de estado do lado do servidor, não por um balanceador de carga mais inteligente. O mecanismo que produz «qualquer instância pode servir qualquer requisição» é «nenhuma instância contém estado que outra instância não tenha». Se o estado é zero, o roteamento é trivial; se o estado é não-zero, o roteamento deve respeitá-lo. ✅ Produção — o artigo nomeia o mecanismo (sem memória de usuário no backend) e a propriedade (qualquer instância pode servir).

O artigo é honesto que isto é um tradeoff, não uma vitória. A mesma ausência de estado do lado do servidor que torna o escalonamento horizontal fácil também torna a continuidade multi-turno difícil, que é o próximo mecanismo. A ausência de estado compra escalonamento; custa continuidade.

O paralelo transversal ao HAI Engine da Everythink é apenas estrutural. O HAI Engine executa Sisters que retornam SisterOutput e nunca escrevem ao Postgres elas mesmas — o Loom persiste. As Sisters são workers de computação stateless; o Loom é a camada de persistência stateful. O «agente stateless escala horizontalmente porque não há estado do lado do servidor» do artigo da MachineLearningMastery e o «Sisters stateless escalam porque retornam output e não persistem» da Everythink compartilham a mesma forma: o nó de computação é stateless, a persistência está em outro lugar. ⚠️ Parcial — o paralelo é estrutural; as Sisters stateless da Everythink servem previsão civil e defensiva, o agente stateless da MachineLearningMastery serve educação de desenvolvedores. Domínios diferentes, mesma forma: o nó de computação não carrega estado, então pode ser substituído ou replicado livremente.

Mecanismo 2 — O histórico fornecido pelo cliente é o mecanismo de continuidade stateless

O artigo afirma que em um design stateless «o frontend deve reenviar todo o histórico de conversação junto com cada nova requisição. Como resultado, a janela de contexto cresce com um efeito bola de neve, aumentando rapidamente o uso de tokens». O Arquiteto Honesto lê isto como uma afirmação de continuidade: a continuidade multi-turno em um design stateless é garantida pelo cliente carregando o histórico, não pelo agente lembrando dele. O mecanismo que produz continuidade é o payload fornecido pelo cliente, não a memória do agente. O custo é nomeado honestamente: o payload cresce como bola de neve, e o uso de tokens cresce com ele. ✅ Produção — o artigo nomeia o mecanismo (o cliente reenvia o histórico) e o custo (janela de contexto bola de neve).

O artigo é honesto que este custo é um teto, não um incômodo. Um agente stateless que lida com conversas arbitrariamente longas deve receber payloads arbitrariamente longos, então o custo de tokens cresce com o comprimento da conversa. Isto é um mecanismo com um teto nomeado, não um almoço grátis: funciona até que o payload exceda a janela de contexto ou o orçamento, e então para de funcionar.

O paralelo transversal ao Eye Key da Everythink é apenas estrutural. O Eye Key é a credencial própria do usuário — o HMAC e a impressão são registrados, o texto claro nunca toca disco, e a chave é a fronteira de limite de taxa do usuário. O «o cliente carrega o histórico, o servidor não carrega nenhum» do artigo da MachineLearningMastery e o «o usuário carrega a chave, o servidor armazena apenas o HMAC» da Everythink compartilham a mesma forma: o artefato que carrega a soberania vive com o cliente, o servidor armazena apenas um verificador. ⚠️ Parcial — o paralelo é estrutural; Eye Key rege a soberania de API para previsão civil e defensiva, o histórico-cliente da MachineLearningMastery rege a continuidade multi-turno para educação de desenvolvedores. Domínios diferentes, mesma forma: o cliente carrega o artefato load-bearing, o servidor carrega um derivado.

Mecanismo 3 — O banco de dados do lado do servidor é o mecanismo de continuidade stateful

O artigo afirma que em um design stateful «o agente assume sobre si mesmo o ônus da memória. O cliente, enquanto isso, apenas precisa enviar o novo prompt do usuário junto com um identificador único. O agente então recupera o histórico de sessão ou contexto de um banco de dados e anexa a nova mensagem a ele». O Arquiteto Honesto lê isto como uma afirmação de continuidade: a continuidade multi-turno em um design stateful é garantida por um banco de dados do lado do servidor indexado por identificador de sessão, não pelo cliente reenviando o histórico. O mecanismo que produz continuidade é a busca no banco de dados, não o tamanho do payload. O payload do cliente se mantém pequeno; o servidor armazena o histórico crescente. ✅ Produção — o artigo nomeia o mecanismo (banco de dados indexado por identificador de sessão) e a propriedade (continuidade com payload de cliente pequeno).

O artigo é honesto que isto move o custo, não o elimina. O design stateful troca custo de payload por custo de banco de dados: «escalar esta solução se torna muito mais difícil, começando pela necessidade de uma camada de banco de dados persistente na arquitetura». A statefulidade compra payloads pequenos e aparação do lado do servidor; custa uma camada de banco de dados e escalonamento mais difícil.

O paralelo transversal à persistência do Loom da Everythink é apenas estrutural. O Loom persiste simulações e foresight através de sua porta LoomStore própria da slice, e as Sisters retornam SisterOutput sem persistir — o Loom é a camada stateful, as Sisters são os workers stateless. O «o agente recupera o histórico de um banco de dados e anexa a nova mensagem» do artigo da MachineLearningMastery e o «o Loom recupera estado prévio, faz fan-out para as Sisters, persiste o resultado fundido» da Everythink compartilham a mesma forma: o orquestrador possui o estado, os workers possuem a computação. ⚠️ Parcial — o paralelo é estrutural; o Loom serve previsão civil e defensiva, o agente stateful da MachineLearningMastery serve educação de desenvolvedores. Domínios diferentes, mesma forma: a camada de persistência é a portadora de continuidade, a camada de computação é a produtora stateless.

Mecanismo 4 — O identificador de sessão é a chave de roteamento

O artigo afirma que «o identificador de sessão é usado para consultar a informação relevante de interações passadas na conversação em curso». O Arquiteto Honesto lê isto como uma afirmação de roteamento: a recuperação de memória stateful é garantida pelo identificador de sessão como chave de roteamento, não pela recordação do agente. O mecanismo que torna o histórico recuperável é a chave session_id, não a memória interna do agente. Sem a chave, o banco de dados é uma pilha não indexada; com a chave, o banco de dados é um histórico recuperável. ✅ Produção — o artigo nomeia o mecanismo (identificador de sessão como chave de consulta) e a propriedade (histórico recuperável).

O artigo é honesto que o identificador de sessão é uma questão de roteamento, não uma questão de memória. Um agente stateful que perde o identificador de sessão perde o histórico, mesmo se o histórico ainda está no banco de dados. O design stateful depende da chave de roteamento estar presente e consistente, não do banco de dados existir.

O paralelo transversal ao «the space is the router» da Everythink é apenas estrutural. A topologia da Everythink é rede → comunidade → sala: uma requisição é roteada a uma sala antes que algo responda, e a chave de sala é a chave de roteamento que torna o estado correto recuperável. O «o identificador de sessão roteia a requisição ao histórico correto» do artigo da MachineLearningMastery e o «a topologia roteia a consulta à sala correta» da Everythink compartilham a mesma forma: a chave de roteamento precede a resposta, e a chave de roteamento decide qual estado é recuperável. O World Monitor da Everythink encarna a mesma forma em escala planetária: os geo-sinais são roteados por prefixo de geohash, os clientes leem o cache não os upstreams, então a chave de roteamento (o geohash) decide qual estado de tile é recuperável antes de qualquer resposta de viewport. ⚠️ Parcial — o paralelo é estrutural; o router da Everythink é uma topologia de salas públicas e tiles de geohash, o router da MachineLearningMastery é um identificador de sessão. Domínios diferentes, mesma forma: a chave de roteamento é a portadora de recuperabilidade, e a decisão de roteamento precede a resposta.

Mecanismo 5 — A amnésia localizada é o modo de falha de escalonamento stateful

O artigo afirma que «em infraestruturas que escalam horizontalmente, estratégias como cache de memória centralizada com Redis podem também se tornar necessárias para evitar "amnésia localizada", onde o histórico de uma sessão fica encalhado na única instância que aconteceu de servir os turnos anteriores». O Arquiteto Honesto lê isto como uma afirmação de modo de falha: a falha de escalonamento stateful é garantida por estado local à instância em uma frota escalada horizontalmente, não pelo banco de dados sendo lento. O mecanismo que produz amnésia localizada é «o estado vive na instância que o escreveu, e o balanceador de carga não roteia por session_id». A correção é nomeada honestamente: cache de memória centralizada com Redis, então o estado é compartilhado entre instâncias. ✅ Produção — o artigo nomeia o modo de falha (amnésia localizada), o mecanismo (estado local à instância em uma frota escalada) e a correção (cache centralizado).

O artigo é honesto que este é um modo de falha específico com um mecanismo específico, não um vago «escalar é difícil». A amnésia localizada acontece quando o estado é local à instância e o roteamento é cego ao estado; não acontece quando o estado é compartilhado ou o roteamento é consciente da sessão. A falha tem um mecanismo, e o mecanismo tem uma correção.

O paralelo transversal às portas hexagonais baseadas em traits da Everythink é apenas estrutural. Os repositórios AppState da Everythink são Arc então os testes trocam em mocks, e a persistência é alcançada através de uma porta, nunca um PgPool concreto — o estado está atrás de um trait compartilhado, não encalhado em uma instância concreta. O «cache centralizado então o estado é compartilhado entre instâncias» do artigo da MachineLearningMastery e o «trait compartilhado então o estado é alcançável através de qualquer adaptador» da Everythink compartilham a mesma forma: o estado é compartilhado através de uma abstração, não encalhado em um portador concreto. ⚠️ Parcial — o paralelo é estrutural; o trait compartilhado da Everythink serve previsão civil e defensiva, o cache centralizado da MachineLearningMastery serve educação de desenvolvedores. Domínios diferentes, mesma forma: o estado é compartilhado, então nenhuma instância é a portadora única.

Mecanismo 6 — A correspondência de fluxo de trabalho é o mecanismo de seleção

O artigo afirma que «a escolha entre um design arquitetônico stateful e stateless se resume a corresponder apropriadamente a infraestrutura ao fluxo de trabalho», e dá os critérios: stateless para «pipelines simples orientados a tarefas muito específicas, como extração de texto, sumarização ou chatbots de classificação de um-turno»; stateful para «assistentes de longa duração, assistentes de código, ou bots multi-turno em aplicações como atendimento ao cliente». O Arquiteto Honesto lê isto como uma afirmação de seleção: o modelo de estado correto é garantido correspondendo a localização do estado à demanda de continuidade do fluxo de trabalho, não escolhendo o design mais sofisticado. O mecanismo que produz a escolha correta é a correspondência de fluxo de trabalho, não a preferência de tecnologia. ✅ Produção — o artigo nomeia o mecanismo (corresponder infraestrutura ao fluxo de trabalho) e os critérios (um-turno vs multi-turno).

O artigo é honesto que nenhum design é universalmente superior. Um agente stateless forçado em um fluxo de trabalho multi-turno acumula payloads como bola de neve; um agente stateful forçado em um fluxo de trabalho de um-turno paga um custo de banco de dados que não precisa. Não há vencedor global: o mecanismo correto depende do fluxo de trabalho, e o fluxo de trabalho é o critério de seleção.

O paralelo transversal às portas hexagonais baseadas em traits da Everythink é apenas estrutural. A arquitetura da Everythink é um conjunto de portas onde cada porta responde a uma pergunta diferente, e os crates de caso de uso dependem do trait, nunca do adaptador concreto — a porta correta é selecionada pela pergunta, não pela preferência de implementação. O «corresponda o modelo de estado ao fluxo de trabalho» do artigo da MachineLearningMastery e o «corresponda a porta à pergunta» da Everythink compartilham a mesma forma: a seleção é pela demanda, não pela oferta. ⚠️ Parcial — o paralelo é estrutural; a seleção de porta da Everythink serve previsão civil e defensiva, a seleção de modelo de estado da MachineLearningMastery serve educação de desenvolvedores. Domínios diferentes, mesma forma: o mecanismo de seleção é a correspondência de demanda, não a preferência de oferta.

O que isto implica para escopo e limites

O artigo da MachineLearningMastery é sobre educação de desenvolvedores e arquitetura de agentes. A plataforma da Everythink é sobre previsão civil e defensiva. Os paralelos transversais neste post são estruturais — eles compartilham formas de mecanismo, não mercados. O Arquiteto Honesto marca os paralelos ⚠️ por esta razão.

O próprio go-to-market da Everythink para ferramentas de agentes comerciais é 🔵 Roadmap — a plataforma é pre-revenue, e qualquer aplicação comercial dos paralelos traçados aqui está sujeita àquele estado Roadmap e à revisão Howey antes de poder ser oferecida. Os paralelos arquitetônicos se sustentam independentemente; as afirmações comerciais não.

O que o artigo não afirma merece também uma marca. Não afirma que stateless é superior — nomeia o custo de payload bola de neve. Não afirma que stateful é superior — nomeia o custo de camada de banco de dados e a falha de amnésia localizada. Não afirma que o tradeoff é resolvível — nomeia o critério de correspondência. Estes limites de escopo são a honestidade do artigo, e este post os preserva.

Pontos principais

• O escalonamento horizontal para qualquer instância é garantido pela ausência de estado do lado do servidor, não por um balanceador de carga mais inteligente. A localização do estado é o mecanismo de escalonamento. ✅ Produção.
• A continuidade multi-turno em um design stateless é garantida pelo cliente carregando o histórico, com um custo de payload bola de neve. O payload do cliente é a portadora de continuidade. ✅ Produção.
• A continuidade multi-turno em um design stateful é garantida por um banco de dados do lado do servidor indexado por identificador de sessão, com um custo de camada de banco de dados. O banco de dados é a portadora de continuidade. ✅ Produção.
• A recuperação de memória stateful é garantida pelo identificador de sessão como chave de roteamento. A chave de roteamento é a portadora de recuperabilidade. ✅ Produção.
• A falha de escalonamento stateful é garantida por estado local à instância em uma frota escalada horizontalmente; a correção é estado compartilhado ou roteamento consciente da sessão. A falha tem um mecanismo, e o mecanismo tem uma correção. ✅ Produção.
• O modelo de estado correto é garantido correspondendo a localização do estado à demanda de continuidade do fluxo de trabalho. O fluxo de trabalho é o mecanismo de seleção. ✅ Produção.
• Os paralelos transversais ao HAI Engine da Everythink (Sisters stateless, Loom stateful), «the space is the router» (a chave de roteamento precede a resposta), World Monitor (cache como camada stateful, pollers como alimentadores stateless), Eye Key (o cliente carrega o artefato load-bearing) e portas hexagonais (trait compartilhado, seleção por correspondência de demanda) são apenas estruturais — mercados diferentes, mesmas formas de mecanismo. ⚠️ Parcial.
• O go-to-market da Everythink para ferramentas de agentes comerciais é 🔵 Roadmap — pre-revenue, sujeito à revisão Howey; os paralelos arquitetônicos se sustentam, as afirmações comerciais não.

Sources

• Iván Palomares Carrascosa, Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, MachineLearningMastery.com, publicado em 2026-07-24. https://machinelearningmastery.com/stateful-vs-stateless-agent-design-tradeoffs-for-scalable-agentic-systems (recuperado em 2026-08-23).
• Arquitetura da plataforma Everythink: HAI Engine em produção desde 2016; Theorem 3 (uma propriedade é garantida exatamente quando seu mecanismo está implementado e medindo); topologia «the space is the router» (rede → comunidade → sala); World Monitor (geo-sinais roteados por prefixo de geohash, os clientes leem o cache não os upstreams); normalização do ensemble do Oracle com entropia em nats estampada em cada merge; Sisters tipadas (analyst, contrarian, disruptor, historian, institutionalist) retornando SisterOutput sem persistir, Loom como camada de persistência stateful; portas hexagonais baseadas em traits com adaptadores intercambiáveis; soberania do Eye Key (HMAC e impressão registrados, o texto claro nunca toca disco, a chave do usuário é a fronteira de limite de taxa).