Suppose your AI coding agent has saved the project's build requirements, past decisions, and previous fixes. You ask it to repair an Android continuous integration (CI) build. Which records should it load before changing the workflow?

The Java requirement gives it a useful first check. A past Redis decision probably does not.

Memory isn't context. Memory keeps what the project has learned. Context is what the agent receives for one task. The engineering problem is choosing that subset without losing instructions that still apply.

Let's work through one build failure, a small selection model, and the limits of that model.

The obvious idea

Consider a made-up project. Its Android CI build is failing. Across earlier sessions, the team has saved six facts:

  • Build requirement: this project's Android build requires Java 17.
  • Project rule: the developer says never to write directly to the production database. The rule applies to all project work.
  • Authentication: the project uses Cognito.
  • Billing: a legacy retry workaround exists in the billing module.
  • Naming decision: UserService became AccountService because the old name no longer described its responsibilities.
  • Architecture decision: Redis was evaluated and rejected; the reasoning was recorded.

Keeping these facts saves repeated investigation. The Java requirement survives a new conversation. So does the reasoning behind the Redis decision.

An AI assistant places the Java 17 requirement and the project-wide production database rule in an Android CI work tray, leaving four unrelated records in the archive.
Android CI: use the Java 17 requirement and the project-wide database rule. Keep the other four records in memory.

Why remembering everything is not enough

The next request is “Fix the Android CI build.” Sending all six records makes the agent sort through unrelated history before checking the build.

Two records have a clear job here:

  1. The Java 17 requirement tells the agent what to check in CI.
  2. The production database rule still governs its work, even though the request says nothing about databases.

There is no established link to Cognito, billing, the rename, or Redis. Keep those records in memory. Leave them out of this task's initial context. If the investigation reaches billing, select context again with that new scope.

Memory is storage. Context is a decision.

Memory answers “What do we know?” Context selection answers “What does this task need?”

The distinction is visible in our example: six records remain stored, but only two are sent to the agent.

Memory → selection → contextSame memory. A smaller handoff.

Task Fix the Android CI build.

  1. Start with six records
    • Java 17 build requirementSelected
    • No direct prod DB writesSelected
    • Cognito authenticationKeep stored
    • Billing retry workaroundKeep stored
    • AccountService renameKeep stored
    • Redis rejection rationaleKeep stored
  2. Send two to the agent

    Check scope and authority, then relevance and budget.

    Required · project-wideNo direct prod DB writes

    A constraint that still applies.

    Relevant · Android buildUse Java 17

    A fact that helps this task.

  3. Begin the investigation
    Next checkDoes CI use the Java version this build requires?

    Compare the current CI setup with the saved requirement.

    Context is a starting point, not a build fix.

All six records stay in memory. Only the two that apply to this task enter its starting context. Selection does not delete the other four.

Selecting fewer records does not delete the others. It gives the agent a useful starting point while leaving room for source code, tool output, and the actual investigation.

Different knowledge has different meaning

A saved record needs more than its text. Three questions matter:

  • Where does it apply? The Java requirement belongs to the Android build. The database rule applies project-wide.
  • Who established it? A developer's explicit instruction differs from an agent's observation.
  • What kind of record is it? A rule constrains work. A decision explains a choice. A discovery supplies evidence.

These labels help selection. They are not a universal taxonomy. Calling a record an “instruction” does not prove that the developer authorized it or that it applies everywhere.

Required vs relevant

Separate what must be included from what would help.

In this example, the database rule is required because the developer made it a project-wide instruction. A low similarity score for “Android CI” must not remove it.

The Java 17 fact is relevant because it helps diagnose the build. Useful background can be ranked and selected within the available space. An applicable mandatory instruction cannot quietly lose that competition.

Required ≠ relevantTwo reasons to include knowledge.
  1. Keep the applicable rule
    RequiredNever write directly to the production database.
    Source
    Explicit developer instruction
    Scope
    Whole project

    It governs this work even when the task says nothing about databases.

    Include before relevance ranking.
  2. Add useful background
    RelevantThis Android build requires Java 17.
    Source
    Saved build requirement
    Scope
    Android build

    It gives the agent a concrete check for this failing build.

    Rank and fit in the space left.
Starting contextDatabase rule + Java 17 requirement

One constrains the work. One helps the investigation.

If required instructions don’t fit: report incomplete context. Don’t silently drop a rule.

Both records enter the Android CI context for different reasons: one constrains the work, the other helps diagnose it. These roles depend on this example’s scope and authority.

Scope still matters. A rule limited to database migrations would not automatically govern this build task. If a rule's scope is unclear, resolve that question or report it. Do not treat “unknown” as “does not apply.”

Authority matters

Suppose the selector finds the Redis decision. It should read that as “this option was evaluated and rejected,” not invent a permanent ban on Redis.

The same applies to discoveries. An agent observing a billing workaround has learned something useful. It has not created a new developer instruction.

For example, a stored rule might retain these fields:

id: no-prod-write
text: Never write directly to the production database.
scope: whole-project
source: explicit-developer-instruction

These fields explain the example; they are not a storage schema to adopt. The point is to preserve the rule's source and scope. Authority tells us what may constrain the work; it does not prove that every stored factual claim is still true.

Deterministic selection

Once scope and authority are known, many checks belong in code. A selector can collect applicable rules, check their size, and then choose useful background.

Here is a simplified model. It assumes scope and authority have already been resolved. Treat required as a validated policy flag. An agent cannot make its own observation mandatory by setting a label. The helpers stand in for scope checks, token counting, and ranking. This is illustrative pseudocode, not a library API.

applicable = [
    fact for fact in memory
    if scope_matches(fact.scope, task)
]
required = [f for f in applicable if f.required]
if tokens(required) > budget:
    return NotReady("Required instructions exceed budget")

optional = [f for f in applicable if not f.required]
candidates = relevant_to(optional, task)
context = required + rank_and_fit(
    candidates, task, budget - tokens(required)
)

For the Android task, the intended result is the database rule plus the Java 17 requirement. The other four records stay available for later work. Given the same inputs and explicit policy, those checks should be reproducible. Relevance ranking may still use a model.

The selection is a starting point, not a build fix. The Java 17 record could be stale. Check the current build files and CI configuration before changing them.

This is the boundary I’m working on in Curator: preparing a useful starting context without treating every saved record as a rule. The agent still has to investigate the build. Persistent knowledge should help that investigation, while keeping the project’s constraints intact.

Context has a budget

A model processes text in chunks called tokens. Its context window limits how many tokens it can use at once. A project-context budget is the share we choose to spend on stored project knowledge. Code, conversation, and tool output need space too.

Reserve space for applicable required instructions first. Use the rest for relevant facts. If the required set does not fit, report incomplete context. Narrow the task, adjust the allocation, or remove duplication without changing the rules' meaning. Do not silently drop a rule and claim readiness.

The caller decides what to do next. The selector must make the missing context visible.

What should use an LLM — and what should not

A large language model (LLM) can help interpret an ambiguous task, find related decisions, or summarize a long investigation. Searching saved facts by meaning can use embeddings: numeric representations of text. That search does not require a model to generate an answer.

Those tools do not need to renegotiate a known project-wide rule or decide whether a measured budget was exceeded. Keep explicit checks in code. Use interpretation where the relationship is uncertain. A summary must preserve an instruction's meaning and authority.

An illustrative Android CI workspace with the task, Java 17 and database rule, current code, and failed-build logs.
Use selected project facts alongside the task, current code, and build logs.

Try this on the next task

Before handing stored knowledge to an agent:

  1. State the task and the part of the project it touches.
  2. Resolve which instructions apply and who authorized them.
  3. Include that required set, then select the facts that help.
  4. Check the budget and report unresolved or missing required context.

For our example, the handoff could be this small:

task: Fix the Android CI build.
required:
  - Never write directly to the production database.
relevant:
  - This project's Android build requires Java 17.
next_check: Compare CI's Java setup with the build requirement.

This is an illustrative handoff, not a schema to adopt. It gives the agent a concrete next check and an applicable constraint. The Redis decision has not been forgotten. It is waiting for a task that needs it.

From the idea to Curator

The Android example ends with a small handoff: one applicable rule, one useful build fact, and a next check. A real project needs to make that choice again when the task changes. It also needs to keep useful findings from the investigation for later work.

In Curator, I make task preparation explicit. The agent supplies the task’s purpose and scope and receives selected project context. During work, it records durable findings; closing the session adds them to local project knowledge. The next task needs a new selection. Recording a finding does not make it a mandatory instruction.

The examples and pseudocode in this article explain the design problem, not Curator’s internal implementation.

Memory keeps the knowledge available. Context gives it a job in the current task. If you’d like to try this workflow, take a look at Prodero Curator.