knowledge based tooling

I was passively scrolling X in the hopes of magically growing my tech account when I came across (this post). In the post the idea of stack overflow for agents is facetiously proposed, given as a "unicorn idea".

While I don't think the idea has *that* much merit, I definitely saw some value in there and internalized it. As luck would have it, I was able to realize this idea a few days later at the insforge hackathon in SF. Because I'm goated, you already know it had a shiest ass name, Snippet, that paralleled its efficacy. I was almost scared to talk about the principles behind this topic, because I was worried about someone stealing recognition for my only novel idea, but I quickly realized no one actually reads this blog so I might as well anyways.

The inspiration is simple. Agents are expensive. With bloated harnesses, agentic loops, and frontier models still having the capability (though rarer) to hallucinate, it's a wonder that tokens are still subsidized. However, if you were to breakdown the workload of the average agent, you would end up find a lot of repeated work.

For example, let's say you are the typical slop merchant of today. You want to release a profitable version of one of your side projects that, let's say, lowballs people on Facebook Marketplace. What is the most efficient way to go about this?

If you're the unenlightened, your options look something like this:

1. Reprompt Kimi K3 (or Claude Fable 5 if your trash can is hard to find) on max thinking to make sure you don't miss a single detail while making "Tinder for bartering"

2. Point your agent at your old project, and tell it what changes you want made

3. Copy the project yourself and *manually* change the variables, naming, and branding to the target project to make sur--yea I'm just kidding

There are express problems between 1 and 2. In 1, you are wasting reasoning tokens relearning lessons that were prompted away ages ago. Option 2 is still not as optimal as possible, since the agent is crawling the entire codebase, learning too much about the old project, given that the task is to make a different one. We are spoiled by generous coding plans and massive context windows to the point that we never check our agent's reasoning trace and see how many useless "thoughts" they generate.

My solution to this was a lot more generalizable to problems besides one shotting React slop. The idea was that Snippet was a tool that would refer to modular, documented code (thought the same principles apply to any agentic context) that agents would not have to generate from scratch. Before I go into some intricacies that make this useful, let me mention some of the benefits behind an idea like this:

1. Massively bolster lower parameter models.

- SLM Research implies that SOTA low parameter models have much larger knowledge gaps than intelligence gaps when compared to their gargantuan peers. A tool that gives them access to a relevant knowledge base could make your gemma-24b-e4b-heretic-Q_4_M.safetensors compete with GPT 5.6 Sol (in theory)

2. Reduce token spend of frontier models

- The original goal for this is achieved more than satisfactorily. During my testing of the snippet tooling I made, I saw a token spend decrease of 33% for the same benchmark task of fixing a broken pandas CSV import with GPT 5.5 with opencode (~4k output tokens with snippet, ~5k output tokens on the agent without. reasoning trace). Though that may be a small example, this would add up over the time of a payment cycle, especially if you're paying API pricing.

3. Faster one shots

- While a lot of simple proof of concepts can be one shotted, when you try to make more intricate apps you need to get a lot more involved. Because a lot of the times, LLMs are chatting shit. They reinvent the wheel, and spend a lot of time reasoning through the steps of a problem that is already solved. With something like this, an agent can just fetch a consensus answer and move on with the task at hand.

4. Greater accuracy

- This significantly reduces the odds of hallucinations due to reliance on deprecated or poorly documented APIs. Imagine if you have a preferred stack without much agent integration (as in, you have to manually approve things on a dashboard). Making new apps in these frameworks tends to be a nightmare. There are a plethora of deprecations, edge cases, and runtime errors that the agent just wouldn't be aware of due to their knowledge cutoff hallucinations. This is my life as I mainly use firebase due to how cheap it is. A fleshed out KBT platform could allow me to save all the errors I have ran into for the type of apps I make, and have my agents never make those mistakes again.

5. Cheaper than web fetch

https://www.reddit.com/r/ChatGPT/s/eEVNciHbSL

https://www.reddit.com/r/ClaudeCode/s/tscymKXGRF

- As other agent-conscious reddit users have pointed out, webfetch is expensive. Most of the results the agent gets back will be irrelevant, or worse: misleading. The only proposed solution I've seen on Reddit, which is the amalgamate of humanity's applicable knowledge, is to use cheaper websearch tooling... KBT solves this by using vector embeddings (cosine similarity, similar to RAG) to fetch only relevant results thus not polluting your context window

6. More efficient than finetuning, works with larger datasets than CAG

- KBT takes significantly less time and data than finetuning an LLM for a specific task. However, it can also use much larger datasets than CAG, as the database would not be bottlenecked by a 1M context window.

7. More detailed than MCP

- Admittedly, there is a lot of overlap between a MCP and KBT. Although there is a key difference: specificity. For example, a coding KBT can catch runtime errors not visible to the LLM simply checking syntax with an MCP. This is useful for bleeding edge libraries that may have bugs the LLM would be unable to properly fix everytime.

since this is already my longest blogpost, I’ll wrap this up with some details on a correct implementation of KBT. For one you need a contract for each “snippet” (general term for example of applicable solution). If it’s code you need a type-safe signature, if it’s microcontrollers you need a predetermined pinout format, etc. The idea is that if you promise “I return/apply to/do this” your agent doesn’t have to waste time verifying or testing that every time. Next is you want the knowledge base to have an exact description to be embedded for agent retrieval later. I choose raw cosine similarity (sometimes L2). All in all, KBT is an itemized agentic RAG format that comes with plenty of benefits.