How a few folders of Markdown turned a stateless coding assistant into a teammate that compounds, and why the system looks a lot like good management.
If you’ve used an AI coding assistant, you know the specific kind of tired I’m talking about when I say Claude can be draining. You explain your conventions. Your stack. The one weird architectural choice and the reason behind it. The work is good. Then you start a fresh session and it’s all gone, like talking to a brilliant contractor with no memory of yesterday. So you explain it again. And again.
I frequently build mobile and web apps on my own, during these projects I’m the whole org chart: architect, implementer, and institutional memory. I couldn’t afford to also be the assistant’s memory. So over the last several months I built something to fix it, and the longer I worked on it the more it stopped looking like an AI project and started looking like a management one.
I never fine-tuned a model. No training, no weights, no GPUs. Just structured Markdown and a disciplined loop. The field calls this context engineering, and I think it’s the highest-leverage skill most teams are still walking past. But here’s the framing that actually made it click for me: I wasn’t programming a tool. I was managing a teammate. And the best managers all do the same three things. They provide structure, set clear guardrails, and build feedback loops. Then they get out of the way and let their team do its job.
That’s the whole system. Let me walk through it.
Teach in context, don’t retrain
When people imagine teaching an AI, they picture fine-tuning, retraining the model’s weights on their own data. It’s expensive, slow, and marries you to one model version.
There’s a cheaper path. You shape behavior entirely through what you put in front of the model, not by changing the model itself. Nothing under the hood moves. So when a stronger model ships, my entire setup walks over to it untouched, with no retraining and no migration. For a small shop, that portability isn’t a nice-to-have. It’s the point.
It’s also just how onboarding works with people. You don’t perform surgery on a new hire’s brain. You hand them the docs, the context, and the why, and they get to work.
Standing instructions: the part every good manager writes down
At the root sits one file the assistant reads at the start of every session. It says who I am, my stack (Expo, React Native, C#/.NET, Azure), my code style, my git rules, how I like to work. The style rules are blunt on purpose: no speculative abstractions, no comments unless the reason is genuinely non-obvious.
The technical name is system-prompt augmentation: persistent standing instructions that override the defaults. But really it’s the team handbook. It’s the difference between a new hire who writes generic, technically-correct code and one who writes code that looks like it belongs in your codebase. Every good manager eventually learns that the expectations living only in your head aren’t expectations. They’re just disappointments waiting to happen. This system documents those expectations, and as a bonus it’s human readable for the rest of the team as well.
Memory, sorted by what kind of memory it is
This is where it got interesting. The field has started describing agent memory using the same categories we use for human memory, and my folder structure landed on them almost by accident.
Durable facts and decisions, what we chose and why, live as ADRs or Architecture Decision Records. That’s semantic memory.
The story of a specific event, like a bug that bit me, becomes a lesson document: symptom, root cause, fix. That’s episodic memory.
How to do a repeatable task lives as playbooks and reusable skills. That’s procedural memory.
And a small index file plus short per-fact notes loads every session, so the assistant walks in already knowing what I’m in the middle of. That’s the persistent context a good teammate carries between days.
Most teams treat AI memory as ad-hoc copy-paste into a chat box. Sorting it by purpose is the unglamorous move that makes any of it findable later. It’s the same reason a well-run team keeps decisions, incident reports, and runbooks in organized document management systems instead of one ever-growing channel nobody scrolls back through.
Retrieval without the machinery
Two things happen with that knowledge base. The standing instructions and the memory index load every session. The individual ADRs, lessons, and playbooks load only when they’re relevant, and the index carries a one-line description of each one, which acts as a lightweight router. The assistant skims the descriptions and decides what to pull in.
That’s Retrieval-Augmented Generation, RAG, but kept file-based, human-readable, and predictable. No embeddings, no vector database to babysit. For a few hundred documents instead of a few million, plain files with honest descriptions beat a semantic-search stack, and I can read every byte of what my teammate is working from. You can’t manage what you can’t see.
The loop that makes it compound
A static knowledge base rots. The thing that keeps mine alive is the last step of my workflow, the one I call CAPTURE. The full loop is SCOPE, DESIGN, BUILD, VERIFY, CAPTURE.
Every meaningful piece of work ends by writing its learnings back into the corpus the assistant can retrieve. A new architectural decision becomes an ADR. A nasty, non-obvious bug becomes a lesson. A pattern I’ve nudged the AI towards three times graduates into the standing instructions. And in my case, it’s all git controlled just like my code for all the same reasons.
That’s a feedback loop, a knowledge flywheel. Each project makes the next one faster because the hard-won context gets saved instead of evaporating at session end. It works for the same reason a team retro works: the learning only compounds if you actually stop and write it down. I made capture a two-second slash command, because the honest truth is that anything with more friction than that quietly stops happening, on any team.
Promote what generalizes
Here’s the part I see least often in the wild. A learning doesn’t just get saved. It gets promoted based on how broadly it applies.
A bug fix that only matters to one app stays in that app’s folder. A pattern that holds across all my React Native work climbs to the framework tier. Something genuinely stack-agnostic rises to universal, where every future project inherits it for free.
The literature calls this memory consolidation, the same generalization step reflective-agent research describes, and I run it as a governed process with templates rather than a clever algorithm. It’s an organizational discipline, not a technical trick. It’s also exactly what a good manager does when they notice one team’s fix is really an everyone problem, and they turn it into a standard instead of letting each team rediscover it. Deciding which lessons deserve to become defaults is where most teams stop short.
Guardrails are what let you move fast
One deliberate choice runs through all of it: this is supervised autonomy, not full autonomy. UI work gets a mockup and my sign-off before any code is written. Commits happen only when I ask. Updates to the knowledge base get reviewed and refined.
That sounds like a brake. It’s the opposite. The system is fast because it’s bounded, the same way a team with clear guardrails ships faster than one that either drifts from expectations or where every decision needs the manager in the room. Good management was never about doing the work or hovering over it. It’s about setting the structure, drawing the lines that are expensive to cross, wiring up the feedback, and then trusting the work to happen inside that frame. The guardrails are what let me hand over the keys and still trust where the car ends up.
Why this travels beyond my desk
Strip out my specifics and you’ve got a blueprint that scales past a team of one.
Teach in context instead of retraining, because it’s cheaper, faster, and portable. Sort your memory by type, because decisions, incidents, and procedures are different animals that want different homes. Make capture frictionless or it won’t survive contact with a busy week. Promote knowledge on purpose, because institutional memory that never generalizes is just clutter with good intentions. And keep a human on the decisions that are expensive to undo.
If that list reads like a management philosophy, that’s the point. Structure, guardrails, feedback, then get out of the way. That’s how you get the best out of a team of people, and it turns out it’s how you get the best out of an AI teammate too. For me the result is an assistant that onboards itself, remembers the reasoning behind every call, and gets more useful with each project instead of resetting to zero.
So tell me, is your team’s AI memory engineered, or is it ad-hoc?