Current Memory: The Agent's Loaded Brain

The fastest way to make an agent feel prepared is to give it a memory file.

The fastest way to make that same agent feel haunted is to keep adding to it.

At first the notes are helpful: use pnpm, run the smoke tests, the API client lives in src/lib/api, do not publish without approval. Then the file starts collecting everything that ever hurt once: a failed Windows build, a temporary migration plan, a user preference from one project, three paragraphs about a bug fixed two weeks ago, and a solemn instruction to “be careful.”

Congratulations: the agent has memory. Unfortunately, it is now starting every run with a backpack full of receipts.

Current memory is the part of agent memory loaded before work begins. It is the small set of instructions, rules, identity, constraints, and pointers that shape how the agent behaves. In the load / carry / recall model, this is the load layer.

The trick is not to make current memory empty. The trick is to make every item earn its seat.

Current memory should be the agent’s launch checklist, not its attic.

This is the second article in the local agent memory series. How Agent Memory Actually Works introduced the full load / carry / recall map; this piece goes deep on load, the context an agent starts with before work begins. The planned follow-ups cover short-term working state and long-term recall.

What Current Memory Is For

Current memory answers one question:

What should this agent know before it starts almost any run in this scope?

That last phrase matters. A personal coding preference, repository convention, and organization-wide security policy may all be useful, but they should not all apply to the same work.

Good current memory usually contains the agent’s role, stable project rules, coding conventions, workflow boundaries, source-of-truth pointers, common commands, and compact notes the agent would otherwise need re-explained every session.

Anthropic’s Claude Code docs make this concrete with CLAUDE.md: a place for persistent instructions such as coding standards, build commands, project layout, and workflow rules. The docs also separate managed, user, project, and local instruction scopes, which is the practical detail many memory designs skip.

Scope is how you stop “I like compact examples” from becoming company policy.

Current memory should feel boring in the best way: stable enough that tomorrow’s task still wants it, specific enough that the agent can act on it, and short enough that you do not resent paying for it every run.

The Junk Drawer Test

Imagine this project memory:

Use pnpm.
Always write tests.
The current article topic is current memory.
The last image build failed because hero.webp was missing.
The user prefers short paragraphs.
Full notes from the June migration attempt...
Never publish without explicit approval.
Be careful with security.

Some belongs in current memory. Some belongs elsewhere. Some should become code.

Use pnpm is a stable project convention. Good current memory.

Never publish without explicit approval is a boundary the agent should see, but if publishing can do damage, it also deserves deterministic protection: workflow checks, permissions, or a command that requires confirmation. Memory is a reminder, not a lock.

The current article topic is current memory is active task state. Carry it in the session, a plan, or a task file. Do not teach the agent that every future run is about this article.

The last image build failed because hero.webp was missing is an episode. Store it in a troubleshooting note with a date and project scope. Retrieve it when image builds fail; do not load it forever.

Full notes from the June migration attempt is archival material. Link to it. Do not paste it into startup context unless every task needs the whole thing.

Be careful with security is too vague to help. Replace it with specific rules or checks: do not log secrets, never send .env contents to external tools, run the security test suite before release.

That sorting habit is the whole game.

Guidance Is Not Enforcement

This is the line worth writing near the coffee machine:

If a rule must always happen, do not rely on the model remembering it.

Claude Code’s memory docs state that CLAUDE.md and auto memory are loaded as context, not as hard enforcement. For behavior that must happen regardless of what the model decides, the docs point to hooks, managed settings, and related configuration.

That distinction generalizes. OpenAI’s Agents SDK describes agents as configured with instructions, tools, and optional runtime behavior. Instructions shape the run. Hooks, guardrails, schemas, permissions, tests, and ordinary code can enforce or observe specific behavior.

Use current memory for guidance:

• “Prefer small, focused changes.”
• “Production deploys require approval.”
• “Check the design notes before creating a new service.”

Use deterministic mechanisms for hard requirements:

• blocking destructive commands,
• validating structured output,
• requiring approval before publishing,
• preventing secret exposure,
• running tests before release.

The agent can miss a sentence. Your CI pipeline is less poetic, but it has better recall under pressure.

Dynamic Context Still Counts

Current memory does not have to be one static file.

OpenAI’s Agents SDK supports static instructions, dynamic instruction callbacks, prompt templates, and typed run context passed through agents, tools, handoffs, and hooks. That matters because some startup context is stable, while some should be assembled for the run.

A support agent might always load its role and escalation policy, then dynamically receive the user’s plan tier, locale, and ticket ID. A coding agent might always load repository conventions, then receive the branch name, active task, allowed tools, and test command for this run.

That is still current memory in the practical sense: context available before action. But it should not all share one storage place or lifetime.

Stable instructions:
  Role, rules, project conventions, boundaries.

Dynamic run context:
  User, task, permissions, environment, active resources.

On-demand context:
  Skills, docs, decisions, examples, troubleshooting notes.

LangChain’s context-engineering docs reinforce the same principle: agents work better when the model receives context relevant to the current step, not every possible note the system can reach.

Loaded context is expensive real estate. Treat it like the top of a workbench. The hammer can stay there. The box of old receipts can go somewhere else.

What To Move Out

A current-memory file usually goes bad slowly. Nobody wakes up and decides to create contradictory markdown lasagna. They add one reasonable note at a time.

Audit by asking where each item should really live.

Move active task state into sessions, plans, checkpoints, or scratch files: current goals, pending subtasks, recent decisions, failing tests, and reviewer feedback.

Move detailed procedures into skills, runbooks, or on-demand docs: publishing workflows, release processes, incident response checklists, migrations, and image generation procedures.

Move area-specific rules into path-scoped rules where your tool supports them: frontend conventions, API validation rules, test fixture style, or docs-only guidance.

Move durable facts and experiences into long-term records: architecture decisions, past incidents, user preferences, lessons from failed builds, and research notes with provenance.

LangChain’s memory overview helps keep the layers separate: short-term memory tracks the ongoing thread, while long-term memory stores information across sessions or namespaces. Current memory is neither the whole thread nor the whole archive. It is the small loaded layer that helps the agent start well.

The Current Memory Audit

When memory starts to sprawl, review each line with six questions:

1. Should this shape almost every run in this scope? If not, move it to task state, a skill, a scoped rule, or long-term recall.
2. Is it stable? If it expires after this task, it is working state wearing a fake moustache.
3. Is it specific enough to follow? “Write good code” is mood lighting. “Use 2-space indentation in Astro files” is instruction.
4. Is the scope explicit? User, project, repository, organization, agent, and subagent memory should not blur together.
5. Can a human inspect and edit it? Agent-written memory needs auditability.
6. Should this be enforced instead? If ignoring it would cause data loss, security exposure, publication mistakes, or broken releases, add a deterministic check.

This audit keeps current memory useful without making it precious. Some notes stay. Some move. Some become tests. Some deserve a tiny ceremony where everyone admits they were temporary and deletes them.

A Better Loaded Brain

A healthy current-memory file is short enough to scan and concrete enough to act on:

Project: Atlas Checkout
Audience: engineers maintaining payment and account flows.
Mission: make safe, incremental changes with clear validation.
Deploy boundary: production changes require explicit approval.
Coding rule: prefer focused diffs and preserve backward compatibility.
Pointers:
  - Check service contracts before changing payload shapes.
  - Run checkout and account tests before shipping.
  - Read architecture notes before adding a new dependency.
Enforcement:
  - CI, permissions, and release gates enforce the rules; memory is not the lock.

That gives the agent a useful shape without stuffing the whole publication history into its head.

The important part is not the exact format. It is the discipline: current memory should make the first action better, not drag every old action into the room.

The Last Sip

Current memory is powerful because it is always there. That is also why it is dangerous.

Load the context that should shape almost every run: identity, mission, project rules, conventions, boundaries, and pointers. Keep it concise, scoped, specific, and auditable. Move active state, long procedures, historical records, and occasional knowledge out of the startup path. And when a rule must hold no matter what, enforce it with code, configuration, tests, permissions, or workflow checks.

The loaded brain should help the agent wake up oriented. It should not make the agent start every morning rereading the garage.

Sources On The Counter

• Anthropic’s Claude Code memory docs explain CLAUDE.md, scoped rules, auto memory, audit/edit flows, and why memory files are context rather than hard enforcement.
• OpenAI Agents SDK Agents grounds the article’s distinction between static instructions, dynamic instructions, run context, hooks, and other runtime behavior.
• LangChain’s context-engineering docs support the idea that agents should receive selected context for the current step, not every reachable note.
• LangChain’s memory overview helps keep current memory distinct from short-term thread state and long-term namespace-scoped memory.