Build knowledge agents without embeddings

Deploy an agent with Vercel Sandbox, Chat SDK, and AI SDK

Most knowledge agents start the same way. You pick a vector database, then build a chunking pipeline. You choose an embedding model, then tune retrieval parameters.

Weeks later, your agent answers a question incorrectly, and you have no idea which chunk it retrieved or why that chunk scored highest.

We kept seeing this pattern internally and for teams building agents on Vercel. The embedding stack works for semantic similarity, but it falls short when you need a specific value from structured data. The failure mode is silent: the agent confidently returns the wrong chunk, and you can't trace the path from question to answer.

That's why we tried something different. We replaced our vector pipeline with a filesystem and gave the agent bash. Our sales call summarization agent went from ~$1.00 to ~$0.25 per call, and the output quality improved. The agent was doing what it already knew how to do: read files, run grep, and navigate directories.

So we open-sourced the Knowledge Agent Template, a production-ready version of this architecture built on Vercel.

What the template does

The Knowledge Agent Template is an open source, file-system-based agent you can fork, customize, and deploy. Plug any source: GitHub repos, YouTube transcripts, documents (e.g., markdown files), or custom APIs. Ship it as a web chat app, a GitHub bot, a Discord bot, or all three at once.

The template is built on Vercel Sandbox, AI SDK, and Chat SDK. Deploy to Vercel in a single click, configure your sources, and start answering questions.

File-based search with Vercel Sandbox

No vector database. No chunking pipeline. No embedding model.

Your agent uses grep, find, and cat inside of isolated Vercel Sandboxes.

Here's how it works:

1. You add sources through the admin interface, and they're stored in Postgres.
2. Content syncs to a snapshot repository via Vercel Workflow.
3. When the agent needs to search, a Vercel Sandbox loads the snapshot.
4. The agent's bash and bash_batch tools execute file-system commands.
5. The agent returns an answer with optional references.

Results are deterministic, explainable, and fast. When the agent gives a wrong answer, you open the trace and see: it ran grep -r "pricing" docs/, read docs/plans/enterprise.md, and pulled the wrong section. You fix the file or adjust the agent's search strategy. The whole debugging loop takes minutes.

Compare that to vectors. If the agent returns a bad chunk, you have to determine which chunk it retrieved, then figure out why it scored 0.82 and the correct one scored 0.79. The problem could be the chunking boundary, the embedding model, or the similarity threshold. With filesystem search, there is no guessing why it picked that chunk and no tuning retrieval scores in the dark. You're debugging a question, not a pipeline.

LLMs already understand filesystems. They've been trained on massive amounts of code: navigating directories, grepping through files, managing state across complex codebases. If agents excel at filesystem operations for code, they excel at them for anything. That's the insight behind the filesystem and bash approach.

You're not teaching the model a new skill; you're using the one it's best at. No embedding pipeline to maintain or vector DB to scale. Add a source, sync, and search.

Chat SDK: one agent, every platform

Your agent has one knowledge base, one codebase, and one source of truth. Yet your engineers are scattered across Slack, your community spread across Discord, your bug reports buried in GitHub. A single agent that understands all three.