What broke
Agent-drafted posts didn't sound like me
Responsibility
Decision
Personal Project / AI Work System
Designing an AI work system that grows
without growing the work around it
- Memory loaded into every session peaked at 199 KBDown 74% to 52 KB, while the system kept growing
- Every AI session started from zeroOne system with shared memory, used every day for six months
- Knowing what needed me meant searching for referencesWhat needs me comes first. I don't open the files anymore.
Memory loaded per session
Read at session start vs. everything stored
Per-session load 34 → 199 → 52 KBTotal stored memory 49 → 2,037 KB
- 1Peak · 199 KBJul 27
- 2Grew back · 102 KBAug 15
- 3After the fix · 52 KBtoday
Overview
Six kinds of work, one person, and an AI system that keeps growing.
The system helps with all six, and it stayed easy to manage.
I built it in Claude Code and have used it every day for six months.
Problem
The system was making me manage the system.
Every AI session started from zero: I opened a chat, explained what I needed, and copied results between chats, or designed without AI at all.
Context got in the way
Building one system with shared memory gave every session a base to start from. But as it grew, managing its context started competing with the work, which meant:
- Less accurate results
- Sessions that ran out mid-work
- More context than each task needed
Context should serve the work, not compete with it.
Process
How might I make an AI work system that grows without making me spend more time managing it?
The problems I met in daily use shaped three boundaries: responsibility, memory, and maintenance.
What broke
Every session loaded everything and ran out mid-work
Memory
Decision
Make memory intentional
What broke
Cleanup ran every two weeks, but growth happened every session
Maintenance
Decision
Make maintenance part of the product
Key decisions
Three design decisions.
Keep decisions human
Routine work runs on its own, but decisions don't.
Make memory intentional
Each session gets only the context its task needs, so a writing session doesn't carry my job-search context. Replaced rules are archived, not deleted.
Make maintenance part of the product
The system has to notice when it starts getting in the way. It flags its own drift in a weekly review rather than every morning, and I decide what to act on.
How the three decisions fit together
I decide, direct, and approve across six kinds of work. They share one system: research feeds memory, memory feeds the dashboard, and maintenance keeps it usable. The dashboard is where I see what needs me and decide.
USER1decides · directs · approves
CareerContentConsultingStudyBuildDaily ops
SHARED SYSTEM
Research
Memory2
Dashboard
User sees and decides
3Maintenance keeps it usable
Trade-offs
All three choices keep me in the loop, but each costs something.
01
Posts written by handinstead of: Agents draft them
KeepsVoice and judgmentGives upAutomation02
Memory loads by domaininstead of: Load everything, every session
KeepsFocused, lighter sessionsGives upLinks across domains surface less03
A weekly system checkinstead of: A check every morning
KeepsMornings stay for decisionsGives upDrift can wait up to a week unseen
Design
The design, through two use cases.
When the system started working against me
A cleanup every two weeks and a health check were supposed to keep the memory loaded into every session small, but they didn't.
The code wasn't broken. The model was. The system kept growing. Session load went up, then came down.
- Symptom
Memory grew 51% after cleanup.
- Investigation
One file accounted for 43% of loaded memory. The health check counted lines, while the real constraint was size.
- Design insight
The monitoring model was measuring the wrong thing.
- Change
Measure actual size. Archive earlier. Cap entry length.
- Result
−58% file size · −25% fixed session cost
Designing the decision surface
Before the dashboard, knowing what needed me meant searching for the right references every time. So I organized it around the decisions I have to make: judgment first, action second, retrieval third, and system maintenance last.
Decide
What needs me comes first, ranked by what it costs to leave: a post past its date, a stuck plan, records that make the numbers wrong, then maintenance. Each decision shows why it matters, the evidence, and its options, but nothing on the dashboard acts on its own.
Act
Below it, what I can move forward today, without repeating what's already waiting above.
Find
Finding stays separate from deciding. When I need something, I search or pick a category, and each bar shows how much of it is fresh, aging, or untouched for 30 days.
System check
System health sits last on the page because it matters once a week, not every morning. The weekly check shows what's wrong, what the review noticed, and whether context and complexity are growing. When there's nothing to act on, it stays quiet.
Full stats
All the information stays, one level deeper. When context cost or memory grows, I can see what each session pays for, where the bulk lives, and whether cleanup keeps up.
What I learned
Design the boundary, not just the capability.
Make system state legible before automating it.
Treat maintenance as part of the product.
Still unsolved
Connections across domains still come from me, and the system adds maintenance of its own.
