For the past week or so I have been doing a peculiar kind of engineering. I have been extending an AI assistant, and I have been doing it with the assistant. Not by feeding it into an editor as a source file, but by sitting across from it, describing what it was missing, and letting it write the code that would connect the new capability back into itself.
The distinction sounds like a technicality. It is not. It is most of the point, but first, the two things I set out to give it.
A useful assistant needs to reach, and it needs to remember
If you spend real time working alongside one of these systems, two limitations show up quickly, and they are not the ones the marketing warns you about.
The first is reach. A language model on its own is a closed room. It knows a great deal, but only what it absorbed during training, frozen at some point in the past, with no way to look up a current stock price, a headline from this morning, or a fact it was never shown. The model has no way to check its work against the world. For an assistant that is supposed to help with real decisions, that closed room is a serious constraint.
The second is memory. Each conversation starts from nothing. Whatever we worked out together yesterday, whatever preferences I stated, whatever hard-won context we built up over an afternoon, all of it evaporates when the session ends. Every morning I was reintroducing myself to a colleague with a very good education and no recollection of ever having met me.
Neither of these is a flaw in the model. They are the natural shape of the thing. The model reasons; it does not, by itself, reach or remember. If I wanted an assistant that could do those things, they had to be built around it. So over the last week that is what we built.
Giving it something to reach for
The mechanism for extending reach is a small, sensible standard called the Model Context Protocol. The idea is unglamorous and exactly right: instead of baking every capability into the model, you run small independent programs that expose tools, and the model calls them the way a person calls a coworker who happens to know how to do the one thing they cannot. The protocol is just the shared etiquette for that conversation.
We added four of these, one at a time, each because a concrete limitation had annoyed me in practice.
- Web research with citations. When I asked a question about the current world, I wanted an answer grounded in sources it could point to, not a confident guess. This tool (built on Perplexity’s Sonar model) lets the assistant ask a research service and come back with an answer and its receipts.
- News search. A narrower, faster reach for what happened recently (this one goes through Serper), which is precisely the blind spot a model trained months ago has.
- Market data. I keep a brokerage account, and I already had a small authenticated interface I had written for another project to talk to Schwab. Rather than duplicate it, the assistant reuses that existing credential flow and can now pull live quotes and fundamentals when I ask about a position.
- A calculator. This one sounds almost silly until you have watched a language model do arithmetic. They are pattern machines, not adding machines, and they will state a wrong product with total composure. A tool that does exact math removes an entire category of quiet error.
The point of the collection is not any single tool. The assistant can now take a live number from one source, compute something exact with another, and cross-check the result against a third. That is the difference between a system that talks about the world and one that can actually consult it.
Giving it something to remember
Reach was the easier half. Memory was the more interesting one, because it changes the character of the relationship rather than just its range.
What we built is a small, self-contained memory system. Underneath it is nothing exotic. It uses SQLite, the humble embedded database that quietly runs inside most of the software you touch, together with SQLite’s full-text search extension, FTS5. No cloud service, no new server, no dependency that could rot. Facts and salient pieces of past conversations go into a local file. Before each new exchange, the system searches that store and hands the assistant whatever looks relevant, so it walks into the conversation already knowing who I am and what we have been doing.
The underlying technique was not invented for this, and it would be dishonest to imply otherwise. The assistant’s platform, an agent runtime called Hermes, already used the very same database and search engine for a different purpose, keeping a searchable archive of past sessions. What we added was not a new trick but a new role: a curated, deliberately maintained store that the assistant actively writes to and reads from, and that gets folded into its thinking automatically rather than only when I go looking. Same proven machinery, a different job. Reusing something dependable instead of inventing something clever is usually the better engineering, and it is worth saying so out loud rather than dressing the work up as more original than it was.
The effect, day to day, is quiet and large. I no longer re-explain my projects each morning. When I reference something we settled last week, it recalls the shape of that decision instead of asking me to repeat it. The colleague with the very good education has started to remember our meetings.
The part that keeps me thinking
Both of these efforts feel like more than a line on a feature list.
For each of these capabilities, my entire contribution was to identify the need. I said, in effect, you cannot see the current news, and that limits you, or you forget everything between sessions, and that wastes both our time. I did not write the connecting code. The assistant did. It wrote the programs that expose the new tools, wired them into its own configuration, tested them, and in the case of the memory system built the storage layer, the retrieval, and the automatic recall from scratch, then switched it on for itself.
There is a strange loop in that which I do not want to wave away or oversell. A system extending its own reach and its own memory, at the direction of a person who mostly points at what is missing, is a genuinely new way to build software. It is also not magic, and pretending otherwise would be its own kind of dishonesty. I stayed in the loop the whole way. I chose what to build and in what order. I reviewed the code, insisted on tests, and more than once told it to make something smaller, or safer, or to stop and confirm before touching anything that mattered. The first draft came from the machine. The judgment about whether that draft was right, and whether it should exist at all, stayed with the human. That division of labor is not a limitation I am apologizing for. It is the correct shape of the work.
Which is why the two capabilities belong together in one story. An assistant that can reach further into the world is more useful. An assistant that remembers is more useful still. But an assistant that can help build its own reach and its own memory, while a person keeps hold of the questions of what and whether, is something a little different from a tool. It is closer to a collaborator that you are, slowly and carefully, teaching to be a better collaborator.
I named what was missing. It built the way to fill the gap. We did it together, and next week there will be another gap to name.