On this page
RAG (Retrieval-Augmented Generation) became the default answer to "how do I give my AI access to my data" in 2023. By March 2026, even its co-creator has moved on. Douwe Kiela, co-author of the original 2020 RAG paper and CEO of Contextual AI, confirmed the term has been "rebranded" to context engineering: "I think people have rebranded it now as context engineering, which includes MCP and RAG." Wire generates structured, validated, citation-backed content as static files. Your AI agent reads them directly. No vector database. No embedding pipeline. No retrieval latency.
Why RAG Fails Static Knowledge Bases
A RAG pipeline requires document ingestion, chunking strategy, embedding model, vector database, retrieval logic, re-ranking, and prompt assembly. Each component can fail silently. Chunks lose context. Embeddings drift. Retrieval returns irrelevant passages. The system occasionally produces confident wrong answers from poorly chunked source material.
The failure rate is now documented. According to Tobias Pfuetze via Binariks, only 30% of enterprise RAG pilots reach production. Among those that do, just 10-20% show measurable ROI. The gap between demo and deployment is structural, not a tuning problem.
As Rajiv Shah put it: "It's great on 100 documents, but now all of a sudden I have to go to 100,000 or 1,000,000 documents." The arXiv:2412.15605 paper on Cache-Augmented Generation (CAG) quantified the variance: on HotPotQA Small, sparse RAG top-1 retrieval scores a BERTScore of 0.0673. Top-5 jumps to 0.7549. Top-10 drops back to 0.7461. This is not a tuning problem. It is a retrieval architecture problem.
Kiela himself acknowledged the core difficulty: "People think that RAG is easy because you can build a nice RAG demo on a single document very quickly now and it will be pretty nice. But getting this to actually work at scale on real world data where you have enterprise constraints is a very different problem."
Denis Urayev argued that for most applications, a file-first agent reading source documents directly outperforms RAG. The agent iterates, combines information from multiple files, and synthesizes answers the way a human analyst would. The bottleneck was never retrieval. It was source quality.
Vector Databases Are Losing the Cost-Benefit Argument
The embedding-and-retrieve model is under pressure from both ends. Practitioner benchmarks from XetHub show that BM25 keyword search achieves 85% recall with 8 returned results versus 7 for OpenAI embeddings plus vector search. The recall difference is, as the researchers note, "insignificant considering the cost of maintaining a vector database." That cost runs $50-500/month for hosting alone, before any queries run.
DigitalOcean's survey catalogs four embedding-free retrieval patterns. Wire already implements two: BM25 keyword routing in wire/analyze.py and prompt-guided structured retrieval via frontmatter and topic hierarchy.
Microsoft published PageIndex, an open-source framework for hierarchical document navigation using LLM reasoning instead of vector similarity. It explicitly names chunking and embedding infrastructure as problems to eliminate. The framework targets financial filings, legal contracts, and technical manuals: documents with clear hierarchical structure where high retrieval accuracy is critical. Wire's content fits this profile exactly.
The infrastructure market confirms the trend. In 2025-2026, Snowflake spent $250M on Crunchy Data (PostgreSQL), Databricks spent $1B on Neon, and Amazon S3 added native vector storage. Multimodel databases are absorbing vector capabilities, further negating the need for a dedicated vector database.
Cache-Augmented Generation Replaces RAG
CAG, named and benchmarked in arXiv:2412.15605 (December 2024) and validated by 2026 production data, preloads an entire document corpus into an LLM's extended context window and precomputes a key-value (KV) cache. Retrieval is eliminated entirely.
The benchmark results are direct. On HotPotQA Large (64 documents, up to 85k tokens), CAG completed queries in 2.33 seconds versus 94.35 seconds for standard in-context loading, a 40x speedup. On SQuAD Large (7 documents, up to 50k tokens), CAG completed in 2.41 seconds versus 31.08 seconds, a 13x speedup. Experiments ran on Tesla V100 32G 8 GPUs using Llama 3.1 8B Instruction with a 128k token context window.
Accuracy improves alongside latency. CAG scores a BERTScore of 0.7759 on HotPotQA versus 0.7516 for the best dense RAG configuration and 0.7549 for the best sparse RAG configuration. CAG outperformed all RAG baselines across all three dataset sizes tested.
The cost threshold is concrete. According to ucstrategies.com, the cache build cost breaks even at 6 queries, saving 245 tokens per query versus RAG's repeated embedding lookups. Post-cache, CAG processes roughly 10x fewer tokens per query than RAG.
Dr. Sebastian Gehrmann of Bloomberg frames the shift simply: "If I am able to just paste in more documents or more context, I don't need to rely on as many tricks to narrow down the context window. RAG is not necessarily safer."
A working implementation is available at github.com/hhhuang/CAG.
When to Use CAG vs RAG
The 2026 production data establishes clear thresholds, as analyzed by ucstrategies.com.
Corpora under 1 million tokens with weekly or less frequent updates belong to CAG. It wins on latency, accuracy, and cost. This covers product documentation, compliance rules, internal FAQs, and product catalogs. Above 1 million tokens or where sub-hour freshness is required, standard RAG remains viable. Multi-step reasoning or tool execution demands Agentic RAG, but at a cost: SwirlAI Newsletter documents that a single complex question triggers 3-5 retrieval cycles, with token costs scaling per cycle. A single JSON tool schema consumes 500+ tokens; 90 tools reach 50,000+ tokens before any user interaction. OpenAI recommends fewer than 20 tools per agent, with accuracy degrading past 10.
As ucstrategies.com frames it: "Standard RAG sits in an awkward middle ground, slower than CAG for stable data, less capable than Agentic RAG for dynamic workflows."
One practical warning from the same analysis: teams under 5 engineers should not attempt hybrid CAG plus RAG architectures. Routing logic, cache invalidation, and dual-pipeline debugging outweigh the theoretical benefits. Pick one architecture based on corpus size and update frequency.
VentureBeat's 2026 data infrastructure outlook narrows RAG's remaining use case to "static knowledge retrieval." Contextual memory frameworks (Hindsight, A-MEM, LangMem) are replacing RAG for adaptive agent workflows, which means RAG's sweet spot is exactly the space Wire serves, without the retrieval overhead.
The RAG market is still projected to grow from $1.96 billion in 2025 to $40.34 billion by 2035 (ResearchAndMarkets.com, October 2025), but that growth is concentrated in agentic and dynamic-data applications, not static corpus retrieval.
Explore all Wire use cases to find examples of CAG-ready knowledge bases.
How Wire Fits the CAG Architecture
Wire solves the source quality problem that makes file-first and CAG approaches viable. A Wire-managed site sits squarely within the CAG viability window: content updates on a schedule, not in real time, and the corpus stays well under 1 million tokens for most knowledge bases.
Every page Wire generates has validated structure: frontmatter with title, description, and created date; headings following H1/H2/H3 hierarchy; no random formatting. Wire's style guide enforces inline citations with source URLs, so every factual claim has a traceable origin. Internal links between pages create a navigable knowledge graph the AI can follow to find related context.
Wire generates two files that replace retrieval infrastructure directly. llms.txt is a machine-readable index of every page with title, URL, and description. AI agents consume this as their document index. search_index.json is a full-text search index. An agent with file access can search this instead of querying a vector database.
One important clarification: llms.txt is a developer tooling format, not an SEO signal. Google's John Mueller confirmed in mid-2025: "No AI system currently uses llms.txt" for citation decisions. Google AI Overviews use RAG pulling from indexed web content. The actual utility is for enterprise agents and developer documentation workflows, which is exactly how Wire uses it.
91 build rules prevent broken links, thin content, duplicate information, and structural errors. The source material is clean before the AI ever reads it.
Standard RAG pipeline
Documents, chunking, embeddings, vector DB, retrieval, re-ranking, LLM. Failure points at every stage. 70% of enterprise pilots never reach production. 94.35 seconds per query on HotPotQA Large.
Wire + CAG
Markdown files, Wire build, llms.txt + search_index.json + HTML, precompute KV cache, AI agent reads files. No retrieval pipeline. 2.33 seconds per query on HotPotQA Large. BERTScore 0.7759 vs 0.7516 for best RAG.
Setting Up Wire as an AI Knowledge Base
Point your AI agent at the site/ directory after build:
site/llms.txtfor the page indexsite/search_index.jsonfor full-text searchsite/feed.xmlfor recent changes- Individual HTML files for detailed content
If your agent needs additional structured data, use raw_export in wire.yml to make specific markdown files available at their original paths:
extra:
wire:
raw_export:
- llms.txt
Write a _styleguide.md that emphasizes factual density over narrative flow (every paragraph should contain retrievable facts), consistent terminology (an agent matching queries to content needs consistent naming), and section headers as semantic labels (the agent uses headings to navigate).
Wire's enrich command continuously improves content quality. The news command keeps information current. Teams using Wire for competitive intelligence can feed the same structured output to both their website and their AI agents. The crosslink command maintains the knowledge graph. The build command validates everything. The output is a directory of clean, structured, interlinked files, rebuilt on every run, always in sync with source content.
Quick Start
Organize your knowledge base
Create markdown files in `docs/` with clear frontmatter: title, description, and created date on every page.
Build the static site
Run `python -m wire.build` to generate the static site, `llms.txt`, and `search_index.json` in one pass.
Connect your AI agent
Point your agent at `site/llms.txt` as its document index. Precompute the KV cache once. The 6-query break-even means even low-traffic internal tools recover the cost immediately.
Keep the knowledge base current
Run `python -m wire.chief enrich` to improve content quality iteratively. Schedule weekly builds via the bot to keep information fresh.
Limitations
Wire is a build-time pipeline. It does not serve real-time queries. If your use case requires sub-second retrieval from millions of documents, or freshness measured in minutes rather than days, standard RAG is the right tool. Wire fits when your knowledge base is thousands of pages (not millions), updates weekly (not per-second), and quality matters more than latency. That describes most product documentation sites, internal knowledge bases, compliance portals, and FAQ systems.
For teams building AI assistants on top of Wire-managed content, the practical path is clear: preload the corpus, compute the KV cache once, and serve queries directly. No vector database. No embedding pipeline. No retrieval variance. See all Wire use cases for more patterns.