← Back to all posts

AI & Building

Agent Harness Memory Loop — Four Tiers, Feedback Loop, and Load Gates

External memory is four tiers in practice — short-term, operational, evergreen, and a feedback loop hardened into rules and footers. The harness gates when each tier loads so you keep control without token bloat.

·6 min read
Agentic AIAI MemoryObsidian
Agent Harness Memory Loop — Four Tiers, Feedback Loop, and Load Gates

Series: Cursor Agent Harness (Part 2 of 3)
Part 1: Lightweight harness without a microservice — you keep model and mode control
Memory foundation: Four tiers of external memory · External Memory series hub · Governance layer

The problem: memory everywhere means tokens everywhere

External memory works when agents read the same files in the same order every session. It fails when every tier loads on every turn: vault Session Summaries, brain-pack gotchas, MCP Obsidian reads, and subagents each re-embedding 14k tokens for a question that needed one paragraph.

The harness from Part 1 is not only when to spawn subagents. It is when to load which memory tier — while you still own the files, the model choice, and the ship decision.

Why four tiers (not three)

The External Memory Series describes the stack as three layers for clarity. In practice there are four tiers — and the fourth is the one most diagrams label "feedback loop."

TierNameWhat it holdsHarness load gate
Layer 1Short-termCurrent chat, open files, git diffAlways in context — don't duplicate in brain-pack
Layer 2OperationalSession Summaries, Bridge, NEXT_SESSION.md, memories/repo/*, bootstrap snapshotOnce at session start for code work; skip for Mode A Q&A
Layer 3EvergreenFeatures/*, Architecture/*, shared conventionsOn demand for the task area — not every turn
Layer 4Feedback hardenedRules, custom agents, hooks, footer contract, eval:gateWrite at session end; read via alwaysApply rules — not a 14k paste

Layer 4 is not another folder to grep. It is the Session Continuity System made concrete: session context at the top, v3.1 footer at the bottom, self-improvements with an exact file path, and hooks that regenerate brain-pack.md without you re-explaining gotchas every chat.

brain-pack is a warm embed — mostly Layer 2 facts plus pointers into Layer 3. It is not a substitute for Layer 4. The harness prevents treating brain-pack as "load everything always."

Layer 1 — Short termLayer 2 — OperationalLayer 3 — EvergreenLayer 4 — FeedbackHarness gate(Part 1 policy)Agent chatWorkspace /git stateSessionSummariesmemories/repobrain-pack(embed)Features/*SharedconventionsRules +footerHooks +eval:gate code sessiononce on demandsession endwritesrules +agents
Layer 1 — Short termLayer 2 — OperationalLayer 3 — EvergreenLayer 4 — FeedbackHarness gate(Part 1 policy)Agent chatWorkspace /git stateSessionSummariesmemories/repobrain-pack(embed)Features/*SharedconventionsRules +footerHooks +eval:gate code sessiononce on demandsession endwritesrules +agents

How harness gates map to tiers

Session typeL2 operationalL3 evergreenL4 feedbackSubagents
Mode A Q&ASkip brain-pack + vault sweepSkip unless question needs one FeatureRules only (alwaysApply)No
Code workbrain-pack once; Bridge/Summaries on demandRead relevant Features/*Footer Mode C–D at shipPer policy table
Plan-onlyLighter bootstrap (Mode B footer)IDN before first edit if 3+ filesNo deploy fieldsNo batch for single scope

You stay in control: the gates are defaults the agent follows. Override with plain language ("skip vault," "read Features/Referrals only," "inline this, no batch").

Rule of thumb: native Read/Grep on vault paths you already have locally. Do not stack MCP + native Read on the same file in one turn.

Git vs Obsidian vs feedback (Layer 4)

ContentTierCanonical home
HARNESS-POLICY, eval JSON, CSV schemaL4 + gitdocs/ in repo
Session narrative, open loopsL2Obsidian Operations/* + memories/repo/ mirror
Features, conventionsL3Project vault + shared conventions
Rules, agents, hooks, footer contractL4.cursor/rules/, .github/agents/, AGENTS.md

Harness policy in git versions with the app. Session handoff in Obsidian stays human-readable. Feedback loop = lessons that graduate into rules (footer Self-improvements must cite path:Lnn or the write did not happen).

Session summary line (Layer 2 → Layer 4 bridge)

Append to Operations/Session Summaries.md:

- YYYY-MM-DD HH:MM (Project — **title**) — Harness: direct|batch|test|release; tests_before_ship: yes|no; failure: none|wrong-fix|redeploy; — <outcome>

Mirror one row in docs/harness-session-log.csv for weekly math (Part 3). The Summary line is Layer 2 narrative; the CSV is Layer 4 instrumentation you review to decide whether to build more orchestration.

Session startHarness gateL2 oncebrain-packImplement(you approve)L4 writefooter + rulesMode ACode work
Session startHarness gateL2 oncebrain-packImplement(you approve)L4 writefooter + rulesMode ACode work

Enable this on another repo

  1. Copy context-budget.mdc and HARNESS-POLICY.md from your reference repo.
  2. Point sessionStart at your session-prep script; generate brain-pack from memories/repo/.
  3. One Obsidian vault root per project in MCP or native Read.
  4. Teach agents: Mode A skips bootstrap; ship sessions write one Summary line.

Reader action

Audit your last five agent sessions. Count how many loaded brain-pack or vault files for questions that needed no code. Map your stack to four tiers — if Layer 4 is only "hope the model remembers," add footer + one rule file before adding another memory product. Part 3 shows how to log and review that discipline weekly.