What is a context-only agent memory pattern?

Short answer: Pattern One stores nothing beyond the current request: prompt, live tools, and the conversation slice you pass.

No Engram, no cross-session profile. It fits short tickets, one-shot work, and zero-retention needs. It breaks on multi-week continuity, multi-agent shared experience, and tasks that outgrow the window. Start here while learning the task; graduate when you can name the cross-session question persistence must answer.

Pattern One is the agent that remembers only what fits in the current request. There is no Engram project, no vector index of past turns, and no cross-session profile. The system prompt, the tools results for this job, and whatever conversation slice you still pass are the entire memory. Session ends, continuity ends. That sounds primitive after chapters on prune jobs and reconsolidation. It is also the right architecture for a surprising amount of production traffic. Short tickets, one-shot transforms, and zero-retention workloads do not need a durable memory layer. They need a clean context window.

This chapter defines the context-only pattern, when it wins, where it breaks, how to implement it without accidental persistence, and how to recognize the moment you should graduate to an external store such as Weaviate Engram. Flat vector memory is the usual next step when Pattern One stops fitting.

What does “no persistent memory” actually mean in an agent runtime?

After purposeful forgetting, it is fair to ask whether you needed a store at all. Pattern One answers yes to that question for specific jobs. The LLM is always stateless between API calls. Persistence lives only in your runtime. In this pattern the runtime keeps, at most, an in-process message list for the active session. It does not call memories.add. It does not search prior users. When the process exits or the HTTP request finishes, nothing remains for the next visitor.

Industry pattern catalogs place this first for a reason. Everything lives in the prompt: instructions, the current document or ticket, and optional short history. The agent is a passive recipient of curated context. There is no memory framework to tune. Governance is simpler because there is less to erase.

Do not confuse Pattern One with “paste the entire company wiki into the window.” That is still context-only storage, but it is a poor context-engineering choice. Lost-in-the-middle effects, rising latency, and linear token cost still apply. Pattern One done well keeps the window small and task-shaped.

When is context-only the correct production choice?

Once the definition is clear, the fit criteria are practical. Use Pattern One when the whole relevant state fits in one or a few turns. Classification, extraction, rewriting a single label, and summarizing one uploaded file usually qualify. Use it when policy demands zero retention and you must not write conversation data to disk. Use it for high-throughput batch pipelines where a memory round-trip would dominate latency. Use it when reproducibility matters more than personalization. The same inputs should yield the same agent behavior without hidden profiles.

Median support threads that resolve in a handful of turns often stay inside one window. For those flows, Engram is optional overhead. A fixed system prompt plus the ticket body is enough. Save the memory budget for products that greet returning users or run multi-week projects.

Also prefer Pattern One while you are still learning the task. Stateless agents fail loudly. Stateful agents fail by citing last month’s wrong preference. Start simple. Add persistence when you can name the cross-session question the agent must answer.

Where does the pattern break, even with large context windows?

Knowing the wins, respect the cliffs. Cross-session continuity is impossible by construction. The agent cannot learn that a gallery always wants sentence case wall labels unless you resupply that rule every time. Multi-agent workflows that split one logical job across windows cannot share experience without an external store. Long tasks that exceed the effective context length degrade even when the nominal limit is huge. Cost grows with every replayed token.

Weaviate’s Engram writing is blunt about the naive alternative. Stuffing ever-longer history into each call raises latency and spend, and models still miss middle content. Storing raw transcripts without maintenance creates a different mess. Pattern One avoids the second mess by refusing storage. It does not escape the first mess if you abuse the window.

Watch for accidental persistence. Logs, analytics warehouses, and tool side effects can retain what you thought was ephemeral. If compliance requires true context-only behavior, audit the whole path, not only the LLM client.

What does a disciplined context-only loop look like?

Imagine a museum prep agent on gallery-wall-label-desk-2. Each request is one label draft. Nothing should survive for the next artwork.

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

SYSTEM = (
    "You are a wall-label editor for gallery-wall-label-desk-2. "
    "Use sentence case. Keep body text under 60 words. "
    "Do not invent accession numbers. "
    "This session has no memory of other artworks."
)

def edit_label(artwork_title: str, draft: str, notes: str = "") -> str:
    # Pattern One: only this request's materials enter the model.
    messages = [
        {"role": "system", "content": SYSTEM},
        {
            "role": "user",
            "content": (
                f"Artwork: {artwork_title}\n"
                f"Curator notes: {notes or '(none)'}\n"
                f"Draft label:\n{draft}\n\n"
                "Return the revised label only."
            ),
        },
    ]
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
    )
    return response.choices[0].message.content

print(
    edit_label(
        "Blue Harbor, 1912",
        "This stunning masterpiece shows boats in a harbor at dusk.",
        notes="Avoid masterpiece. Mention oil on canvas.",
    )
)

# No EngramClient. No transcript append across artworks.
# A second call starts from SYSTEM + new draft only.

The important absences are the architecture. There is no user id, no search, and no post-turn write. If a later product asks “apply the same voice rules we approved last month,” Pattern One cannot answer without pasting those rules back into SYSTEM or moving to a persistent store.

How do you know it is time to leave Pattern One?

Graduate when operators paste the same preferences into every ticket. Graduate when users expect the agent to remember prior visits. Graduate when multi-session decision archaeology matters. Graduate when token charts show history replay dominating cost. At that point, keep the disciplined context window for the live turn, and add an external memory service for durable facts.

Weaviate Engram is built for that graduation. You keep recent messages for local coherence and search maintained memories for long-term personalization. You do not have to jump straight to graphs or tiered OS-style memory. The usual next architecture is a flat vector-backed memory store with scoped writes and hybrid retrieval.

Our next chapter, What is flat vector store memory?, covers that first persistent design and how Engram implements it as searchable memories rather than raw transcript replay.