DEV Community: Andrew Detwiler

Build With a Memory Is Now a Public Repo

Andrew Detwiler — Fri, 24 Jul 2026 14:04:01 +0000

I wrote about giving the agent a memory before you give it a task. That post was the what. This is the how.

The whole method is now public: buildwithamemory.com, backed by a repo you can read, copy, and argue with at github.com/adetwiler/build-with-a-memory.

What's actually in it

Ten short method docs. Copyable templates. A one-paste prompt that sets a project up from zero. All plain markdown.

There is nothing to install and nothing to sign up for. That's deliberate. Your project's context should live in your repo, as files you own, next to the code it describes. Not in somebody's hosted memory product. I would rather show you the method and have you keep the files than sell you a subscription to your own context.

It works with whatever agent you use. The files are just markdown; any tool that can read your repo can read them.

The part I'd start with

If you only take one thing, take the decision records.

When you make a real decision, write one small file: what you decided, and why. The why is the part you forget first.

Here's what that buys you. Normally, review cost grows with a project. More code, more history, more "wait, why is it like this?" With decision records, it inverts. The agent reads the decision once and stops re-litigating it. Every session after that is cheaper than the last. Two months in, my reviews got faster, not slower.

That inversion is the whole reason the rest of the method pays off.

What it won't do

Honestly, it's not magic. The agent still gets things wrong. The files go stale if you stop tending them. And a pile of docs nobody maintains is worse than one page that's true. The method is mostly discipline: write the decision down when you make it, write the gotcha down when it bites you, keep the always-loaded page short.

I'm still figuring out parts of it. The repo says so where that's true.

Where this came from

I didn't sit down to design a method. It fell out of building real things: my games, and Playloop, the playtest-insights tool I'm building for indie devs. Every gotcha in those repos taught me something about what an agent needs written down. The private projects keep their private files. The method is what generalizes.

If you want to follow along as it grows, I write a short letter when there's something worth saying. And if the playtesting side of this sounds like your problem too, Playloop is coming later this year and has a waitlist.

But mostly: go take the files. That's what they're for. If you try this on a real project and something doesn't hold up, tell me. The method got better every time something broke, and I don't expect that to stop.

Credits

Not all of this is mine. The mindset shift came from a talk by Matt Pocock, and the grilling pillar adapts his grill-with-docs skill. The repo names every borrowed idea in CREDITS.md. If I borrowed something without naming it, tell me and I will fix it there.

How I Built a Local Memory Network for My AI Agents

Andrew Detwiler — Thu, 23 Jul 2026 21:27:24 +0000

Your AI agent forgets everything between sessions. So it re-derives the same
decisions, and you pay for it every time.

I got tired of paying. Tired of re-explaining the same project every morning,
watching the agent rediscover a gotcha I hit three weeks ago, re-litigating a
decision I already made.

So I stopped relying on the agent's memory and built the memory into the
projects themselves.

I've been running this system across everything I build for months now: a
SaaS, a couple of games, personal tools. This post is the full internals. How
the files are structured, how they link to each other, and how the whole thing
became searchable in about 0.2 seconds without a single byte leaving my
machine.

The whole idea in one sentence

The repository itself is the memory.

Every durable fact gets written to exactly one file, committed where the work
happens. Decisions, conventions, gotchas, what I'm working on right now. A
fresh agent session doesn't recall any of it. It reads it.

That sounds obvious. Maybe it is. But the difference between "we have some
docs" and "the repo is the memory" comes down to three things most doc folders
never get:

A map, so an agent can find the one file it needs without scanning the tree
Links, so facts have one home and everything else points at it
Search, for when you don't know which file to open

Let me walk through each layer.

The part I didn't plan

I built this to stop coding agents from forgetting technical context. But once
the network held decisions, current work, past mistakes, meeting notes, and my
own writing preferences, it turned out to be useful outside the code.

It now drafts my documentation, release notes, blog posts, and social posts
from the actual history of the work. I review, correct, and approve
everything, but I no longer have to reconstruct what happened before I can
explain it. This post was drafted from the same network it describes, and the
site it lives on is updated through that system too.

The shape: three tiers

Not everything belongs in a repo. A convention about how I write tests belongs
in that project. A rule about how I write emails belongs everywhere. My own
working-style preferences belong to me, not to the codebase.

So the network has three tiers.

Fig 1. One home per fact. A top-level index file maps all the networks so any session can locate the right one.

The routing rule is the load-bearing part. The first time a rule shows up
that's wider than the current project, it moves up a tier immediately, in the
same session. Otherwise you end up with four copies that slowly drift apart,
and then you can't trust any of them.

Inside a repo network

Here's the anatomy of a single repo's memory, using my biggest project as the
example.

Fig 2. The read path of a fresh agent session. The always-loaded file stays lean on purpose; everything heavy is lazy-loaded through the map.

The always-loaded manual holds only the rules that prevent damage. Everything
else is behind the map, and the map entry for each file includes one line
saying when to read it. That's what keeps the token cost sane. The agent
doesn't front-load forty documents. It locates, then opens one.

That sounds wrong if you're used to "more context is better." But every file
the agent loads costs tokens, and most of them wouldn't have changed the
answer.

How it all links together

Three kinds of links hold the network together, and none of them are clever.

1. Wikilinks between notes

Every memory note is one fact in one file, with a little frontmatter and a
slug. Other notes reference it with [[that-slug]]. A link to a note that
doesn't exist yet is allowed on purpose. It's a marker that something is worth
writing, not an error.

---
name: verify-before-you-report
description: "Never claim a result you didn't read from the tool this turn"
type: feedback
---

Confirm the exit code, re-run the check on the committed tree, then say it.
Related: [[done-means-verified]], [[never-invent-a-sha]]

2. Index files as hubs

Every tier has a small index: one line per note with a pointer. The indexes
are what get loaded into context; the notes are what get opened on demand.
Same shape at every level, from a single repo's context map up to the
top-level file that maps all the networks on the machine.

3. A health check that keeps the graph honest

Links rot. So a script runs at session start and reports three numbers:
dangling links (a [[slug]] pointing at nothing), orphans (notes no index
points to), and missing file links. This morning it reported 0 dangling and 8
orphans. Those orphans are real debt, but now I can see it instead of finding
out later.

Fig 3. I also generate an actual interactive version of this from the real files: a small script walks the folder, parses the wikilinks, and emits a self-contained force-graph HTML page. Zero dependencies, nothing hosted.

The pattern underneath all three: one home, many pointers. A fact lives in
one file. Everything else links to it and never copies it. Two copies of the
same fact will disagree eventually, and then your memory is lying to you.

How it's searchable (without sending anything anywhere)

Links work when you know roughly where something lives. Search is for when
you don't.

The search layer is one SQLite file, built by a small indexer that walks the
whole network: wide memory, every project's notes, and the docs folders of the
repos I care about. It chunks each file into pieces of about 220 words,
respecting markdown sections, and indexes every chunk two ways:

Keyword (BM25 via SQLite's FTS5). Catches exact rare tokens: an env var name, a commit SHA, a number like 0.62. Embeddings genuinely miss these.
Semantic (local embeddings via Ollama). Catches paraphrase, so a query about "pricing" finds the note that says "monetization." Nothing leaves the machine, which matters because this corpus holds financials and unreleased work.

At query time, both searches run and the results get merged by Reciprocal
Rank Fusion. Not by mixing scores. A BM25 score and a cosine similarity
aren't on the same scale, so you fuse by rank instead, and it needs no tuning.
Answers come back in about 0.2 seconds over roughly eight thousand chunks.

Fig 4. If the local embedding model isn't running, it falls back to keyword-only instead of failing. The search has to always answer something, or I'd stop reaching for it.

Two design choices here matter more than the retrieval math.

The index is disposable. Markdown is the source of truth. The database is
derived from it, and I can delete it and rebuild from scratch in about a
minute. There's no product sitting between me and my own notes, and nothing to
migrate away from later. The notes are still just files on my machine.

Indexing is incremental by content hash. A run with no edits is a no-op
that takes milliseconds. That's what makes it cheap enough to just always be
current.

The agent gets this as a one-line query tool, and the standing rule is to
orient first: before any real task, ask the network what's in flight on that
topic. The answer is either "here's the context" or "nothing relevant," and
both are useful.

The habits that keep it alive

Honestly, this is the part that decides whether the whole thing works. The
files and the search are just plumbing. What actually kills a system like this
is nobody writing anything down.

Three habits, and the mechanisms that enforce them:

Capture in the same pass. When a decision gets made or a gotcha gets hit,
it goes to its one home in that same session. Not a follow-up chore, part of
"done." The agent does the writing; my job is to not skip it.

Hooks that surface memory instead of trusting recall. A session-start hook
prints the open items and the current focus before any work begins. Another
hook fires right before a long conversation gets compacted and re-surfaces the
capture rules, because compaction is exactly the moment a learning would
otherwise be summarized away.

One-word verbs for the expensive moments. Ending a session well used to
mean writing a handoff by hand, so I mostly didn't. The data made that
embarrassing to look at:

Fig 5. 171 session endings, 4 handoffs. I was stretching sessions instead of ending them, because ending them well was work.

The fix was to make the whole close-out cost one word. I type handoff and
the agent writes the summary, files the open questions, sweeps for uncaptured
gotchas, and stores it where the next session's hook will surface it. I type
pick up and the next session starts exactly where the last one stopped. Same
idea for idea (log a passing thought without derailing the session) and
queue (one canonical answer to "what's first today," computed by a script
instead of vibes).

One word removes the friction. The friction was the whole problem.

What this is not

It isn't a hosted product or a service I'm asking you to buy. It's also not
magic memory for the AI. The agent still forgets everything between sessions. The system
just makes forgetting cheap, because everything worth knowing is written down
where the next session will look.

And the AI doesn't get this right on its own. It captures the wrong things,
files duplicates, and lets links rot, unless the rules are written down and
enforced by the same network it maintains. The judgment stays with me. The
system just means I only have to make each call once.

If you want to start

You don't need the search index or the graph or the hooks on day one. I didn't
have them either. The minimum that pays for itself immediately:

One short always-loaded file: what the project is, how to run it, the rules that matter
docs/now.md: what's active right now, a few dated lines
docs/decisions.md: one dated entry per real decision, with the why
docs/notes.md: gotchas worth not hitting twice
The habit: write it down in the same session it happens

Everything else in this post grew out of that seed, one annoyance at a time.
The linking showed up when facts started needing two homes. The search showed
up when I couldn't remember which file held a decision. The verbs showed up
when I noticed I was avoiding my own system because it cost too much to use.

The public repo, Build With a Memory,
includes the seed version: a single prompt you paste into an agent to install
the basic structure in an existing project. The tools from this post are in
there too, under tools/:
the search indexer, the query tool, the graph generator, and the link-health
check, generalized to run on any folder of notes.

Writing it down costs less than re-explaining it.

What are you building into your repos?

I'd honestly love to hear how other people are handling this. If you've got a
memory setup for your agents, even a messy one, what's the piece that actually
gets used? And what died from neglect?

Credits

The network is my own build, but the way of working it grew out of is not all mine. A talk by Matt Pocock flipped committed project memory from something I toyed with into how I actually work. The method repo keeps the full credit record in CREDITS.md. If this post uses an idea I have not credited there, tell me and I will fix it.

Give the Agent a Memory Before You Give It a Task

Andrew Detwiler — Mon, 13 Jul 2026 16:31:05 +0000

Every AI coding session starts the same way.

The agent knows nothing about your project. Not the decision you made last
Tuesday. Not the migration that burned you. Not the naming convention you
finally settled on.

So you re-explain. Every session. Or worse, you don't, and the agent makes
a mistake you already paid for once.

The fix is boring

It's not a smarter model. It's not a bigger context window. It's writing
things down, in the repo, where the work happens.

I keep three kinds of files in every serious project now:

A short operating manual the agent always loads. Rules only. If it grows past a page, something moves out.
Decision records. One small file per locked decision, with the why. The why is the part you forget first.
A gotchas file. Every time something non-obvious bites me, it gets a line right then. If I save it for later, it never happens.

That's it. Plain markdown. No tooling, no framework, nothing to install.

What changed for me

Honestly, the difference is bigger than any model upgrade I've tried.

A fresh session reads the manual and starts acting like it was here last week.
It follows conventions I never mentioned in the prompt. It skips the mistakes I already
made once, because they're written down.

And the strange part: the notes made me better too. Writing "we decided X
because Y" forces you to actually have a Y.

A starter file

Drop this in your repo as AGENTS.md and edit it honestly:

# Operating manual

## What this project is
One sentence. What it does, who it's for.

## Rules that are always true
- Commands: how to run dev, tests, build.
- The one or two conventions people keep getting wrong.

## Decisions (the why matters)
- 2026-07-12: We use X instead of Y because Z.

## Gotchas
- The thing that bit us, and what to do instead.

Start smaller than feels right. A pile of docs nobody maintains is worse than
one page that's true.

What are you writing down?

I'm still figuring out where the line is between useful memory and busywork.
If you're doing something like this in your own projects, I'd honestly love
to hear what you keep and what you throw away.

How I’m Building Personal Apps With AI, Next.js, SQLite, and Tailscale

Andrew Detwiler — Sun, 10 May 2026 02:04:02 +0000

For years, building custom software felt like something reserved for startups, funded teams, or companies with dedicated infrastructure.

That’s changing fast.

Today, you can build fully custom personal apps for yourself, your family, or a small team in an afternoon using AI. You don’t need cloud infrastructure. You don’t need Kubernetes. You don’t even need to deploy anything publicly.

You can run modern web apps entirely on your own machine or on a small dedicated computer in your house, securely, and install them on your phone like native apps.

I’ve been doing this myself for budgeting tools, meal planning apps, grocery lists, internal dashboards, and small tools that help organize things at home.

And honestly, it works incredibly well. Most of these apps would have never been worth building for me a few years ago.

The Shift Happening Right Now

The biggest change isn’t just AI generating code.

It’s that the combination of:

AI coding models
Modern frameworks like Next.js
SQLite
Progressive Web Apps (PWAs)
Tailscale

has lowered the barrier so much that building personal software is now practical for regular developers.

You no longer need:

AWS infrastructure
complicated authentication systems
production-grade distributed databases
app store deployments
expensive SaaS subscriptions for every tiny need

If your app is only for:

yourself
your family
your friend group
a small team
your local business

you can simplify almost everything.

And simplification changes the game.

What You’ll Need

The stack is intentionally minimal.

1. AI Coding Tool

You can use:

ChatGPT
Claude
Cursor
Windsurf
anything capable of generating and modifying code

This is really the only paid part depending on the model you use.

2. Next.js

Next.js is perfect for this.

You get:

frontend
backend API routes
server rendering
static assets
routing
PWA support

all in one project.

No separate backend required.

3. SQLite

For personal apps, SQLite is massively underrated.

You do not need Postgres for:

grocery lists
meal planners
budgeting apps
household management
internal dashboards
small team tools

SQLite gives you:

a single file database
zero infrastructure
no database server
extremely reliable storage
backups as simple as copying a file

And for personal applications, it’s more than enough.

4. Tailscale

This is what makes the whole thing practical.

Tailscale creates a private encrypted mesh network between your devices.

Your app never has to be exposed publicly to the internet.

You can:

host the app on your desktop
run it on a mini PC
keep it on an old laptop
use a small home server

and securely access it from:

iPhone
Android
Mac
Windows
tablets
laptops

Tailscale’s free tier supports up to 6 users, which is perfect for families or small teams.

This is honestly one of the biggest unlocks for personal software development.

The Authentication Trick

For personal apps, you don’t need enterprise auth.

You don’t need:

OAuth
Auth0
Clerk
JWT complexity
social logins

If the app only exists inside your private Tailscale network, you can simplify authentication dramatically.

One approach I use often:

create predefined users
let the app ask “Who are you?”
store the selected user locally
treat that as authenticated

That sounds wrong if you come from enterprise software.

But context matters.

Inside a private encrypted Tailscale network shared only with trusted users, this is often completely acceptable for personal tools.

The result:

almost zero auth complexity
no external auth provider
no monthly auth costs
much faster development

You stop overengineering software that only five people will ever use.

Make It a PWA

This part is important.

When prompting the AI to build the app, include:

installable PWA support
offline support where possible
responsive mobile UI
app manifest
service worker setup

This allows the web app to behave almost exactly like a native app.

You can install it directly from the browser.

iPhone

Use Safari → Share → Add to Home Screen

Android

Install directly through Chrome

Mac and Windows

Install directly from Chromium browsers

Once installed:

it launches like a native app
has its own icon
runs fullscreen
feels like a real application

Most non-technical users won’t even realize it’s a website.

Using MagicDNS

Tailscale’s MagicDNS makes the experience even better.

Instead of:

192.168.1.44:3000

You get:

mealplanner.tailnet-name.ts.net

Or:

budgetbox.tailnet-name.ts.net

This makes your apps feel like real products instead of random local servers.

Example Apps That Work Extremely Well

Family Apps

Meal Planner

weekly meals
shared grocery list
pantry tracking
recipe storage

Budgeting App

monthly expenses
sinking funds
subscriptions
shared family budgeting

Household Dashboard

chores
maintenance reminders
schedules
calendars

Kids Dashboard

allowance tracking
reading goals
homework tracking
screen time systems

Small Team Apps

Internal Tools

lightweight CRM
project tracker
sprint dashboard
client management

Studio Tools

asset trackers
bug lists
roadmap viewers
release planning

Content Pipelines

social post planners
publishing trackers
video pipelines

Why This Matters

We spent years forcing every software idea into:

SaaS
cloud hosting
subscriptions
scaling concerns
public deployment

But most software ideas do not need to scale to millions of users.

A huge percentage of useful software only needs to solve problems for:

one person
one family
one studio
one team

AI makes custom software generation cheap.

Modern frameworks make development fast.

Tailscale makes networking easy.

PWAs make distribution trivial.

And SQLite removes infrastructure entirely.

The result is that personal software development is entering a completely different era.

A Sample Prompt

Here’s the type of prompt I’ll give an AI model:

Build a Next.js PWA for meal planning and grocery management.
Use SQLite for storage.
Use simple local authentication where the user selects their identity from predefined users.
Design it mobile-first.
Add installable PWA support.
Include offline support for grocery lists.
Optimize the UI for iPhone and desktop usage.
Use TailwindCSS and shadcn/ui.
Structure the app cleanly with reusable components and API routes.

That alone can get you shockingly far now.

Final Thoughts

I think we’re entering a phase where developers will increasingly build software specifically for:

their own lives
their families
their friend groups
niche communities
small businesses

Not everything needs to become a startup.

Sometimes the best software is:

simple
private
local
highly customized
built for exactly the people using it

And for the first time in a long time, building those kinds of applications is actually easy.

What Are You Building?

If you’ve been building personal apps or experimenting with local-first setups, I’d honestly love to hear what you’re building or how you’re approaching it.

I think this space is becoming more interesting every month.