You’ve probably noticed the pattern by now. Every AI agent tutorial you read insists you need a vector database. You need embeddings. You need a semantic search engine. You need LangChain, LlamaIndex, Pinecone, Chroma, Weaviate — the list grows every week like a tumor.
What if I told you that a working AI agent memory layer can be built with nothing but Go’s standard library and a bag-of-words vectorizer? No external ML libraries. No vector database. No embeddings API. Just Go.
The entire AI infrastructure industry is built on the assumption that you’re too intimidated to try the simple thing first.
A developer recently demonstrated exactly this. They built a context engine for an AI agent in Go using nothing but the standard library. The approach? A bag-of-words model — the same technique that’s been around since the 1950s, before “machine learning” was even a buzzword. It tokenizes text, counts word frequencies, and compares vectors using cosine similarity. That’s it. That’s the whole memory layer.
And it works. Not for every use case — let’s be honest about that. But for the vast majority of agent memory tasks (recall, context window management, conversation history retrieval), it handles the job without dragging in a dependency tree that looks like a small operating system.
Here’s where it gets interesting. The article itself became a case study in its own critique. The top comment came from a developer named cheikhdev who called out the writing directly:
“No one is going to read this with all the LLMisms. If you want to write for developers — you’ll have to use your own sentences.”
The irony is sharp enough to cut yourself on. An article about stripping away unnecessary complexity was itself buried under layers of unnecessary complexity — in this case, the bloated, hedging, adjective-stuffed prose that LLMs default to when nobody grabs the steering wheel.
The same disease that infects AI infrastructure infects AI writing: everyone confuses more layers with more substance.
Let’s break down what’s actually happening in the technical approach, because the engineering here is genuinely elegant. Instead of calling an embeddings API to convert text into 1536-dimensional vectors, you tokenize your text into word frequency maps. Instead of standing up a Pinecone instance, you store these vectors as simple Go structs. Instead of a semantic search framework, you compute cosine similarity with a function that fits in 15 lines.
The bag-of-words model has limitations — it doesn’t capture word order, it doesn’t understand synonyms, it treats “the dog bit the man” and “the man bit the dog” as identical. Everyone knows this. But here’s what nobody admits: for agent memory retrieval, those limitations rarely matter. When an agent needs to recall what was discussed three turns ago, it doesn’t need semantic nuance. It needs keyword overlap. It needs “which previous messages contain words similar to what I’m looking at right now.”
Most agent memory problems are keyword problems wearing a semantic costume, and treating them like keyword problems makes your code simpler, faster, and cheaper to run.
The Go standard library gives you everything: strings package for tokenization, sort package for ranking, encoding/gob for persistence. You’re not building a research lab. You’re building a tool that remembers things.
Now, let’s address the elephant. The comment about LLMisms deserves its own moment because it points to a problem that’s about to swallow the entire technical writing ecosystem. When every article sounds like it was generated by the same model — because it was — readers develop an immune response. They scan. They bounce. They stop trusting. The writing becomes noise, and noise doesn’t spread.
The lesson cuts both ways. In code, reach for the standard library before you reach for the framework. In writing, reach for your own voice before you reach for the prompt. The builders who stand out in the AI era won’t be the ones with the most dependencies or the most polished LLM output. They’ll be the ones who strip things down to what actually matters.
Simplicity is the contrarian position now. In a world drowning in abstraction layers, the most radical thing you can do is build something that works with what you already have.
So next time you’re about to pip install six packages for a feature that could be twenty lines of code, stop. Next time you’re about to publish an article that sounds like every other article, rewrite it in your own words. The bar is low because everyone else is tripping over it with their arms full of tools they don’t need.
Walk through the door with nothing in your hands. Build from scratch. Write from scratch. That’s where the real work lives.
FAQ
Q: Doesn't bag-of-words lose semantic meaning that embeddings capture?
A: Yes, and that's fine for most agent memory tasks. When an agent needs to recall prior conversation context, keyword overlap is usually sufficient. You don't need semantic nuance to retrieve 'which messages discussed database migrations.' Save embeddings for the cases where they actually matter.
Q: What's the practical takeaway for a team building AI agents today?
A: Start with the simplest thing that works. Use your language's standard library and a basic text similarity approach. If you hit a wall where keyword matching genuinely fails, then add embeddings. Don't start with Pinecone — start with a for loop.
Q: Is this just nostalgia for simpler tools, or is there a real engineering argument?
A: It's pure engineering. Fewer dependencies means fewer failure modes, faster cold starts, lower costs, and code your team can actually debug at 2 AM. The AI industry's default to maximum complexity is driven by hype, not by what production systems need.