Your Knowledge Base Needs a Skill Map, Not More Chunks

The easiest way to make an enterprise agent look smarter is to give it more documents. The easiest way to make that same agent fail in production is to give it those documents as anonymous chunks and hope retrieval will sort out the rest.

That worked tolerably for first-generation RAG assistants, where the job was usually “answer this question from the corpus.” But agents are moving into longer loops: inspect the account, compare policies, choose a next action, draft a response, ask for approval, resume tomorrow, and explain what evidence supported the path. In that setting, the agent does not only need a relevant paragraph. It needs a map.

A new arXiv paper, “Knowledge-as-Skill: A Structural Design for Autonomous Knowledge-Base Use by LLM Agents,” names the bottleneck cleanly. Traditional RAG often makes retrieval decisions outside the model: embed a query, return chunks, concatenate context, generate. As tool-using agents improve, the agent can increasingly decide whether to retrieve, what to inspect, and when to stop. The problem is that many knowledge bases do not tell the agent what they contain.

The paper proposes a simple but important shift: package knowledge so the agent can discover and navigate it. Its design has three layers. A discovery layer gives the collection an entry point, centered on a SKILL.md-style file. A navigation layer adds an index.md file per directory, so the agent can move through the collection intentionally. A knowledge layer stores documents with structured metadata such as topic, type, provenance, and lifecycle.

That sounds almost too mundane to matter. It is not. Most enterprise knowledge failures are boring before they are expensive: the policy exists but sits under the wrong name, the implementation guide is newer than the wiki page, the sales exception lives in a PDF with no owner, the agent finds a chunk but misses the adjacent warning, or it cites the right system while using a stale version. More embeddings do not fix that by themselves. The agent needs to know what shelf it is on.

The early results in the paper should be treated carefully. On a preliminary WixQA customer-support benchmark setup, the author reports higher factuality and context recall than cited Corpus2Skill figures, while also reporting lower faithfulness, lower context precision, and more interaction turns. The paper explicitly frames this as directional cross-work evidence rather than a controlled comparison. That caveat matters. The useful lesson is not “this exact format wins.” The useful lesson is that agent-readable structure changes the retrieval problem.

This lines up with how production agent frameworks are already evolving. Anthropic’s guidance on building effective agents emphasizes simple, composable patterns around models, tools, and workflows rather than opaque systems that hide the important control surfaces. OpenAI’s Agents SDK documentation treats tools as explicit operating interfaces: names, descriptions, arguments, and behavior shape what the agent can safely do. MCP resources similarly point toward a world where context is exposed through described resources, not smuggled into a prompt as undifferentiated text.

Knowledge should get the same treatment. If a tool deserves a name, a description, an argument schema, and an audit trail, then an internal knowledge base deserves at least an entry point, a table of contents, source metadata, freshness indicators, and ownership.

For a team building enterprise AI, a “skill map” does not need to start as a grand platform rewrite. It can begin as a disciplined packaging layer around the knowledge you already have.

Create a top-level entry file that tells the agent what the collection is for, what it is not for, and where to begin. Add indexes inside major directories: billing, clinical operations, onboarding, compliance, product support, engineering runbooks. Each index should summarize the local documents, call out the authoritative source, and point to related sections. Put frontmatter on the documents themselves: owner, source system, effective date, review date, audience, sensitivity, lifecycle status, and known superseding documents.

Then make the agent show its work. A production retrieval path should produce a receipt: which entry point it used, which indexes it traversed, which documents it opened, which passages supported the answer, and which freshness checks passed or failed. That receipt is not just for debugging. It is how operators catch the difference between “the model hallucinated” and “the knowledge package led it to the wrong shelf.”

This is especially important in regulated or high-stakes environments. A healthcare operations agent should not treat an old payer PDF, a current contract clause, and a manager’s note as equally authoritative just because their chunks score well. A customer-support agent should not answer from a deprecated troubleshooting guide because the words match. A coding agent should not select a migration pattern from a retired architecture decision record without noticing the lifecycle marker.

The point is not to abandon vector search. Embeddings are still useful for recall, fuzzy language, and discovery. The point is to stop asking embeddings to carry the whole operating model. Let search find candidates. Let the skill map explain the territory. Let metadata distinguish current from stale, draft from approved, internal from customer-safe, policy from example, and source of truth from supporting note.

A practical rollout can be small. Pick one knowledge domain where agent mistakes already cost time: support escalations, internal IT, release operations, sales engineering, or compliance Q&A. Build the entry file and directory indexes manually for the first pass. Add frontmatter to the top fifty documents. Define two or three retrieval receipts the agent must produce. Then test against real tasks, not toy questions: “Which policy governs this exception?”, “What changed since the last version?”, “What document would you inspect next before acting?”, “Which source should override the other?”

The test should measure more than answer quality. Measure whether the agent starts in the right place, whether it asks for the right document, whether it stops when evidence is insufficient, whether it notices stale material, and whether a human reviewer can reconstruct the path. Those are operating behaviors, not just language-model outputs.

This also gives non-engineering owners a concrete role. Legal, operations, support, and clinical leaders do not need to tune embeddings to improve an agent. They can clarify ownership, mark lifecycle status, retire old documents, write better summaries, and identify authoritative paths. In other words, they can maintain the map.

The next generation of enterprise agents will not be separated by who uploaded the most PDFs. It will be separated by who made their institutional knowledge legible enough for an agent to inspect safely.

A bigger context window can hold more fragments. A better skill map tells the agent where it is, what it is allowed to trust, and when it should stop searching and ask for help. For production AI, that is the difference between a chatbot with a library card and an operator with a map, a compass, and a chain of custody.