Separar memória, conhecimento e contexto reduz alucinação em agentes de IA, mostra arquitetura da InfoQ

Um artigo da InfoQ argumenta que separar essas três camadas resolve boa parte das alucinações em sistemas agênticos. No Brasil, porém, grande parte dos times ainda empilha tudo isso dentro de um único prompt.

O que são contexto, memória e conhecimento para um agente

Um artigo publicado em 2 de novembro de 2026 na InfoQ, assinado pela arquiteta Adi Polak, ataca um problema que a maioria dos times de agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → trata de forma superficial: contexto, memória e conhecimento não são a mesma coisa, e tratá-los como sinônimos é uma das causas mais comuns de alucinação em produção.

A proposta divide o sistema em três camadas com funções bem distintas:

No exemplo que a autora usa, fazer uma omelete não exige lembrar como sovar massa de pão: isso é conhecimento disponível no sistema, mas que só vira contexto quando a tarefa pede. É essa seleção, segundo o artigo, que separa um agente confiável de um que inventa resposta.

Da engenharia de prompt para a engenharia de estado

O texto argumenta que a unidade de trabalho mudou. Engenharia de prompt pergunta "o que devo pedir ao modelo"; engenharia de contexto pergunta "qual é o conjunto mínimo e mais valioso de informação que o modelo precisa agora para raciocinar bem". A diferença não é estilística: é arquitetural.

Para isso, a autora propõe isolar a máquina em torno do modelo num componente chamado context engine, responsável por selecionar, filtrar, ranquear, estruturar, comprimir e proteger a informação antes que ela chegue ao modelo. A comparação usada é com um compilador: assim como um compilador traduz código de alto nível em instruções executáveis, o context engine traduz dados brutos, dispersos e não estruturados num estado pronto para raciocínio, já validado, sem dados pessoais e dentro de limites de negócio.

Contexto não é commodity, mesmo com modelo e banco vetorial padronizados

O artigo chama atenção para uma camada que virou produto genérico: modelos como GPT-4 e Claude, e bancos vetoriais como Pinecone e Milvus, hoje são acessíveis via API para qualquer time. Isso não vale para o contexto em si.

Segundo a autora, os princípios de curadoria de contexto são específicos de cada domínio de negócio. Um agente de análise de fraude num banco prioriza timestamp de transação, anomalia de geolocalização e regras de compliance; um agente jurídico que gera contratos prioriza legislação estadual. A conclusão do artigo é que contexto não pode ser genérico: ele precisa refletir a lógica, as fronteiras de segurança e o vocabulário do produto específico.

Alucinação como falha de engenharia, não do modelo

O ponto mais direto do artigo é que alucinação quase nunca é o modelo "quebrado": é sintoma de uma janela de contexto mal gerida.

Alucinações de LLMs raramente são resultado de um modelo "quebrado"; quase sempre são sintoma de uma janela de contexto mal administrada e empobrecida.

Adi Polak, arquiteta e autora do artigo na InfoQLLM hallucinations are rarely the result of a "broken" model; they are almost always the symptom of an unmanaged, impoverished context window.

Na prática, isso significa que encher o prompt com dados não é proteção contra erro: dez páginas de wiki despejadas sem curadoria fazem o modelo gastar ciclos de computação tentando separar sinal de ruído, e o sinal relevante acaba enterrado. O artigo chama isso de operar como um SELECT *: mais dado não é sinônimo de mais acerto.

O ciclo de vida do contexto que a maioria dos times pula

O artigo descreve quatro estágios que, segundo ele, deveriam existir como módulos ou serviços dedicados na arquitetura de qualquer agente:

1. Seleção: identificar os pontos de dado de maior valor para a tarefa, combinando busca semântica densa, busca por palavra-chave (como BM25) e navegação em grafos de conhecimento, em vez de depender só de similaridade de cosseno.
2. Injeção: colocar essa informação na janela de contexto de forma estruturada, com templates semânticos, exemplos e esquemas de saída (como definições JSON) claros, porque ordem e agrupamento mudam como o modelo raciocina.
3. Compressão: usar modelos menores e mais baratos, ou algoritmos determinísticos, para resumir históricos longos antes de cada rodada, testando a qualidade do resumo com métricas como PPL Ratio ou divergência KL.
4. Expiração e atualização: aposentar suposições antigas, porque contexto que nunca expira vira passivo: uma preferência de usuário pode durar meses, mas um incidente de suporte pode virar ruído em uma semana.

Sem o quarto estágio, segundo o artigo, sistemas caem num loop de dado obsoleto, reusando contexto que já foi correto mas que hoje só é convincente.

Token economics: contexto maior nem sempre ajuda

Modelos com janelas de 128 mil a mais de 1 milhão de tokens tentaram alguns times a jogar repositórios inteiros ou pilhas de documentos dentro do prompt. O artigo é direto: isso aumenta a latência até o primeiro token, explode o custo de API e, paradoxalmente, piora a qualidade da resposta.

A explicação técnica citada é o fenômeno "lost in the middle", descrito por pesquisadores de Stanford liderados por Nelson F. Liu em 2023: o modelo lembra bem do início e do fim de uma janela de contexto grande, mas perde precisão nos fatos enterrados no meio dela. Quanto maior a janela usada, maior essa zona cega. Por isso o artigo defende orçar contexto como se orça qualquer outro recurso caro: nem tudo que cabe nos 100 mil tokens disponíveis deveria ser enviado.

O que muda pra quem constrói agentes no Brasil

Boa parte dos agentes em produção por aqui, hoje, segue uma pilha razoavelmente padrão: LangChain ou orquestrador equivalente, um banco vetorial como Pinecone ou pgvector, e uma chamada direta pra GPT-4, Claude ou um modelo nacional, com RAG simples buscando os documentos mais parecidos e jogando tudo no prompt. É exatamente o padrão que o artigo da InfoQ descreve como SELECT * disfarçado de arquitetura.

Times de fintech e bancos digitais que rodam agentes de triagem de fraude ou atendimento via WhatsApp tendem a sentir isso primeiro: o custo de token sobe junto com o histórico de conversa acumulado, e a resposta começa a variar porque o contexto mistura regra de negócio antiga (conhecimento), preferência do cliente de seis meses atrás (memória) e o evento que acabou de acontecer (contexto real), tudo sem nenhuma camada separando as três coisas.

A recomendação prática do artigo, adaptada a esse cenário, é simples de descrever e trabalhosa de implementar: separar o pipeline que transforma dado bruto em conhecimento (sumarizações periódicas, grafos de conhecimento) do pipeline que decide o que vira memória de curto prazo, e tratar expiração de contexto como parte do design desde o início, não como ajuste fino depois que o custo de inferência já estourou o orçamento.

Fica em aberto, no próprio artigo, como medir objetivamente a qualidade de um resumo de contexto em produção: a autora cita métricas como PPL Ratio, divergência KL e teste qui-quadrado, mas sem indicar qual delas vira padrão de mercado. Para quem está desenhando a próxima geração de agentes por aqui, essa ainda é uma lacuna a preencher caso a caso.

Fonte 1: InfoQ (https://www.infoq.com/articles/agentic-ai-context-memory-knowledge/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global)

Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures - InfoQ

BT

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architect.

View an example

We protect your privacy.

Close

InfoQ Homepage

Articles

Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures

Architecture & Design

Nov 02, 2026

16 min read

by

Adi Polak

reviewed by

Rafał Gancarz

Youtube 232K Followers Linkedin 26K Followers Instagram New RSS 19K Readers X 57.1k Followers Facebook 21K Likes Bluesky New

Listen to this article - 0:00

Audio ready to play

Your browser does not support the audio element.

0:00

Normal 1.25x 1.5x

Like

Reading list

Key Takeaways

Context engineering beats prompt engineering - the system that builds context matters more than the prompt itself.

Separate context, memory, and knowledge - each serves a different purpose and should be managed independently.

Balance history with real-time data - great agents combine experience with live signals.

Hallucinations are often context failures - better context leads to more reliable reasoning.

Optimize context, don't maximize it - small, relevant context outperforms large, noisy prompts.

This article is part of the " Agentic AI Architecture " article series. In this series, we try to establish agentic AI architecture as a new type of software architecture that will likely dominate the industry for years to come. The articles, written by industry experts, cover various elements and aspects of agentic AI architecture. We aim to present the latest trends and developments shaping the new type of architecture as it enters the mainstream.

As the industry moves from chatbots to autonomous agents, the architectural bottleneck is shifting. The hard problem is no longer simply retrieving data. It is deciding what an agent should know, when it should know it, how long it should remember it, and what should be forgotten. As with humans, it is one thing to know and another to remember. Hence, memory and knowledge. Knowing when to use any of the existing "knows" by bringing it to memory depends on the task context . For example, if I want to cook an omelet, I don't necessarily need to remember how to knead dough right now.

Let's break it down.

Related Sponsors

Agents must reason across tools, sessions, users, and live systems, given that in an engineered system we can describe the context as a control plane. Context as a control plane is an architectural paradigm in which organizational, behavioral, and situational data (the who, what, and why) serve as the centralized governing layer for system operations, rather than being hardcoded directly into individual applications, AI models, or microservices↳Microsserviços24 conteúdosArquitetura de Microsserviços em Node com o MoleculerJSDev (Back & Front) · jun 2025Segurança das APIs: como proteger seu ecossistema de microsserviçosDev (Back & Front) · dez 2023Você provavelmente não precisa de microsserviços (ainda)Dev (Back & Front) · mar 2026Ver tudo em Dev (Back & Front) →. In our world, this will determine whether an agent acts like a reliable software system. Providing the wrong context highly increases the likelihood of the model hallucinating.

Knowledge of the system is our policies, governance, and hard truth. Knowledge acts as the system's official textbook. It holds core business logic, strict policies, and databases. Back to our omelet example, part of the knowledge would be the need for eggs and a pan.

Memory is the critical layer that bridges historical data and real-time signals into a reasoning-ready state. What needs to be remembered for the current task? This is usually information given from knowledge, historical data, and current live events.

To summarize our three components:

Context - the immediate, active, and temporary information the agent is utilizing at any given moment. It sits directly within the model's active context window (analogous to computer RAM).

Memory - provides persistence. It allows the agent to retain information beyond a single interaction, enabling it to learn from past experiences and adapt to users over time.

Knowledge - the underlying foundation of facts, concepts, and rules that the agent inherently possesses before interacting with the user. It is the domain-specific data used to train or fine-tune the system, or the reference library to which it is granted access. Highly curated data.

Our goal in agentic systems is, when given the task context, system knowledge, and memory, to turn data into the right memory state at the right moment.

Beyond that, there are limitations to this dynamic architecture paradigm; hence, we need to systematically address the economic costs of large language model (LLM) limitations and the technical, architectural roots of hallucinations. As developers and architects, learning to avoid the common "culprits" of agentic systems mismanagement is crucial. Dive in to learn how to design a sophisticated, multi-tiered architecture for the next generation of reliable agentic AI.

Shift into Context Engine

An LLM is only as good as how we use it. While the model generates, our system determines what it sees. To avoid hallucinations, we need a trustworthy system around it. Leveraging context, knowledge, and memory. To architect the system, we will separate the model from the surrounding machinery. Going forward, for the machinery around it, we will call it a context engine.

The context engine is part of the context control plane. This is the orchestrator responsible for selecting, filtering, ranking, structuring, compressing, safeguarding, and delivering information before it ever hits the LLM inference endpoint. It pulls information from knowledge, categorizes it in memory, and determines what the agent's context should be at any given millisecond. This is a meaningful shift from simple prompt engineering to systems engineering.

From Prompts to State/Context Systems

Prompt engineering assumes the task is to craft a better instruction. Context engineering assumes the real task is to build a dynamic substrate that continuously assembles the right state for reasoning. The prompt is no longer about "What should I ask the model?" It is "What is the minimal, highest-value context the model needs in order to reason well right now?"

In a production-grade agentic architecture, we require dynamic systems that dictate what an agent "knows" at any given millisecond. Our system goal is to take what's relevant and compile a new prompt encompassing the required information to improve the model's success likelihood.

Context as a Compiler

To understand how the Context Engine behaves, consider the analogy of a modern software compiler. A compiler translates high-level source code into machine-executable instructions; the context engine translates vast oceans of unstructured, disconnected raw, real-time, and historical data into a structured, reasoning-ready state. It builds a deterministic state machine that allows the probabilistic agent to execute safely. It ensures that inputs are authenticated, validated against business logic, stripped of personally identifiable information (PII), and securely sandboxed before the LLM generates a plan of action.

Thinking Through Architecture

Effective software architecture for autonomous AI agents requires reconciling several fundamentally conflicting paradigms of data management and data flow.

Historical vs. Real-Time Memory Streams

A robust agentic architecture must gracefully balance long-term "episodic" memory with immediate "sensory" input. Meaning that to build a useful context engine, our architecture must reconcile two very different categories of state: historical memory and real-time input.

Historical memory is the long-lived layer. It includes prior interactions, past decisions, user preferences, domain rules, internal documentation, and accumulated observations. This is what gives an agent continuity. It allows the system to behave as though it has experience.

Real-time input is the short-lived layer. It includes the current task, the latest events, live telemetry, fresh tool outputs, and environmental changes. This is what keeps the agent grounded in the present.

While vector databases excel at retrieving historical, semantic facts, agentic workflows frequently pivot on sub-second, real-time context. For example, if an AI DevOps↳DevOps29 conteúdosHabilite o Código de Segurança Azure DevOpsDevSecOps · jun 2025O que é DevOps – minha experiência como executivo nessa frenteDev (Back & Front) · abr 2026DevOps: a automação de processos de TI como estratégia de eficiência operacionalDev (Back & Front) · set 2024Ver tudo em DevSecOps → agent is triaging a server outage, retrieving an architectural runbook from a vector store (episodic memory) is only half the battle. The agent also needs the live error log stream from the last five seconds (sensory memory). The architecture must fuse these batch and streaming sources asynchronously, ensuring the agent acts on a unified, up-to-date reality.

This architecture must have balance. If it over-indexes on history/episodic memory, the agent becomes stale. It will keep replaying yesterday's assumptions into today's reality. If it over-indexes on real-time data, the agent becomes reactive and forgetful. It may respond to the latest signal but fail to incorporate the broader context that gives that signal meaning.

Luckily for us, this tension is not new. Distributed systems have always had to reconcile durable state with transient events. Agent systems inherit the same problem, but with an additional challenge: the reasoning layer is probabilistic, expensive, and bounded by a limited context window. This adds an important layer of constraint optimization to the context architecture design - deciding which information to keep, which can be compressed, which must be revalidated, and which should be excluded entirely. The goal is not just freshness or completeness. The goal is usefulness under constraint.

Figure 1: Historical Data vs Real-Time Memory Streams (Source: created by the author with Gemini)

Knowledge vs. Raw Data ( SELECT * vs. Cumulative Insight)

One of the most common architectural mistakes in AI systems is treating retrieval as if it were enough, ie, operating under the semantic equivalent of a SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → SELECT * , assuming more information must be better. Architectures that attempt to consistently retrieve large volumes of data will inevitably fail at scale. We can think of retrieval as how we get data into the system, yet it does not guarantee that the data is useful, timely, coherent, or appropriately ranked for the decision at hand.

This is what standard RAG pipelines are all about. They are often built to retrieve raw, fragmented, and overlapping data chunks. In actuality, using this approach would most likely result in the system dumping 10 unedited wiki pages into a prompt, making the LLM waste compute cycles trying to sort the noise from the signal - yet failing due to relevant signals buried under less important and more noisy ones. Hence, the right information and shape of the data, which we refer to as knowledge , matter more than raw data.

True Knowledge Curation focuses on cumulative insight . Instead of injecting raw data, the architecture employs background workers/ML pipelines that distill, aggregate, and rank retrieved data by relevance, using the up-to-date system state. To achieve that, we need to build dedicated pipelines that transform raw data into structured knowledge graphs or condensed summaries. For example, taking a large database and creating a pipeline that summarizes a million data entries into one entry every 12 hours. This way, we ensure the model receives a small, synthesized body of knowledge (1 entry point in the database) rather than a chaotic stream of consciousness (the whole database, sometimes).

Custom Context: The End of "One-Size-Fits-All"

Foundational models like GPT-4 and Claude, as well as vector databases like Pinecone and Milvus, have become an accessible commodity. Everyone can access them today through their services. Yet, this is not the same for context; the architectural principles for working with context are highly domain-specific. Every company should design its own context based on the business domain and the product it serves.

For example, a fintech firm might choose to curate context for an autonomous fraud-analysis agent by prioritizing transaction timestamps, geolocation anomalies, and strict compliance rules. This will look entirely different for a legal tech firm. A legal tech firm might choose to curate context based on state law for use with an agent that generates contracts. We are learning that the context itself cannot be generic; it must reflect the unique domain logic, security boundaries, and vocabulary of the specific product.

The Context Lifecycle: Managing Knowledge & Hallucination at Scale

Treating context as a continuous lifecycle allows us, as engineering teams, to manage knowledge systematically and directly address the root causes of model failure and prohibitive inference costs.

The Lifecycle Stages

Generally speaking, there are 4 stages: Selection, Injection, Compression, Expiration & Refresh. Figure 2 describes how each stage could be a dedicated module in our architecture or a standalone service.

Figure 2: Agentic AI Systemic Context Lifecycle (Source: created by the author with Gemini)

Selection (Retrieval & Filtering)

The first and most important step. This is where the system identifies which data points are likely to matter for the current task. The system's goal is to identify the absolute highest-value data points across multiple data stores. Advanced architectures have moved beyond simple cosine similarity in vector spaces, implementing hybrid search algorithms that combine dense semantic search with sparse keyword search (e.g., BM25) and knowledge graph traversal to ensure precision.

In this process, we want to understand intent, task type, risk, user role, and temporal relevance. It is important to remember that the same underlying corpus may yield different contexts for a troubleshooting agent, a research agent, and a support summarization agent. This is where architecture begins to diverge from product. As part of the design requirements, we need to identify and define what is risky and what is actionable.

Injection

Once the system knows what matters, it has to place that information into the model's working context (aka context window) in a useful form. While the end result might look like simple string concatenation, the path to getting there requires more deliberate design. That design involves semantic templating, ensuring the data is formatted to match the user's explicit intent, including necessary system instructions, few-shot examples, and output schema constraints (such as JSON definitions). To understand the importance of this step, consider how it affects the entire system. In our world, this placement of information changes how models reason. Hence, order, grouping, and structured state matter.

Compression (Summarization & Distillation)

Processing a large context is expensive. To respect token limits, historical data should be iteratively compressed. Utilizing smaller, faster LLMs (or even deterministic algorithms) to summarize conversation histories or condense long documents saves massive amounts of space and reduces latency for the primary reasoning model. Test summaries carefully to avoid distortions. There are statistical models available today to assess summary validity, such as the Perplexity (PPL) Ratio, Token-Level Kullback-Leibler (KL) Divergence, the Chi-Square Test for Categorical Outputs, and others.

Expiration and Refresh

Context that never expires eventually turns into a liability. Agents need mechanisms to retire stale assumptions, refresh live facts, and separate durable truths from temporary observations. A system preference might remain stable across months or change overnight. A product configuration might change in minutes. A support incident may be relevant for a day and misleading a week later.

Without expiration and refresh, systems fall into stale data loops: they keep reusing context that was once correct but is now simply persuasive. Hence, constantly testing and validating the system through feedback loops is a must. This should be tailored to the system's end goal. For example, in a car-sharing system, the goal is to satisfy users; hence, if user satisfaction drops suddenly, it's best to explore underlying factors that may need refreshing.

Hallucination Is Often a Context Failure

LLM hallucinations are rarely the result of a "broken" model; they are almost always the symptom of an unmanaged, impoverished context window. Because LLMs are probabilistic, when an agent lacks the explicit, factual data required to answer a prompt or execute a task, its underlying mechanism forces it to "guess" based on latent training weights.

Proactive context management acts as a strict guardrail. By saturating the model with highly relevant, high-confidence knowledge and explicitly instructing it to reason only based on the provided context , we can effectively suppress latent, inaccurate associations. In a productionized agentic system, a well-engineered context engine becomes our primary defense against hallucinated actions.

Token Economics: The Cost-to-Performance Trade-off

Processing a large context is notoriously expensive. Every token injected into the prompt window incurs both a computational latency cost and a strict financial cost. Token Economics is the engineering discipline of optimizing "attention real estate" within the LLM's limitations.

The recent expansion of context windows (e.g., models boasting 128k to 1M+ token limits) has tempted developers towards lazy architecture. They dump entire code repositories or massive troves of documents into the prompt. This drastically increases Time-to-First-Token (TTFT) latency, skyrockets API billing costs, and, ironically, degrades model performance. The model suffers from the "Lost in the Middle" phenomenon, shown in Figure 3.

This problem was identified by Stanford researchers Nelson F. Liu et al. in 2023, where the model fails to retrieve facts buried in the center of massive context windows and only focuses on edge case information. The larger the bottom part of the U shape (context window), the less accurate the response will be. This research explains why we want the context sent to the model to be relatively small. This approach makes the U bottom part smaller as well - hence, improving outcomes.

Architects must weigh the marginal utility of every retrieved document against its token cost and relevancy. Just because we can send 100,000 tokens doesn't mean we should . Strict context budgeting, iterative pruning, and caching mechanisms are mandatory for scalable economics.

Figure 3:

Fonte: InfoQ