Over the past few days, I have spoken with dozens of people who are trying to understand what to do with artificial intelligence.
\nSome are students. Some have jobs. Some want to start a business. Many say they want to build an agent or a second brain. But when I ask what the agent should actually accomplish, the answer often becomes vague.
\nThey have seen the videos. They know the vocabulary. They can talk about agents, memory, automation and orchestration. They are excited by the architecture of a future project, but they do not yet have a problem they are determined to solve.
\nAt first, I thought this was simply the usual gap between consuming content and doing the work. Then I realised I recognised the behaviour because I had spent the previous month and a half doing my own, much more sophisticated version of it.
\nI was not watching tutorials and imagining a project. I was building real systems. I had code, infrastructure, tests and working software. I was shipping almost every day.
\nAnd I was still stuck.
\nThat is the uncomfortable part. The trap does not always look like procrastination. Sometimes it looks exactly like serious work.
\nBefore AI coding tools, complexity had a natural cost. Every new abstraction, validation layer and automated check required enough manual effort that you were forced to ask whether it was worth building.
\nThat friction has largely disappeared.
\nNow I can describe a sophisticated mechanism and watch it become code. I can ask for another test, another safeguard, another agent, another recovery path. Each request may be reasonable. Each addition may improve the system in isolation. And because the work is happening so quickly, it feels like progress.
\nBut AI did not remove my responsibility to decide what the product needed.
\nIt only removed many of the practical limits that used to stop me from building too much.
\nThis creates a new failure mode: we can now construct unnecessary systems at a speed that feels productive.
\nI ran into this while building Agent Company Index, a directory of companies working with AI agents.
\nThe basic product is not difficult to explain. A company should be able to submit its website and services, pass the necessary checks, and appear in the directory.
\nAt some point, however, that simple path became surrounded by more than a thousand automated checks. There were validations, hashes, integrity rules, tests for tests, and safeguards for situations that had not happened yet. Every layer made sense when I looked at it individually.
\nThen I tried to onboard my own company.
\nIt took me two days, and I still could not make it work on the first attempt.
\nThis was a static directory. I was the owner. I understood the code. I had built the process. Yet the architecture had become so demanding that I could not perform the product’s most basic action.
\nThat is when the contradiction became impossible to ignore.
\nI had built a system that was increasingly good at protecting its own structure and increasingly bad at letting a person use it.
\nThe architecture was no longer supporting the product. The product was servicing the architecture.
\nIt would be convenient to blame the coding agent.
\nI cannot.
\nThe AI did what I asked. More precisely, it did what I repeatedly approved.
\nIt knew how to build validations. It knew how to increase test coverage. It knew how to make the pipeline more rigorous. When I requested a new protection, it could explain why that protection was a good engineering practice and implement it competently.
\nThe problem was not that the AI produced the wrong answer.
\nThe problem was that I had not defined the boundary of the answer.
\nAn AI system can be excellent at answering “How do we make this more robust?” while never asking the more important question: “Is this already sufficient to help one person complete the job?”
\nThat remains the operator’s responsibility.
\nAI knows an enormous amount about how software can be built. It does not automatically know how much software your idea deserves today.
\nPeople often describe AI literacy as knowing how to write prompts, choose models or connect tools. Those skills are useful, but I increasingly think the more important skill is learning to define “enough.”
\nWhat must be true before a first version can meet reality?
\nWhich failure would be genuinely dangerous, and which one would merely be inconvenient?
\nWhat evidence are we waiting for before adding another layer?
\nAt what point does improving the system produce less value than showing it to a user?
\nThese are product questions, not coding questions. AI can help us examine them, but it cannot take ownership of them.
\nIf I do not know what done looks like, the model will not run out of ways to continue. There is always another edge case. There is always a cleaner abstraction. There is always a more complete test suite, a more flexible architecture, a more autonomous agent.
\nThe construction can continue forever.
\nThe people I spoke with are often at an earlier point in the same loop.
\nThey want an agent, but have not chosen a task. They want a second brain, but have not built a habit of producing or using knowledge. They are collecting tools for a version of themselves who will begin serious work later.
\nThis is not stupidity. It is a predictable response to the way AI is presented online.
\nThe most visible content shows possibility. It gives us the exhilarating sense that one person can build a company, automate a profession or create a digital workforce. What it rarely shows is the ordinary work of choosing one problem, testing one outcome and discovering that the impressive architecture was not necessary.
\nHype makes preparation feel like participation.
\nYou can spend weeks learning about agents without delegating one useful task. You can design a knowledge system without having knowledge you need to retrieve. You can watch people build businesses while remaining a permanent student of business.
\nThere is nothing wrong with learning for its own sake. The problem begins when learning becomes a convincing substitute for deciding and doing.
\nI am not abandoning Agent Company Index. I still believe in the idea. I have already started removing the things that do not help the central action, and I will continue developing it.
\nBut I am changing the order in which I earn complexity.
\nFor my own work, the sequence now looks like this:
\nThis does not mean removing all tests or ignoring security. Some risks deserve protection before the first user arrives, especially when money, personal data or irreversible actions are involved.
\nIt means matching the protection to the evidence and the stage of the product.
\nA prototype needs to answer whether the idea is useful. A production system needs to remain dependable under real use. Confusing those stages can make the prototype so elaborate that it never gets the chance to teach us anything.
\nI still think artificial intelligence is one of the most powerful technologies available to an individual.
\nIt allows us to turn an idea into something testable with extraordinary speed. It can help a person cross disciplines, challenge assumptions and produce work that once required a team. I have experienced that leverage directly, and I do not want to go back.
\nBut speed only helps when it shortens the distance to reality.
\nIf it shortens the distance to another abstraction, another internal system or another month of preparation, it can make us more efficient without making us more effective.
\nThat is the trap of eternal development. You are always moving. The commits accumulate. The system becomes more intelligent. The work becomes harder to explain. Yet the first useful result remains exactly where it was.
\nThe hardest question in AI-assisted building is no longer “Can we make this?”
\nFor a growing number of ideas, the answer is yes.
\nThe harder questions are: “What is this supposed to change, and how will we know when it has changed?”
\nWithout those answers, AI gives us the ability to build forever.
\nWith them, it gives us something much more valuable: the ability to find out what is worth building.
\nIf you want more field notes about using AI in real work, without turning every new tool into a new religion, join the newsletter below.
","date_published":"2026-09-15T00:00:00.000Z","tags":["AI and building"],"language":"en","authors":[{"name":"Slava Spitsyn","url":"https://slavaspitsyn.com/about/"}],"_syndication":{"service":null,"syndicate":["linkedin","medium","substack"],"lang":"en"}},{"id":"https://slavaspitsyn.com/notes/skills-ai-cannot-choose-for-you/","url":"https://slavaspitsyn.com/notes/skills-ai-cannot-choose-for-you/","title":"The Skills AI Cannot Choose for You","summary":"AI can produce answers at astonishing speed, but systems thinking and mathematical reasoning help us decide which problems matter, what an answer changes, and whether it deserves to be trusted.","content_html":"I keep seeing the same reaction to AI: people rush to learn the newest tool before the previous one has even settled into their work.
\nI understand it. I do the same thing. A new model appears, a new agent becomes possible, and suddenly yesterday’s workflow looks old. Some skills that took years to build are becoming cheaper almost overnight. Drafting routine text, summarising documents, producing a first version of code, collecting basic information — none of this has disappeared, but the scarcity around it is disappearing.
\nThat made me ask a different question.
\nInstead of trying to predict which profession will be safe, what can I train that will still help me when the tools change again?
\nI have a hypothesis. There are two skills that form something like the supporting walls under the same roof: systems thinking and mathematical reasoning.
\nI cannot prove that either of them will remain valuable forever. “Forever” is a dangerous word, especially now. But the faster AI develops, the more important these two abilities seem to become.
\nJobs are bundles of tasks, and AI does not affect every task equally. The International Labour Organization estimates that one in four jobs worldwide has some exposure to generative AI, while saying that transformation is more likely than outright replacement. The World Economic Forum expects 39% of workers’ current skill sets to change or become outdated between 2025 and 2030. In the same report, analytical thinking remains the most sought-after core skill among employers.
\nThose forecasts are not laws of nature. They are signals. And the signal I take from them is that protecting one fixed professional identity is probably a weak strategy.
\nIf a person defines their value as “I produce this particular output in this particular way,” AI can put pressure on that value very quickly. If the person can understand the larger situation, define the real problem, see consequences and test whether a proposed answer makes sense, they can move when the tool changes.
\nThe output may change. The ability to orient yourself remains useful.
\nMost problems arrive disguised as isolated tasks.
\n“We need more leads.”
\n“We need to publish more content.”
\n“We need to automate support.”
\nAI is extremely good at helping with a clearly framed local task. It can generate landing pages, campaigns, messages, scripts and automations at a speed that was impossible a few years ago. But increasing the output of one part can make the whole system worse.
\nMore leads can overload delivery. More content can weaken trust. Faster support can hide a product problem that should have been fixed at the source. A local improvement can create a downstream cost, and that cost often arrives with a delay.
\nSystems thinking is the habit of looking beyond the visible event. What produces it? What reinforces it? Where is the bottleneck? Which part is reacting with a delay? What behaviour does the current incentive reward? What happens after the obvious first result?
\nThis matters with AI because AI makes local optimisation cheap. We can now produce more changes, faster. That also means we can produce second-order damage faster.
\nThe systems thinker does not merely ask, “Can this be automated?” The better questions are:
\nThese questions are not a defence against technology. They are what allow technology to be used without becoming trapped by its speed.
\nWhen I say mathematics, I do not mean that everyone needs to become a mathematician or return to pages of school exercises.
\nI mean the discipline of making vague claims more exact.
\nHow much? Compared with what? How often? Over what period? What is the base rate? Which variable changes the result most? What would have to be true for this conclusion to hold?
\nAI can produce an answer that sounds precise even when the assumptions beneath it are weak. Mathematical reasoning gives us a way to resist that surface confidence. It trains the instinct to check scale, units, probability, proportions and uncertainty.
\nSuppose an AI system claims that an automation will save a team a large number of hours per year. The calculation may be correct inside the assumptions it was given. But how often is the process actually performed? How many people will use the automation? How much time will checking mistakes consume? What is the cost of one serious error? Does the saving remain meaningful if adoption is only half of what we expect?
\nThis is mathematics in a practical sense. It turns an attractive statement into a model that can be questioned.
\nIt also trains a certain kind of honesty. An equation forces us to reveal what we are assuming. A probability reminds us that confidence is not certainty. A rough estimate can expose a beautiful idea that simply cannot work at the required scale.
\nSystems thinking without mathematics can become a beautiful diagram in which everything connects to everything, but nothing can be tested.
\nMathematics without systems thinking can produce a perfect answer to the wrong question.
\nTogether they do something more useful. Systems thinking helps us choose the boundary of the problem. Mathematics helps us test what happens inside that boundary. One shows relationships; the other applies pressure to our assumptions.
\nThis is the roof I have in mind. Under one side is the ability to see the whole. Under the other is the ability to reason precisely.
\nAI can help with both. It can suggest variables we missed, simulate scenarios, explain an equation, challenge a causal map and find counterexamples. But there is a difference between using AI to strengthen thought and using it to avoid thought.
\nA 2025 study from Microsoft Research surveyed 319 knowledge workers and collected 936 examples of AI-assisted tasks. Higher confidence in generative AI was associated with less critical thinking, while higher confidence in one’s own ability was associated with more. The study is based on self-reports and does not prove that AI causes people to think less. Still, the pattern is worth noticing: a tool that can extend reasoning can also make it easier to stop reasoning too early.
\nReading helps, but systems thinking and mathematics become useful through contact with real decisions.
\nI would take one situation from my actual life or work each week: a sales process, a content pipeline, a personal habit, a family schedule, a product, a community or a financial decision.
\nThen I would do five things:
\nThat last part may be the real skill: building models of the world that can survive contact with reality and still be updated.
\nThinking in Systems: A Primer by Donella Meadows. This is the clearest starting point I have found. It explains stocks, flows, feedback loops, delays, resilience, boundaries and leverage points without turning the subject into abstract theory. The current Russian edition is titled Системное мышление. Как создавать и улучшать системы в бизнесе и жизни; earlier editions appeared as Азбука системного мышления.
\nThe Fifth Discipline: The Art and Practice of the Learning Organization by Peter M. Senge. Useful when the system is an organisation. It connects systems thinking with mental models, collective learning and the ability of a company to adapt.
\nHow to Solve It: A New Aspect of Mathematical Method by George Pólya. A compact book about problem solving: understanding the problem, building a plan, carrying it out and looking back. It is about mathematics, but the method travels well beyond mathematics.
\nHow Not to Be Wrong: The Power of Mathematical Thinking by Jordan Ellenberg. A good bridge between mathematics and ordinary decisions. It shows that mathematical thinking is less about memorising formulas and more about seeing structures hidden beneath everyday claims.
\nI do not want to compete with AI at producing the first acceptable answer. That race already looks pointless.
\nI want to become better at deciding which answer is worth producing, what it will change, how it can fail and whether the evidence beneath it is strong enough. AI can then become a multiplier instead of a substitute for judgment.
\nI do not know which models, interfaces or professions will dominate five years from now. I am increasingly convinced that learning another tool is not enough preparation for that uncertainty.
\nThe roof will keep changing.
\nSystems thinking and mathematics still look like two good walls to build under it.
\nI have been working with AI for a long time, and recently I noticed something strange: I cannot remember a single day when I used it for exactly the same task as the day before.
\nMy problems keep changing.
\nSometimes I use AI while building a project. Sometimes it helps me prepare for a negotiation, investigate an unfamiliar subject, structure a decision, or find a way through a problem I have never encountered before.
\nAs the number and variety of these tasks grow, I become better at finding ways to delegate parts of them to AI.
\nThat, to me, is a much more important skill than mastering one tool or learning one perfect workflow.
\nI see many people who technically work with AI but remain stuck in the same intellectual loop. They keep designing an architecture, refining a business plan, searching for an ICP, or learning how to automate one narrow task.
\nThey may be busy, but they are no longer moving.
\nOnce they find something that works, they stay there. AI becomes a more efficient way to repeat what they already know instead of a way to explore what they could do next.
\nMy experience has been almost the opposite.
\nEvery new task forces me to understand a different problem, find the limits of what the model can do, and decide which parts of the work I can actually delegate.
\nThis is not an easy or passive process.
\nWorking seriously with AI requires an enormous amount of mental energy. I have to formulate what I mean, read the response carefully, notice what is missing, correct the direction, and make the final decision.
\nAI does not remove me from the process. It keeps pulling me deeper into it.
\nAnd after doing this for a long time, I feel that my mind works better.
\nI do not mean that AI has somehow made me automatically smarter. I mean that I spend much more time actively formulating ideas, evaluating answers, comparing possibilities, and turning vague thoughts into explicit decisions.
\nIt is like communicating every day with an extremely capable technology that still needs you to know where the conversation should go.
\nEvery AI system eventually reaches the edge of its understanding of the problem.
\nIf I ask it to work on a question in biology, it may remain inside the frame of biology. It will not necessarily recognise that an idea from physics, business, psychology, or an experience from ordinary life could change the answer.
\nI can bring that connection into the conversation.
\nI can take something I learned in one situation and apply it somewhere that appears completely unrelated. Cognitive scientists call part of this analogical reasoning: recognising a useful relationship in one domain and transferring it into another.
\nThis ability becomes especially valuable when working with AI.
\nA model can give me access to knowledge across many fields. But access to knowledge is not the same as knowing which fields should be connected at a particular moment.
\nThat still depends on the person directing the work.
\nPerhaps this is how expertise is changing.
\nIt is no longer only about spending your entire life inside one narrow domain. AI allows one person to work meaningfully across a much wider range of subjects. But the value does not come from pretending to be an expert in everything.
\nIt comes from combining what you know.
\nThe more varied problems I encounter, the more material I have for making those combinations. A lesson from one project can influence a negotiation. An observation from life can change a product decision. An idea from one scientific field can provide a new way to understand a completely different system.
\nAI can help examine each piece.
\nThe human contribution is often the moment when several pieces that did not seem related suddenly become one useful idea.
\nThis is why I do not want to become good at using AI for only one task. I want to keep giving it different problems. I want to keep finding its limits, improving the way I think, and discovering which parts of my experience can be brought into the next decision.
\n\n\nThe more work I delegate to AI, the more clearly I see what cannot be delegated: knowing when two seemingly unrelated things belong together.
\n
I have never been very interested in technology as a collection of specifications. I care about the moment it crosses into ordinary life — when an impossible idea becomes a tool, a habit, or an entirely new kind of company.
\nThat is probably why I keep returning to artificial intelligence. Models change quickly, but the more interesting questions move at a different pace: What becomes possible when software can understand context? What should remain a human decision? Which impressive demos will become useful systems, and which will disappear?
\nMy way of learning is not especially academic. I usually start by making something. Then I discover what I did not understand, rebuild it, and slowly find the language for it.
\nThis approach has taken me through RAG systems, language models, agents, automation, startups and communities. It has also made me suspicious of clean predictions. The future rarely arrives in a straight line. It appears as a collection of awkward prototypes before anyone agrees on what to call it.
\nScience fiction gave me a way to think about technology long before I could build any of it. Star Trek asked what progress might look like. Star Wars made technology feel lived-in and human. Isaac Asimov turned intelligence into an ethical problem. Dune showed how every powerful tool becomes part of politics, culture and belief.
\nI still return to those worlds — including their older versions and imperfect adaptations — because they are not really about spaceships. They are about people trying to remain people while everything around them changes.
\nThis site is where I want to think in public. Not as a catalogue of services and not as a polished biography, but as a record of ideas becoming clearer.
\nI will write about AI systems, founders, useful models, experiments, forecasts, mistakes, and the signals that seem worth following. Some notes will be practical. Others will be speculative. The common thread is simple: curiosity about what comes next, grounded by the habit of building something today.
\nIf that sounds interesting, join the newsletter. One thoughtful letter at a time is enough.
","date_published":"2026-08-12T00:00:00.000Z","tags":["Opening note"],"language":"en","authors":[{"name":"Slava Spitsyn","url":"https://slavaspitsyn.com/about/"}],"_syndication":{"service":null,"syndicate":["linkedin","medium","substack"],"lang":"en"}},{"id":"https://slavaspitsyn.com/notes/useful-ai-is-a-system/","url":"https://slavaspitsyn.com/notes/useful-ai-is-a-system/","title":"Useful AI is a system, not a model demo","summary":"Why the quality of an AI product depends less on a single model and more on everything built around it.","content_html":"The AI conversation keeps returning to models: which one is largest, fastest, cheapest, or closest to the top of a benchmark. I follow that race too. But the more systems I build, the less I believe the model is the product.
\nA useful AI product is a chain of decisions around the model. What context does it receive? Where does that context come from? What can the system do after it produces an answer? How does a person correct it? What happens when it is uncertain?
\nThese questions are less dramatic than a new model release, but they decide whether somebody will use the product twice.
\nRAG is a good example. People sometimes talk about it as if it were an old workaround that better models will eventually remove. I see it differently. A company does not only need an intelligent answer. It needs an answer grounded in its own changing reality: documents, decisions, customers, permissions, and history.
\nThe same is true for agents. Giving a model more tools does not automatically create a reliable worker. The difficult part is designing boundaries, feedback, memory, and a clear path for human judgment.
\nI am increasingly interested in smaller models inside well-designed systems. A focused model with the right context and a narrow responsibility can be more valuable than a brilliant general model placed in an empty chat window.
\nThat changes how I evaluate AI products. I ask fewer questions about the demo and more about the loop: Does the system understand the situation? Can it act safely? Does it become more useful through real work?
\nThe model still matters. It is just one layer. The product begins when all the layers start working together.
","date_published":"2026-08-11T00:00:00.000Z","tags":["AI systems"],"language":"en","authors":[{"name":"Slava Spitsyn","url":"https://slavaspitsyn.com/about/"}],"_syndication":{"service":null,"syndicate":["linkedin","medium","substack"],"lang":"en"}},{"id":"https://slavaspitsyn.com/notes/shorter-distance-to-a-test/","url":"https://slavaspitsyn.com/notes/shorter-distance-to-a-test/","title":"The real AI advantage is a shorter distance to a test","summary":"A field note on building first, learning in public, and turning ideas into something you can actually judge.","content_html":"I rarely understand a new idea completely before I start building it. My process usually works in the opposite direction: make the first version, notice what is wrong, and then find the language for what I have learned.
\nAI makes this way of working much faster. Not because it removes the need to think, but because it shortens the distance between a thought and a test.
\nAn idea that used to stay in a notebook can become a small interface, a workflow, or a working prototype in a day. Once it exists, the conversation changes. I no longer have to ask whether the idea sounds intelligent. I can ask whether it is useful.
\nThe first version is often awkward. That is not a failure. It exposes the questions that planning keeps hidden.
\nWho is this really for? Which part needs intelligence, and which part only needs a clear rule? What would make somebody trust the result? Is the problem important enough to survive contact with reality?
\nThese questions are easier to answer when there is something in front of you.
\nMoving quickly does not mean publishing every experiment or automating every decision. Some prototypes should remain private. Some ideas become less interesting after the first test. That is part of the advantage too: it is now cheaper to discover that something should not exist.
\nFor me, an AI-first way of working is not about adding AI to every product. It is a habit of reducing the cost of learning. Build the smallest honest version, look at what it teaches you, and decide what deserves the next step.
\nThe future may move quickly, but progress still comes from asking one better question after another.
","date_published":"2026-08-10T00:00:00.000Z","tags":["Founder log"],"language":"en","authors":[{"name":"Slava Spitsyn","url":"https://slavaspitsyn.com/about/"}],"_syndication":{"service":null,"syndicate":["linkedin","medium","substack"],"lang":"en"}},{"id":"https://slavaspitsyn.com/notes/librarian/","url":"https://slavaspitsyn.com/notes/librarian/","title":"Give Your AI Agents a Second Brain","summary":"Librarian turns completed AI coding sessions into searchable memory, so your agents can reuse past decisions instead of rebuilding context from zero.","content_html":"\n\nYour AI agents can write code, plan projects, and solve difficult problems. Then the session ends — and the next one starts without the decisions you already paid to reach.
\n
Librarian is a self-hosted Second Brain for AI coding agents. It turns completed terminal sessions into compact, searchable memories. Later, a connected agent can ask “have we dealt with this before?” and retrieve the relevant decision, fix, or dead-end instead of rebuilding context from zero.
\nLibrarian Starter Kit · one-time €49
\nInstall the same core memory pattern on your own machine. Your agent gets the source, setup guide, database, four MCP tools, and a synthetic end-to-end verification.
\n Get the Starter Kit →\n Explore the live Second Brain\nThis article shows the production system behind the product: what it remembers, how it works, where it failed, and what I changed after running it every day.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Role | Solo architect & operator — I owned the problem, the design decisions, the production system, and its incidents. Implementation was AI-directed (I specified and reviewed; Claude Code wrote the code under my direction). |
| Type | Personal infrastructure turned into a self-hosted Starter Kit |
| My setup | Node.js · PostgreSQL + pgvector · Gemini Flash · Vertex AI embeddings · MCP · Raspberry Pi 500 · Tailscale. The Starter Kit can run anywhere you have Docker; the Pi is my example, not a requirement. |
| Status | In production since April 2026; incident-hardened release since May 2026. Used daily as the memory layer for the several Claude Code agents I run. |
| Artifacts | Architecture doc · 11-entry Architectural Decision Log (ADRs) · operations runbook · incident log — all maintained alongside the code. |
AI agents are stateless between sessions. Every new session starts blind: the agent has no idea what was decided yesterday, which approach already failed last week, or what state a long-running project is in.
\nClaude Code auto-writes a full transcript of every session to disk — but a raw transcript is the wrong artifact to remember from:
\nThe cost of no memory is concrete: the agent repeats mistakes, re-litigates settled decisions, and loses continuity on anything spanning more than one sitting. I was paying — in time and tokens — to re-explain context I had already established.
\nThe task I set myself: capture the signal from each session, make it semantically searchable, and expose it to compatible agents through a clean interface — without turning raw transcripts into permanent memory or requiring a frontier-model bill.
\nFor the person using the agent, the outcome is simple:
\nI built Librarian for my own work first. I defined the behaviour and architecture, directed the AI-assisted implementation, reviewed the output, and operate the production system. The useful part is not a prompt or a screenshot; it is the complete memory loop and the operational decisions behind it.
\nThe commercial Starter Kit packages that core into a self-hosted installation for Docker, with source code, migrations, setup instructions, security boundaries, troubleshooting, and written support.
\nThe design thesis, and the thing that separates Librarian from a naive “log everything and keyword-search it” store:
\nAn LLM sits on the write path and an LLM sits on the read path — and that is deliberate.
\nThe bet is that selectivity at both ends beats a dumb pipe in either direction — dump-everything on write, or blind-inject on read. The smart part is what gets remembered, and what gets recalled and used. I validate this by spot-checking recall against sessions I remember; an automated recall-quality harness (a golden query set) is the top open item — I do not yet measure precision numerically, and I say so plainly rather than assert it.
\nEverything below is in service of this thesis.
\nI ask ChatGPT to save a confirmed project brief in Librarian. Then I open Claude, ask it to retrieve that memory, and it builds the page from the same context — no copy-and-paste between chats.
\nTwo independent services, cleanly split into a writer and a reader — a system can capture memory and serve memory without the two paths interfering.
\nMy production instance mirrors session logs from a Mac to a Raspberry Pi 500, where a harvester processes them. That is one deployment example. The Starter Kit uses Docker Compose and can run on macOS, Linux, or a loopback-only VPS.
\nTwo-layer storage. One memories row per session holds the full human-readable digest; many indexed_chunks rows hold one embedding per bullet, each linked back to its parent. Retrieval ranks on the fine-grained chunks, then follows the link to the full digest only when needed — a cheap two-step over one expensive blob.
Three-level scope isolation. project (coarse) → domain (six fixed buckets: technical, business, reflections, core, content, private) → tags (open-ended). An agent can narrow before it searches, so recall is targeted rather than fuzzy — and private-domain memory stays isolated from shared agents.
MCP as the interface. Exposing recall through the Model Context Protocol means any MCP-compatible agent gets memory with zero custom glue — the same integration shape the agents already use for other tools.
\nSecurity posture (stated, not hidden). The recall endpoint has no application-level auth: the Tailscale network boundary is the perimeter, which is the right trade-off for single-operator use. Token-signing would be a prerequisite before any multi-user exposure — a deliberate, documented decision, not an oversight.
\nSelf-hosted · source included · written support
\nThe Starter Kit includes the database, harvest and explicit-write paths, semantic retrieval, four MCP tools, installation guidance, and proof with synthetic data.
\n See exactly what is included →\nThe full log has 11 entries; these four best show the reasoning style. Each was written down at the time with context, decision, and consequences.
\nPrecision over recall — chunk by structure, not by sliding window.\nThe industry-default RAG chunking is a ~500-character sliding window. Digests already have explicit structure (named sections, numbered bullets), so I chunk one bullet = one chunk instead. One concept per embedding raises ranking precision for narrow queries; a sliding window would have averaged unrelated topics into one vector and blurred recall. (Trade-off accepted: chunks vary in size and the chunker is digest-specific, not a general splitter.)
\nModel the memory, not a graph — an explicit non-goal.\nThere is constant temptation to bolt on the latest graph-RAG paper (LightRAG, Mem0, etc.). I wrote an ADR drawing the line: those systems optimise recall over a static document corpus; Librarian optimises precision over personal session transcripts, where the priority is not hallucinating a decision I never made. The rule that came out of it — borrow retrieval-side mechanics (rerankers, query rewrite), never the storage model wholesale — turns every future “should we adopt X?” from a half-day comparison into a one-line check against a written non-goal.
\nRight-sized model choice. Digest extraction runs on Gemini Flash on the free tier, not a frontier model. Summarising a session doesn’t need frontier reasoning; the free tier covers extraction, and the only metered cost is Vertex AI embeddings (billed per character, cents/month at this volume). Right tool for the job, not the most expensive one — a cost decision I can justify.
\nIndependence over coupling. A neighbouring MCP service had corrupted source on disk (see §7 lineage). Rather than block on repairing it, I made the writer talk directly to PostgreSQL and gave Librarian its own recall server. The system now lives and dies on its own code — no shared component can take it down.
\nThe original MVP was a “Correction Hunter” — extract every “don’t do X, do Y” moment from a session and store it as a rule. First smoke tests killed it: the LLM over-generalised a single in-context remark into a blanket rule, and the same remark phrased differently produced duplicate rules that hashing couldn’t dedupe.
\nI flipped the output format mid-build: one factual digest per session instead of N prescriptive rules. Digests are fact-shaped (“what happened”), which is a far smaller hallucination surface than prescriptive rules (“what should always be done”), and one-record-per-session made idempotency trivial (hash(session_id) — one row by construction).
The lesson I take to interviews: I changed the core abstraction because the evidence said to, not because the original plan was sunk cost.
\ntechnical work with a steady tail of business and reflections. (These counts are the genuinely-digested-since-launch figures; they exclude ~4,150 pre-launch sessions marked skip and a separate legacy file-index corpus that recall filters out.)A production incident I own. A deployment stripped the executable bit off a service wrapper; after the next reboot the harvester silently failed to start — a six-day gap in memory capture before I caught it. The fix was not a one-off patch but a set of durable guards I designed and documented as invariants:
\nExecStartPre=chmod +x), so the failure mode cannot recur;failed state instead of restart-looping forever;OnFailure hook now fires a Telegram alert — so the next silent failure is loud;enable-linger guarantees user services come up on boot without a login.Diagnosing a silent, delayed-onset production failure and converting it into codified invariants — rather than a quiet hotfix — is the operational maturity these roles look for.
\nget_digest), but a weak model yields weak memory.| What you get | Evidence behind it |
|---|---|
| A complete memory loop | Session harvest, explicit write_memory, semantic search, and full-digest retrieval |
| Self-hosted ownership | PostgreSQL + pgvector in Docker; your machine, accounts, and data |
| Agent-first installation | START_HERE.md and examples for supported Codex and Claude Code terminal sessions |
| Proof before private data | Synthetic fixtures and an automated end-to-end verification |
| Operational guidance | Setup, privacy, security, limitations, troubleshooting, and uninstall documentation |
| Commercial use | One buyer or legal entity may use and modify the kit for its own internal and commercial work |
One memory · every connected agent
\nGet the Librarian Starter Kit for €49 as a one-time purchase. You receive the licensed package and setup instructions by email after payment.
\n Get the Starter Kit →\n Secure checkout and invoice by Stripe · no VAT charged under §19 UStG · written support\nBuilt and operated by Slava Spitsyn. Source is private (personal infrastructure); this write-up describes the system without exposing secrets, credentials, or private content.
","date_published":"2026-07-12T00:00:00.000Z","tags":["Case study"],"language":"en","authors":[{"name":"Slava Spitsyn","url":"https://slavaspitsyn.com/about/"}],"_syndication":{"service":null,"syndicate":["linkedin","medium","substack"],"lang":"en"}}]}