Support Agent: Case Study
The agent that keepsyour other agents working.
Most AI deployments skip the maintenance layer. Context resets, stale memory, and no operational status mean agents repeat mistakes and lose continuity. We built the support infrastructure first.
Note: The memory and context architecture shown is what we run for our own agent stack. The same patterns, status snapshots, tiered memory, scheduled distillation, apply to any agent deployment, using whatever file formats, databases, or notification channels your team already uses.
The Problem
Agents wake up fresh. Your business does not.
Every AI session starts with a blank slate. Without a support layer, that means agents re-ask questions you already answered, repeat outreach to contacts you already emailed, miss context from yesterday's decisions, and slowly drift out of sync with reality.
The Architecture
Six plus automated maintenance jobs.
The support agent is not one thing. It is a coordinated set of scheduled maintenance jobs that keep memory, code quality, backup integrity, filesystem structure, and session context current.
Status Refresh
gen-status.js HubSpot API File systemBefore the main agent wakes up, a status script generates a live snapshot of operational state. It reads the outreach queue, checks Apollo and Hunter credit usage, counts staged leads and Reddit posts, and summarizes the last week of outreach activity. The result is written to STATUS.md, a single file the agent reads at session start.
This means the agent never starts a day guessing at queue sizes, credit availability, or recent send history. It reads the facts, then acts on them.
Nightly Memory Distillation
Claude (Sonnet) memory/YYYY-MM-DD.md MEMORY.md indexEach day writes raw notes to memory/YYYY-MM-DD.md. At 10:00PM, a Sonnet maintenance run reviews that daily record, distills durable learnings, updates topic files, and refreshes MEMORY.md as a curated index.
It removes outdated references, promotes stable decisions, and keeps short-lived operational details in daily files instead of long-term memory. This keeps retrieval fast and avoids memory drift.
Result: daily logs remain complete, topic memory stays curated, and MEMORY.md remains a clean index rather than a growing storage dump.
Nightly Codebase Audit
Claude (Sonnet) Automated code review reports/audit-latest.mdA dedicated Sonnet run performs nightly code review and repository hygiene checks. It captures findings in reports/audit-latest.md so each morning starts with an up to date engineering risk summary.
This creates a continuous quality control loop without requiring manual review every night.
Morning Status Refresh
STATUS.md Silent run Operational snapshotBefore active work begins, a scheduled status job writes STATUS.md silently with current queue, credits, and activity state. The agent reads one file and gets the current operating picture immediately.
This removes startup guesswork and keeps daily execution aligned with live system state.
Nightly Git Backup
Claude (Haiku) Commit + push Repository safetyA low-cost Haiku maintenance run creates a nightly commit and push cycle for backup continuity. This guarantees a recoverable checkpoint even after heavy automation days.
Backup reliability is handled automatically, not manually remembered.
Weekly Filesystem Structure Check
Claude (Sonnet) Silent by default Alert on non-zeroA weekly Sonnet validation pass verifies expected directory and file structure. The run stays silent on healthy results and alerts only when the check exits non-zero.
This catches structural drift before it breaks automation dependencies.
Context Priming and Heartbeat Coverage
SOUL.md + USER.md MEMORY.md index HEARTBEAT.md heartbeat-state.jsonEach session starts with context priming: read SOUL.md, USER.md, MEMORY.md, and recent daily notes. This restores operational continuity after resets and enforces a consistent startup protocol.
A heartbeat system provides periodic checks guided by HEARTBEAT.md, with check timing tracked in heartbeat-state.json. Compaction mode is default, so long sessions auto-compact context instead of accumulating token bloat.
When a session grows too large, a reset protocol can clear state safely. A recent reset moved from 4,876 entries and about 106k tokens back to a fresh baseline with full file-based continuity preserved.
Memory Architecture
Three tiers. Each with a different job.
Not all memory is equal. Mixing raw logs with curated facts in a single file is a common mistake. It bloats context, buries what matters, and makes everything slower.
The support layer maintains three distinct tiers: daily logs for raw chronology, a curated index that routes to topic memory files, and a live status snapshot for operational state. Each tier is scoped for a specific retrieval job and loaded only when needed.
When context resets, which it always does, the agent recovers in seconds by reading the right tier. It does not re-discover. It resumes.
Daily Notes
Raw log of everything that happened today in memory/YYYY-MM-DD.md. Created fresh each morning. Feeds nightly distillation. Kept for chronological reference.
MEMORY.md Index + Topic Files
MEMORY.md now functions as a curated index, not a storage dump. It points to topic files in memory/*.md such as lessons.md, outreach.md, infrastructure.md, gtm.md, instagram.md, and montebelle.md. Updated nightly by distillation.
STATUS.md
Live snapshot generated every morning at 7:30AM. Queue sizes, credit usage, recent activity. Never stale by more than 24 hours. Replaces the need to query multiple systems for current state.
Memory Retrieval
Search that understands what you mean and what you wrote.
Semantic retrieval is exposed through memory_search and memory_get, so the agent can resolve both conceptual and exact matches across daily and topic memory files. This avoids manual file scanning and improves recall during active work.
The support layer combines two retrieval methods. Vector search finds conceptually related content even when the wording differs. Full-text keyword search (BM25) finds exact tokens: configuration names, identifiers, error strings, tool references. The two signals are weighted and merged before results are returned to the agent.
Two additional passes refine the results. MMR (Maximal Marginal Relevance) removes near-duplicate snippets, which commonly accumulate when daily notes cover the same topic across multiple sessions. Temporal decay applies a recency weight, so a note from last week outranks a semantically similar note from three months ago when the question is about current state. Recent context surfaces first. Old context fades unless it is stored in the curated long-term file, which is never decayed.
The result: the agent retrieves relevant, current, non-redundant context on every search rather than returning five versions of the same fact from five different days.
How memory search works
Vector search
Semantic similarity over ~400-token chunks. Finds conceptually related memory even when wording differs.
BM25 keyword search
Full-text match on exact tokens. Catches identifiers, config names, and technical terms that semantic search misses.
MMR deduplication
Removes near-duplicate results. The same fact from five different days becomes one result, not five.
Temporal decay
Recency weighting on daily notes. A 30-day half-life means last week beats three months ago when both are semantically equal.
What It Looks Like
The agent reads this before it does anything.
Every morning at 7:30AM, the status script queries live systems and writes a structured snapshot. By 8AM, when the main agent starts work, it already knows the current state without asking a single question.
No "what's in the queue?" No "how many credits do we have?" No "did the last email send?" The support layer answered all of that before the session began.
STATUS.md: Generated 7:30AM today
Nine facts. Zero questions asked. Session starts informed.
The Point
Every agent deployment needs this layer.
It is the last thing teams think about and the first thing that breaks. When agents lose context, they produce worse outputs, repeat work, and require more human oversight, the opposite of what they were built to do.
The support layer is part of every build we deliver. Memory architecture, status generation, pruning schedules, and context priming are not optional extras. They are what make agents reliable over weeks and months rather than just impressive in a demo.
Memory Architecture
Design the right tiers for your agent system: what gets retained, what gets pruned, what stays in context, and what gets archived. Built once, maintained automatically.
Operational Status
A daily-generated snapshot of what matters: queue sizes, credit usage, recent activity, system health. One file. Read at session start. Always current.
Continuity Across Resets
Context windows reset. Agents should not. A well-designed priming sequence restores full context in under a minute after any session restart or handoff.
Fixed price. Two to four weeks. You own the code.