the apiary
- updates as you work
- + yes continuous capture
- personalized to your project
- + yes
- three-tier recall
- + key, summary, raw
- self-tidying
- + yes
- shared across assistants
- + yes
- a store you own
- + deeplake, on your hardware
The Apiary vs plain RAG
RAG over documents is genuinely great for static knowledge, a manual, a policy, an API reference that rarely changes. Agent memory is a different job. It captures what happens as you work, updates itself as things change, and recalls it later, so it personalizes to your project and stays current instead of retrieving from a corpus that goes stale the day after you index it.
DownloadWhat plain RAG does well
Retrieval-augmented generation over a document set is the right tool for static knowledge. Feed it a manual, a set of policies, an API reference, and it finds the passage that answers a question, then hands it to a model to phrase the answer. The corpus is fixed, indexed once, and the value comes from search quality over material that already exists. When your knowledge genuinely does not change day to day, this is the right shape.
Why coding work does not fit that shape
Coding is not static. The decision to skip an approach, the fix that finally worked, the convention your team agreed on this morning: none of it exists as a document before it happens. A RAG pipeline over a fixed corpus has nothing to retrieve, because nothing was ever written down. What is needed instead is a layer that captures the thing as it happens, distills it into something worth keeping, and makes it recallable, continuously, not as a one-time indexing job. That layer also has to update itself: a convention from last month that got reversed this week should not keep surfacing as if it were still true. Plain RAG has no mechanism for that. Agent memory does, because it is built around change, not around a fixed snapshot.
Where they differ
The Apiary is the highlighted column. "Plain RAG" refers to the common pattern: chunk and embed a fixed document set, then retrieve at query time.
| the apiary | plain RAG | |
|---|---|---|
| updates as you work | honeycomb advantage. yes continuous capture | no. no fixed corpus |
| personalized to your project | yes. yes | partial. only what was written down |
| three-tier recall | yes. key, summary, raw | partial. single passage retrieval |
| self-tidying | honeycomb advantage. yes | no. no re-index to update |
| shared across assistants | yes. yes | partial. depends on setup |
| a store you own | honeycomb advantage. deeplake, on your hardware | partial. depends on the vector store chosen |
Capability comparison of the common patterns, not a benchmark of a specific RAG product. Captured 2026-07.
Two different questions
RAG answers "what does the documentation say." Agent memory answers "what did we decide, and what happened last time." The first question has a fixed answer sitting in a corpus somewhere. The second does not exist until you live it, and it keeps changing. The Apiary is built for the second question, on Deeplake, which stores exact text and meaning together so recall works whether you use the same words or not.
See how it worksrecall "refresh token rotation"
auth/refresh-token.ts:42 ✓ verified
rotate the refresh token on every use; the old one is revoked server side.
session:2f9c-deploy-staging
staging deploys run from the release branch, never from a feature branch.
db/migrations/notes.md:7 ✓ verified
add the column nullable first, backfill, then set not null in a later migration.
Common questions
What is the difference between RAG and agent memory?
RAG retrieves from a fixed corpus that already existed. Agent memory captures new material as you work and keeps adding to it. RAG answers from what exists. Memory answers from what happened.
Is RAG bad, or is memory just better?
Neither. RAG over documents is great for static knowledge like a manual or API reference. It is the wrong tool when what you need to remember was never written down.
Can RAG and agent memory work together?
Yes. Many setups use RAG for stable reference material and a memory layer for what happens as you work. They complement each other more than they compete.
Does agent memory need its own document corpus to work?
No. Its source is your work itself, the sessions, decisions, and fixes that happen as you use your assistant. There is no separate indexing step first.
Give your agent memory of what happened, not just what was written.
One command installs the stack, wires up your assistants, and opens a dashboard in your browser. Your data stays on hardware you control.
Windows (PowerShell): irm https://get.theapiary.sh/install.ps1 | iex
Download