# I Run My Life From a Git Repo an AI Agent Maintains

> A private git repo of markdown about my own life, maintained by an agent. What the engineering discipline is for, what it caught, and where it fails.

For the last few months my primary thinking tool has been a private git repository full of markdown files about my own life, and I write almost none of it. An agent does. It reads what I feed it, files it, cross-references it, and tells me when two of my own files disagree. This post is about the system and not about its contents. I have published the empty scaffold so you can read the structure without reading me.

> **TL;DR**
>
> - I had been running this about nine weeks when Andrej Karpathy published his LLM Wiki gist describing the same architecture. Convergence, not lineage.
> - One layer is genuinely his, and I say which.
> - A person is a harder target than a research topic: claims expire, the same event gets recorded three times, and the author is an unreliable narrator in both directions.
> - Most of the engineering discipline in it exists to fix exactly those three problems.
> - The part I did not expect to matter most: the schema encodes my own failure modes as rules the agent must follow.
> - The scaffold is public and MIT at [ph33nx/llm-life-wiki](https://github.com/ph33nx/llm-life-wiki). The repo it came from stays private.

## Convergence, and the one layer I did take

The journals and dashboards in my repo date from January 2026. [Andrej Karpathy published his LLM Wiki gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) on 3 April 2026, by which point there were thirty-two daily entries in there. Reading it was the mildly deflating experience of finding a cleaner statement of something you are already doing, plus better names for the parts. His framing, which I have since stolen for explaining it to other people: Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase.

So the catalog file, the schema file, the dated log and the split into layers were already there. The log designs are not even the same shape: his is a single append-only file, mine is a directory with one file per day. I mention this only because the honest version of the story is more interesting than either of the dishonest ones.

**One layer is his, and it went in three months late.** The immutable `sources/` directory, raw material the agent may read and may never edit, was added this July after the gist made me realise what was missing. Before that, sources got read once and discarded, and the wiki had no way to distinguish what it had been told from what it had concluded. That distinction turned out to matter a lot, and I would not have arrived at it that cleanly on my own.

Neither of us invented the ingredients, for the record. A catalog file is a documentation convention older than both of us. The schema file points at conventions the agent vendors set. Interlinked markdown as a personal knowledge base is Zettelkasten with better tooling. We are both downstream of the same tradition.

Which leaves the actually interesting claim. Two people solving different problems arrived at the same architecture within about nine weeks of each other. That is weak evidence that the architecture is forced by the problem rather than invented by anyone, and if you go build one of these you will probably end up somewhere close too.

## Why a person is a harder target than a research topic

A research wiki accumulates facts that mostly do not fight back. A paper published in 2019 still says what it said. A life wiki has to survive four things that a topic wiki never encounters.

Claims expire. Something true last quarter is false now, and nothing about the file announces that.

The same event lands in three files, slightly differently each time, because I described it three times on three days in three moods.

The author is unreliable in both directions. I overstate some things and I flatly refuse to see others, and a system that just records my self-report faithfully inherits both errors.

And it has to be useful during a bad hour without amplifying it.

Almost every piece of engineering discipline in the repo exists to answer one of those four. That is the honest explanation for why a folder of notes turns into something with a commit gate.

## The rules that keep it from rotting

It is a git repository, not a folder. Every change is a commit whose message says why. Corrections are new commits, so a correction is visible as a correction instead of silently overwriting what I used to believe. The history is the audit trail, and for a document about yourself the audit trail is most of the value.

There is a pre-commit hook. Markdown lint, formatting, a type check on the scripts, and a test suite run before anything lands. A knowledge base drifts exactly as fast as a codebase does, so it gets the same treatment.

Three rules do the heavy lifting.

**One canonical home per fact.** Every volatile number lives in exactly one file. Every other file links to it and never restates it. There is a canonical-homes table in the index saying which file owns what. Duplication is a bug, not redundancy, because two copies drift and an agent reading both will either hedge or contradict itself.

**Decisions and state are different things.** Plans hold decisions and derived targets. Dashboards hold measured state. Plans link to dashboards and never restate a measured value. The test I use is "would this sentence be wrong next week?" If yes, it is state, so link it rather than copy it.

**Never trust a number in prose when a live authority exists.** Figures for [the ventures I run](/about "Abhishek Chaudhary: entrepreneur, systems architect and singer-songwriter from New Delhi") get fetched from the production systems at question time through tool calls, never read out of a file. I already run my site's admin as [an MCP server rather than a CMS](/blog/mcp-as-cms-private-admin-server "MCP as CMS: running a brand site admin as a private MCP server"), so the wiring was there. This is the rule I would keep if I had to drop every other one: the wiki holds interpretation, not figures. If the number is stale, the agent says so instead of quoting it.

The layout splits by kind rather than by chronology, because chronology is what the log, the journal and `git log` are already for.

```
wiki/
├── profile/       slow-changing biography
├── people/        one file per person
├── patterns/      recurring behaviours + a trigger log
├── lessons/       extracted principles, written generically
├── goals/         what
├── plans/         how. one per life track, and the count is fixed
├── dashboards/    measured live state, one per domain
└── journal/       one file per day. the only place feelings belong
```

Non-journal files are written for machines: one fact per bullet, tables over lists, arrows instead of connective prose, no filler. The journal is exempt and allowed to be human. Keeping [three tracks running at once](/blog/sustaining-three-parallel-careers "How I sustain three parallel careers and the weekly math behind it") is the reason the plan count is fixed at three and not left to grow.

## Configuring the agent against myself

This is the part I did not anticipate and now think is the whole point.

The schema file does not only describe formatting. It tells the agent what not to do, because I know these specific things misfire on me. Two examples that are actually in it: do not declare a fragile streak complete, because naming it is itself the thing that breaks it. And do not frame past actions as moral debt, because that specific frame caused years of damage.

Those are not preferences about tone. They are guardrails against known failure modes in the person the system is describing. The agent is configured against my biases, not only for my tastes. A generic assistant will happily hand me the exact framing that has historically cost me the most, because it reads as supportive.

The correction loop runs in both directions, which is the other half of it. The agent flags contradictions across files and claims that a newer source has superseded. I correct the agent when it over-fits. On one recent day I deleted three of eight items from a pattern it had generalised too eagerly, and added a fourth it had no way of knowing. Both edits got committed. It is a self-narrative with a QA process attached, which is a strange sentence to write and an accurate one.

## What it actually caught

Five things, described in shape rather than in detail.

A business metric dipped and felt alarming. Held against the recorded history, it was inside normal variance, and a restructure I was drafting turned out to be a response to noise.

The opposite case: a venture I had written off by feel had simply never been switched on properly. The gut read and the record disagreed, and the record won.

A conclusion I was proud of reaching turned out to have been reached and written down four weeks earlier, in almost the same words. That is how a loop becomes visible as a loop instead of feeling like progress.

One lesson had been recorded three separate times, always scoped to the specific incident, never generalised into a rule. Which is precisely why it never stuck.

And a long-running feeling I could not date got traced back to a specific decision in a specific month years ago. Vague became "started here, caused by this," which is a different problem and a solvable one.

Notice what all five have in common. None of them required intelligence. They required an accurate record and something willing to read all of it.

## The failure mode I have to watch

A knowledge base is a product. Building a product is comfortable, legible, and has a definition of done. Living the life it describes has none of those properties. So there is a constant, quiet pull toward improving the system instead of acting on what it already told me, and refactoring the schema feels productive in a way that the actual work does not.

The ratio I watch is time spent documenting against time spent doing. The diagnostic is one question: **am I improving the thing, or using it?** I do not always like the answer. This is the same reflex I have written about in [what senior developers do once the agents arrive](/blog/senior-developer-career-after-ai-coding-agents "What senior developers should do after AI coding agents"), pointed inward, and it is not more flattering there.

There is a second thing worth saying plainly. A system like this performs a role that in most lives is performed by people who have known you a long time. Someone who remembers what you said four weeks ago and is willing to point out that you are saying it again. That is a real observation about why it works, and I do not think it is a selling point.

The scaffold is public: [ph33nx/llm-life-wiki](https://github.com/ph33nx/llm-life-wiki), MIT, an empty skeleton with the schema, the folder layout, the ignore policy and the commit gate. It follows the [AGENTS.md convention](https://agents.md/), so it works with Claude Code, Codex, Cursor and the rest. The repository it came from is private and stays that way. What is worth sharing is the structure, and you can read a structure without reading a person, which is the entire reason it is built the way it is.