Everything Da Vinci Plugin
One router. Fifty specialists. Product knowledge on demand.
Da Vinci's 400+ help articles held the answers, but keyword search couldn't reliably connect people to them. I designed a knowledge system of 49 specialized AI skills, coordinated by a router that sends each question to the right expertise without holding the answers itself.
Up to 10×
FEWER TOKENS PER QUERY
ROLE
Knowledge Systems Designer & Technical Writer
TIMELINE
2026, In active trial
TEAM
Enablement, Solutions, Sales, PMM, Developers
TOOLS
Claude Cowork, Zendesk Guide, Notion
01
The challenge
The answers existed. Finding the right ones was the problem.
Da Vinci's product knowledge was spread across more than 400 help center articles, covering everything from product features and integrations to operational processes.
As the library grew, the same terms appeared in different contexts. A search for creative, for example, could return several technically relevant articles without identifying which one answered the user's actual question.
The problem grew across teams. Sales, Solutions, PMM, Developers and Enablement needed different kinds of answers, sometimes pulling from several knowledge domains at once. Keyword search could retrieve matching content, but it couldn't interpret the question, pick the right expertise or combine information across domains.
I needed to make product knowledge easier to reach without building something that got more expensive, less reliable or harder to maintain as the library grew.
02
The insight
Don't make the model know everything. Make the system better at routing.
I compared the realistic options before building anything.
Zendesk Guide had no connector for the workflow I needed. Using Claude in Chrome to read help center pages live could retrieve information, but token use was unpredictable and multiplied with every page it read, and answers that spanned topics were inconsistent. Guru AI was cheaper, but it surfaced a single best-matching card rather than combining information across the domains a question might touch. Neither gave me the routing control I needed.
The breakthrough was separating two jobs:
Finding the right expertise and providing the answer shouldn't be the same job.
Instead of one assistant with access to everything, a lightweight router identifies the relevant knowledge domain and hands the question to a specialist.
03
The system
One router. Fifty specialized knowledge domains.
The system is built around 49 specialized knowledge skills and a central router, dv-find. The router identifies the right specialist without holding or generating answers itself. It reads a live help center sitemap in Notion and two lookup files, with a static routing table as backup.
The system has six components:
Question intake: Users ask questions in natural language.
Knowledge router:
dv-findidentifies the relevant skills and routes the question to them.Specialized skills: Each skill owns a defined knowledge domain and receives only the context it needs.
Access boundaries: Separate catalogs keep internal-only knowledge out of the client-facing index.
Fallback routing: A static routing table keeps skills discoverable if the live index is unavailable.
Update loop: After every publish, the skills the new content affects are updated, versioned and announced in a changelog for everyone using the plugin.
The same skills also feed InkLoom, my AI editorial system, which checks every draft against them for product accuracy.
04
Key Decisions
Make the architecture responsible for what the model shouldn't have to remember.
01
Centralize routing. Decentralize knowledge.
I kept the router deliberately lightweight. It identifies the right specialist but doesn't duplicate that specialist's knowledge. This gives each skill a clear responsibility and lets the knowledge system expand without continually enlarging a central assistant. One entry point doesn't require one knowledge base.
02
Give each skill a defined knowledge boundary.
Skills are organized around distinct domains rather than arbitrary collections of articles. Each specialist works with relevant knowledge instead of searching the entire library for every question. The difficult part was making those boundaries specific enough to improve retrieval without creating a maze of overlapping skills.
03
Separate internal knowledge from client-facing access.
Some skills contain internal operational information that clients shouldn't access. I created separate catalogs and excluded internal-only skills from the client-facing index. Access boundaries became part of the system's architecture rather than something left to the model's discretion.
04
Design for staleness and outages.
Curated knowledge has one weakness: it can fall behind the product. So updates are part of the publishing process, not a separate chore. Every published change points back to the skills it affects, and those skills are updated and versioned before the work is done. The live index improves routing, but losing it shouldn't break the system. A static routing table keeps every skill discoverable without a live connection.
05
The Transformation
From searching everything to routing precisely.
Before Everything Da Vinci, users had to find the right search terms, review overlapping articles and reconcile the information themselves.
A general AI assistant could reduce some of that work, but it still had to retrieve and process broad context. The routed system changes where that effort happens. The user asks once. The router identifies the relevant expertise. The specialist works within a narrower knowledge domain and produces the answer.
The system handles the discovery work instead of making every user repeat it.
06
the outcome
A scalable knowledge system, now being tested across teams.
Everything Da Vinci is in active trial across five teams: Sales, Solutions, Product Marketing, Developers and Enablement.
Cost was designed to be predictable. A routed query reads one to three fixed-size skill files, estimated at about 5,000 to 15,000 tokens. The browser-based approach was estimated at 10,000 to 50,000+ tokens for every page read, multiplying with each page a question needed. That's up to ten times fewer tokens per query, and a cost you can know in advance.
07
What I Actually Designed
The intelligence is in the architecture.
The experience is simple: ask a question, get an answer. Behind it, I designed six interconnected parts:
Routing model: Directs questions to the right specialist.
Skill architecture: Organizes product knowledge into defined domains.
Access boundaries: Separates client-facing and internal knowledge.
Lookup and fallback mechanisms: Keep skill discovery reliable.
Update loop: Keeps skills current as the product and help center change.
Scaling model: Expands through new specialists, not a larger central assistant.
The value wasn't putting 400 articles into AI. It was designing a system that finds and applies the right knowledge.
08
The bigger idea
Centralize access. Decentralize expertise.
A large knowledge system doesn't have to become one enormous knowledge base. In fact, making one assistant responsible for every domain can make the system harder to maintain, harder to control, and more expensive to operate.
Everything Da Vinci takes a different approach.
Users get one place to ask questions, while the knowledge remains organized into specialized, independently maintainable domains. The router connects the two.
One entry point. Distributed expertise.
09
Reflection
The hardest part was deciding where one skill ends and another begins.
Building the router was only part of the challenge. The more consequential design work was defining knowledge boundaries: deciding which information belonged together, where domains overlapped and when a question needed more than one specialist.
Too few skills would recreate the generalist problem. Too many poorly differentiated skills would make routing unreliable and maintenance difficult.
The goal was specialists with clear responsibilities in a system that stays easy to navigate and extend. The lesson: a useful AI knowledge system depends as much on information architecture as on the model answering the question.
What the trial has to prove next is quality at scale: measuring how good the answers are across five very different teams, and catching the questions the router sends to the wrong specialist before users do.
Want to know how the routing actually resolves a fuzzy question, or what happens when the live index goes down? Reach out and I can go into the details!