ONE SKILL INSTEAD OF SIX

Viacheslav Bochkarev — Tue, 18 Aug 2026 09:13:50 +0000

When I started wiring up AI agents, I did what everyone does: I kept adding tools. One tool remembered facts. Another compressed web search results. A third summarized long conversations. A fourth shared state across a team of agents. Before long, my agents were juggling a pile of little integrations, each with its own storage format, its own context cost, and its own way of failing.
So I collapsed all of it into a single skill. Here's what that looked like, and what broke along the way.

The fragmentation problem
Every agent capability I needed had become a separate moving part:

Memory — facts that survive between sessions, found by meaning, not keywords.
Web search savings — search results are 5–15K tokens per article; dumping them raw into the model is expensive.
Thread memory — long conversations that don't fit in context but still need to be restorable.
Team memory — several agents writing into one shared namespace so an orchestrator can see "what the team already knows."
Live handoff — an agent resuming work after /new, a restart, or a crash, without asking the human "where were we?"
Archive — old facts that shouldn't slow down search but must never be lost.

Six tools meant six integrations, six storage files, six context blobs, and six things that could drift out of sync. The overhead was eating the savings.

The unifying idea: everything is a node
I asked a dumb question: what actually differs between a remembered fact, a compressed article, a conversation summary, and a team note?

Almost nothing. All of them are just "a labeled thing with content, a security level, and an expiry." So I built one primitive and stopped building tools:

A single local encrypted graph, where every capability is just a node with a label, tags, a TTL, and a security level.

One storage format (a .web file). One crypto layer. One CLI. The six "products" became six ways of using the same graph.

Security became a single axis: L1 / L2 / L3
Instead of each tool inventing its own access rules, I gave every node one of three levels:

• L1 (public) — names, tags, cities. Anything can see it.
• L2 (private) — notes, roadmap. Encrypted with the agent's key.
• L3 (secret) — API keys, passwords. Encrypted with the user's key, and it never reaches the LLM context at all — the model only ever sees a 🔒 placeholder.

One important consequence: the model literally cannot leak an L3 secret, because it never saw it. That's a stronger guarantee than "please don't print the API key."

How each function collapsed into the graph
Memory is just nodes and edges:

node = graph.add_node("Anna", "Client, loves coffee without sugar", tags=["person"])
graph.add_edge(node.id, "company-inc", "founded")

Web search savings became a compress-and-cache step in front of the search call — measured at 96.2% fewer tokens per article (12,975 → 489):

compressed, stats = compress_article(article_text, query) # saved_pct=96.2

Thread memory keeps the full history in the file and sends only a compressed summary to the model — 72% fewer tokens, details restorable on demand:

vibo dialog add "client asked about pricing" --topic pricing
vibo dialog compress # old messages → summary
vibo dialog ask "what did we agree 3 days ago?"

Team memory is just a namespace with authorship and TTL — one agent writes, the orchestrator reads one digest:

vibo add "health" "disk 48G" --namespace team:x --by sys-agent --ttl 6h
vibo context --namespace team:x

Live handoff is a single overwritten state_live node — read it first on startup, update it on every stop:

vibo resume # "where was I" — one node, always current
vibo save-state "summary" --done --next

Archive is a two-tier "desk + drawer": an active memory that search touches (fast, cheap) and an archive that everything eventually lands in (never lost, queried on demand).

The honest tradeoffs

Combining everything into one skill is not free:

Bigger surface. One skill now does six things, so it's more to test, more to document, and more to keep honest.
It's a commercial skill. One license key, one machine, a license check on every run. I decided against a free tier with "built-in" keys — every install requires activation.
The honest floor matters more than the ceiling. ViBo must never cost more than no-ViBo: with a small memory (~100 facts) the skill stays silent and adds no overhead; only once facts pile up (10K+) do the savings appear — 50–150× fewer tokens.

That last point is the one I care about most. A tool that "sometimes saves you tokens" but quietly wastes them when your data is small is a tax, not a feature. I'd rather the skill say nothing than pretend it helped.

What I'd do differently

If I started over, I'd unify the storage and security model before building the first feature, not after. The compression, the semantic search, the team namespaces, and the handoff state all turned out to be the same graph operation wearing different hats — and realizing that late meant a few rounds of refactoring that a single primitive would have avoided.

The win, though, is real: agents that used to depend on a toolbox now depend on one skill, with one file, one encryption model, and one honest savings number.

Built by Viacheslav Bochkarev. Source: github.com/vnbochkarev-netizen/ViBo-memory · wwwvibo.com

ZIP Stores Documents. ViBo Understands Them.

Viacheslav Bochkarev — Fri, 14 Aug 2026 16:56:41 +0000

The Living Archive: How My Agent Started Working Through ViBo

My AI agent had a problem that every agent has: too many documents, no memory.

98 files. 9 MB. Business plans, contracts, requisites, notes, decisions. When the agent needed an answer — "what did we propose to partner X?" or "what are the tax benefits of zone Y?" — it had to open files one by one. Slow. Expensive. Unreliable.

So I built a LIVING ARCHIVE: my own format (.vibo), compression, semantic search. And then I did the hardest thing: I made my agent actually work through it. Not as a test. As its only working memory.

Here is the proof, measured on real data.

The archive

98 working documents (9 MB) became one file: 808 KB.

33 .docx files (business plans, a proposal to a partner, a service contract, company requisites) — now indexed as TEXT. Earlier they were opaque binaries. Now the full text is searchable.
Junk is filtered automatically: package.json, tsconfig, tailwind configs, node_modules, build artifacts — never enter the archive. Only real documents.
The agent answers ONLY through the archive: vibo archive search archive.vibo "question".

Real questions, real answers

"proposal to partner about the project"
• Found: the actual proposal text ✅

"project essence, key section"
• Found: the exact section of the plan ✅

"company requisites"
• Found: the requisites, extracted from .docx ✅

"margin on product X?"
• Found: the pricing document, 100% tokens saved

"what tax benefits does zone Y give?"
• Found: the zone Y note ✅

"how much does the product cost?"
• Found: pricing records, 99.7% saved

Savings: up to 99.7% of tokens. The agent reads 2-3 relevant fragments instead of opening 98 files.

Integrity

A real test on 216 files (1.6 MB): pack → unpack → ALL 216 files returned. Zero losses. Full paths preserved, name collisions resolved, extensions kept (.md stays .md). Original files untouched — the archive is a working copy, originals are backed up.

The economics

9 MB of documents → 808 KB archive (9× smaller).
Search: milliseconds.
Token cost per question: near zero (the LLM reads only the essence).
The more documents — the bigger the savings. This is not compression of bytes. This is compression of TIME.

Why it matters

ZIP stores documents. ViBo understands them. A ZIP cannot answer a question. ViBo answers in milliseconds — and now my agent works through the archive as its only memory. Dust is no longer dust. Dust is memory that was waiting for its hour.

ViBo — memory + living archive for AI agents. One license, one key, three languages. Try it: 2-day free trial (https://wwwvibo.com/).

DEV Community: Viacheslav Bochkarev

ONE SKILL INSTEAD OF SIX

The honest tradeoffs

What I'd do differently

ZIP Stores Documents. ViBo Understands Them.