I jot thoughts down as if into a notepad — twice a day an agent turns them into a linked knowledge base

Context

I run several lines of business in parallel — furniture hardware distribution, manufacturing, my own products — and all the substance behind them lived in chat threads, phone notes and my head: unit economics, agreements, prices, takeaways from books. The only way to find anything was to scroll through chats, and half the decisions simply got lost.

The classic atomic-notes method solves this pain, but for most people it dies: between “a thought occurred” and “a note with links” sits tedious manual work that nobody does. The opposite method — one file, everything new at the top — always survives, but produces an unstructured wall of text thousands of lines long that is impossible to search.

The cost of the problem isn’t measured in minutes. A thought that never became a note never meets other thoughts. An observation about patience in the third period of a hockey game and the conclusion “in a stormy market, the best deal is no deal” will never end up side by side, even though they are the same principle. Those junctions are where new ideas come from.

The solution is to combine both methods and take the human out of the loop: a single frictionless file on the way in, structure on the way out, and an autonomous agent doing the tedious work in between.

Constraints

• Zero confirmations. A deliberate decision: the agent runs fully autonomously and never asks. The consequence: the supervisor’s role is taken over entirely by technical safeguards, not by a person
• iPhone only as the mobile input. iOS forbids apps from working in the background; mobile git sync overwrote fresh files with stale snapshots four times. Input through a messenger was rejected: notes should live where they are read
• The agent gets no git and no command line. Read, write and search only. All history operations are done by a wrapper script after checks — the agent cannot bypass the safeguards even if it makes a mistake
• Incrementality is mandatory. The naive scheme of “read the whole vault on every run” would stop working within six months: processing looks only at what’s new and finds links through search
• Cyrillic file names, a stripped-down environment and the scheduler’s time zone are the most common causes of silent failure in systems like this; each is handled separately
• Privacy. These are personal notes: a private repository, secrets kept outside the repository with restricted permissions, end-to-end encrypted sync

Solution

What it delivers

You write your thoughts into a single file — plain text, no tags, folders or formatting, from any device. Twice a day the system turns what was written into structure on its own: atomic statement-notes, tasks, cards for books and projects, links between them, and refreshed topic maps. Once a week it rereads the whole archive looking for non-obvious pairs — notes from different areas with no link between them but a shared pattern of thinking. A separate module assembles a “Plan for the day”: today and tomorrow only, by time, with checkboxes.

How it works

Input is a file called “Stream”: zero friction, nothing is sorted at the moment of writing. Output is a flat folder of atomic notes plus hub maps of topics: the structure lives in links, not in directories. In between is the LLM layer: an autonomous agent (Anthropic API) running headless on a VPS, launched on a schedule with a prompt that points to a rules file inside the vault itself.

The rules are not code but an editable document: how to classify an entry, how to check atomicity, how to find link candidates by searching for key concepts, how to preserve the author’s voice and honestly mark the places where meaning was filled in. The system’s behavior is changed by editing plain text, with no deployment.

Safeguards instead of trust

Autonomy rests on engineering, not on faith in the model. Every run is a separate git commit. Entries arriving from devices are committed before the agent starts: a rollback undoes the agent’s work and physically cannot erase what the human wrote. A run that deleted a file or changed the text of an entry that wasn’t its own is rolled back automatically, with a rescue snapshot taken before the rollback. The comparison is done line by line, ignoring service markers — the “raw” marker on a matured entry can be swapped for “processed”, but the thought itself cannot be touched. System files — scripts and rules — live in a reference copy outside the repository and are restored on every run if a faulty sync has overwritten them. When any safeguard fires, a beacon file appears in the root of the vault and a banner at the top of the daily report.

Sync

Git is kept on the server only — as history and backup. Devices sync through encrypted Obsidian Sync, and the server takes part in the same sync through a permanently running headless Obsidian in a Docker container. This is a compromise paid for dearly: the first architecture, with git sync on every device, fell apart on the iPhone.

Try it yourself

A live graph: write a thought — the agent will weave it into the base

Below is a scaled-down copy of the system on fictional notes. On the left, the “Stream” file with seven raw thoughts; on the right, the graph. Send them one at a time: the agent phrases an atomic note, finds links — including across different areas of life and with your previous notes — and the node drops into the graph before your eyes. Nodes can be dragged; click one to see the note’s text and its links.

Architecture

The agent’s rules are a document inside the vault, not a prompt in code. The system’s behavior is changed without deployment; the agent rereads the rules on every run.

The agent has no git and no command line; a wrapper manages history. The agent cannot bypass the safeguards even if it makes a mistake.

Incoming data is committed before the agent works. The only way to make rollback safe with external sync.

A reference copy of the scripts outside the repository + self-healing. The repository syncs to the phone, and the phone is capable of overwriting the scripts in it.

Incremental processing + a full sweep only in the weekly review. Linear growth in the cost of a run would kill the system on a six-month horizon.

A shared lock across all runs. Processing, review and plan assembly must not touch git at the same time.

A generated “Plan for the day” with checkboxes written back to the source. The view can be rebuilt as many times as needed — state lives in the source. The dates the plan was built for are stored in its header: otherwise yesterday’s checkboxes would be attributed to today — a bug caught by a test.

Stack

Outcome

First week in production: 63 notes and 167 links from ~40 stream entries, 20 automated runs in a row without intervention — all verifiable in the git history, not in a demo video. The maximum time from “thought” to “structured note” is no more than nine hours with two runs a day; before, this journey never happened at all. Critical scenarios are covered by 13 scenario tests and 26 readiness checks that run before every job.

Reliability

How the system catches its own mistakes

The best test of safeguards is a real incident, and one happened.

After the move from git sync to Obsidian Sync, entries from devices started arriving in the server’s working folder uncommitted. The old rollback mechanism didn’t account for that — and the very first false rollback wiped fresh entries together with the agent’s work.

From there the system behaved exactly as designed. The rescue snapshot taken before every rollback had preserved everything that was wiped — the entries were restored in full, zero lost over the system’s entire lifetime. And the incident itself exposed a second problem: the alert was being written to a file inside a hidden service folder, and nobody knew about the outage for 36 hours. Now the alarm signal must be in plain view by default — a beacon file in the vault root and a banner at the top of the daily report: a failure is visible in the same run, not a day and a half later.

The main lesson is baked into the order of operations: first the human’s data is committed, then the system does whatever it likes with its own. Committing incoming entries is the first step of every run — now a rollback physically cannot erase what the human wrote.

What I’d do differently

• The safeguard turned out to be more dangerous than the threat it guarded against. A hard rollback was safe as long as devices synced via git. After the sync changed, it started wiping uncommitted entries. Lesson: commit the user’s data first, roll back your own second
• A false positive cost two days of the system’s uptime. The check “stream line unchanged” forbade any change to a line — including the legitimate replacement of the service marker on a matured entry. Every run dutifully rolled itself back. The comparison should have been by content from the start, ignoring service markers
• A silent failure is worse than a loud error. The alarm channel must be in plain view by default, not in a hidden folder — 36 hours of downtime proved it
• Mobile git is a dead end, and it cost four attempts. The iPhone overwrote fresh files with stale snapshots four times; twice the vault had to be rebuilt from scratch. The dead end should have been admitted sooner: fixing it took longer than the proper solution
• Other people’s texts are not for atomizing. The first processing run tried to shred a book summary into fifty-odd scraps. The rule was refined: other people’s texts are moved whole into sources; only my own thoughts are subject to atomization

Where next

People also look at

Want a system that tidies up your data on its own — and physically cannot lose it?

Get in touch — we'll work out what can be automated in your case.

I reply the same day, usually within a couple of hours.