Everyone Is Building the Same Context Engine

Most agent products quietly turn into the same system.

One feature gets a search service. Another gets a background job that updates a user profile. A third gets a prompt builder, an evaluation step, and a table of failures. Soon the model call is the smallest part of the application. The real product is a data pipeline whose final consumer happens to be an agent.

We think that pipeline is a missing software layer: a context engine. Its job is to turn changing evidence into the right context for one task, at one moment, with a record of why each piece is there.

Across seemingly different agent architectures, that job keeps decomposing into the same eight moves: collect records, enrich them, derive new state, trigger work, retrieve what matters, assemble context, evaluate the result, and feed the outcome back.

We did not start with that theory. We backed into it by building a scheduling assistant.

The model call was the easy part#

Our daily digest sounded simple: fetch tomorrow’s calendar, find the active scheduling conversations, and produce a briefing for email and WhatsApp. But calendar records had to stay searchable. Events had to be selected for one user, in one timezone, for one morning. The result had to fit a token budget and render differently for each channel.

Calendar enrichment needed the same machinery in another shape. A source calendar says a meeting starts at 2:00 PM; it does not say whether the user needs travel time, whether the event requires preparation, or whether it is part of a recurring pattern. We had to compute those values, attach them to the event, and recompute only when relevant source fields changed.

The meeting-time recommender did it again. It combined similar meetings, the user’s current scheduling profile, free slots, nearby events, attendee timezones, and the live conversation. Evaluators rejected conflicts and bad buffers, then returned their reasons so the next attempt would not repeat the same mistake.

These looked like three features. In the code, they were three arrangements of one system:

The records changed—events, conversations, contacts, preferences, rejected slots—but the lifecycle did not. Once we saw it, “agent memory” started to feel like too small a name for the problem.

Retrieval cannot tell you what is true now#

The usual answer is to put events and messages in a vector database and search before each model call. That works until the application needs to know what remains true.

Suppose a user once preferred breakfast meetings and later changed jobs and stopped taking calls before 10:00 AM. Both statements are semantically similar to a query about scheduling preferences. Retrieval can find them; it cannot, by itself, tell you which one should govern tomorrow’s recommendation. That requires a maintained interpretation of changing evidence.

Even the correct records are not yet useful context. A daily briefing needs a chronological slice of tomorrow’s calendar. A recommender needs similar past meetings, current preferences, hard constraints, and nearby events. Selection, ordering, budgets, and formatting are application behavior—not incidental string handling.

A vector database asks which records look similar. A memory store preserves what happened. A context engine answers the larger question:

What should this agent know for this task, right now, and what evidence made it so?

Memseek is our attempt to build that layer as an open-source, declarative context engine. An application records what happens. Memseek enriches those records, maintains useful conclusions, retrieves the relevant evidence, and assembles task-specific context. Outcomes return as new evidence instead of silently rewriting a prompt.

Eight moves, four things to define#

The abstraction became clearer when we stopped naming components after product features. The eight runtime moves reduce to four things programmers define: collections, derivations, views, and artifacts.

A collection is the typed home for one kind of record. It defines what a valid calendar event, observation, profile fact, or learning signal looks like; which fields can be filtered; and which enrichment such as embeddings or importance scores should run. It is closer to a table plus an indexing policy than to a folder of text.

A derivation is a bounded computation that turns records into new, cited records. New conversations might update a current profile. Important memories might produce a reflection. Evaluator failures might draft a better procedure. Its output returns to ordinary storage with links to the evidence that produced it, so conclusions can be inspected, superseded, or withdrawn.

A view is a named, parameterized retrieval plan. One view can mean “all events between these dates, ordered by start time.” Another can combine keyword and vector search over memories, plans, and reflections. The application calls the name and supplies parameters instead of rebuilding retrieval logic in every feature.

An artifact assembles views and maintained records into the exact context a consumer needs, with a token budget for each block and a manifest of what was included. It is not the model’s answer. It is the versioned input that made the answer possible.

For a scheduling assistant, the design might read roughly like this. The production definitions live in separate files; this is compressed to show the shape rather than serve as a copy-paste configuration:

# collections/calendar.yaml
collections:
  - name: calendar_events
    mode: event
    schema: {required: [title, starts_at, ends_at]}
    optional_processors: [embedding, importance]

# derivations/profile.yaml
name: scheduling_profile
sources:
  new_events: {kind: changes, collections: [calendar_events]}
  current: {kind: current, collections: [profiles]}
tasks:
  - {id: update, use: llm}
emit: {from: "{{update.records}}", collection: profiles, type: fact}

# views/tomorrow.yaml
views:
  - name: upcoming_calendar
    parameters: {entity: string, start: datetime, end: datetime}
    query:
      mode: structured
      scope: {collections: [calendar_events]}
      where: {starts_at: {gte: "{{start}}", lt: "{{end}}"}}
      order_by: [{field: starts_at, direction: asc}]

# artifacts/daily_briefing.yaml
artifacts:
  - name: daily_briefing
    blocks:
      profile: {collections: [profiles], max_tokens: 1500}
      calendar: {view: upcoming_calendar, max_tokens: 3000}
    template: |
      CURRENT PROFILE:
      {{profile}}
      TOMORROW'S CALENDAR:
      {{calendar}}

The point is not that YAML can express a prompt. It is that the sources, enrichment, retrieval, budgets, and exact assembly are explicit—and can be validated together before production.

Declarative does not mean no code#

“Put it in YAML” is not an architecture. A bad declarative system merely moves programming into a worse language. Memseek keeps a deliberate boundary: common context behavior is declared, while specialized computation remains code.

The declaration answers operational questions. What records may this process read? What causes it to run? How many records and tokens may it consume? Which model alias may it call? What schema must the output satisfy? Where will that output be stored? Does it become active immediately or wait for review?

Code still implements a contact merger, domain-specific scorer, or calendar conflict checker. Those functions are registered as tasks and invoked under declared limits. It is the same split that makes SQL useful: queries are declarative even though database operators are programs.

This separation matters more when models are involved. A conventional function usually fails the same way on the same input. A probabilistic transformation can vary, exceed its budget, or produce a plausible value that should not become live state. The runtime needs boundaries around the model call: schemas, citations, concurrency checks, budgets, and review.

Context engineering is becoming backend engineering. The prompts still matter, but so do migrations, data ownership, retries, observability, provenance, and rollback. Treating the entire problem as prompt composition is like treating a web application as HTML generation.

Different architectures, the same eight moves#

It is easy to extract an internal framework from one product and give it a grander name. The useful test was whether Memseek could express architectures created by other teams for different reasons.

This claim should be falsifiable. If these systems share a substrate, we should be able to describe each one without inventing a new kind of infrastructure:

Their centers of gravity differ: reflection, periodic reorganization, progressive abstraction, local retrieval, or graph consolidation. But none requires a ninth move. The records, ranking, triggers, and consumers change; the lifecycle does not.

The examples use the same Memseek runtime. There is no “gbrain mode” or Generative Agents subsystem hiding underneath. Memseek ships runnable examples of the Generative Agents reflection pattern, TencentDB’s L0–L3 progression, and gbrain’s graph and dream cycle. The distinctive behavior lives in the definitions: which records exist, when work runs, how views rank, and what context an artifact assembles.

YAML is not the point. Reviewability is.#

The payoff is not fewer lines of Python. It is making agent behavior inspectable before the agent runs.

If a pull request changes a scheduling profile derivation, a reviewer should be able to see that it now reads rejected recommendations, uses a different model, and may update three profile keys instead of one. If a context artifact doubles the token budget allocated to reflections, that should appear as an ordinary diff. If a new definition references a collection that does not exist, it should fail at deployment rather than after a user receives a strange answer.

Context also changes meaning over time. A record created under one schema should not be silently reinterpreted under another. A conclusion should retain the derivation version and evidence that produced it. An unexpected model response should be traceable to the context the model actually saw—not the context we think it probably saw.

This is why Memseek stores evidence immutably and represents correction through supersession rather than in-place edits. It is why derived claims cite their inputs, and why reviewed derivations can stage drafts instead of activating their own conclusions. The system does not make model reasoning deterministic. It makes the surrounding behavior legible.

Learning needs the same discipline. When a recommendation fails, Memseek binds the outcome to the artifact that produced it. A derivation can then propose a changed profile or procedure. An agent quietly rewriting its production instructions is not learning; it is an unreviewed deployment.

The context layer is where the agent becomes your product#

Models will continue to improve, and applications will switch between them. The part that makes a scheduling agent understand one person’s working life is not stored in the base model. It is the current calendar, the history of decisions, the user’s maintained preferences, the procedures that survived real outcomes, and the rules deciding which of those things matter for the next request.

Raw transcripts are only evidence. The durable asset is the maintained interpretation connected to it: what is current, what was contradicted, which procedure worked, and which source supports the conclusion. Two products can call the same model and index the same documents while behaving differently because their context systems have accumulated different judgment.

That layer should be open and application-owned. It sits too close to product behavior and user data to become an opaque vendor-side prompt cache. Teams should be able to inspect the definitions, choose where records live, change model providers, export evidence, and understand why an agent saw something.

The category is broader than memory. Memory asks how experience survives. Context asks how evidence becomes useful state for a particular decision. Search, profiles, reflections, knowledge graphs, prompt assembly, and feedback are not separate islands once they all operate over the same records and provenance.

We open-sourced the layer we wanted#

Memseek is not an agent framework. It does not decide which tool an agent calls next, and it does not require an application to adopt a particular model SDK or workflow graph. It is not a new vector database either; PostgreSQL and pgvector remain very good at storing and retrieving data.

Memseek owns the boundary between changing evidence and the context an application serves: typed records, enrichment, cited derivations, named views, artifact assembly, versioned definitions, and a path from outcomes back to reviewable improvements.

We extracted it because we did not want the next feature to create another private search index, another profile updater, another prompt builder, and another feedback loop. Since then, the architectures we have mapped onto it have strengthened the original intuition: many teams building agents are independently assembling a context engine without having a name for it.

If your agent already has a retrieval service, a profile updater, a prompt builder, and a table of outcomes, you may be building one too. We would like to know whether Memseek can express yours—and, more importantly, where the abstraction breaks.