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 50 specialized AI skills, coordinated by a router that directs questions to the right expertise without holding the answers itself.
~10x lower
QUERY COST
ROLE
Knowledge Systems Designer & Technical Writer
TIMELINE
2026, In active trial
TEAM
Enablement, Solutions, Sales, PMM, Engineering
TOOLS
Claude Cowork, Zendesk Guide, Notion, Guru AI
01
THE CHALLENGE
The answers existed. Finding the right ones was the problem.
Da Vinci's product knowledge was distributed 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 became more pronounced across teams. Sales, Solutions, PMM, Development, and Enablement needed different kinds of answers, sometimes requiring information from multiple knowledge domains. Traditional keyword search could retrieve matching content, but it couldn't reliably interpret the question, select the right expertise, or synthesize information across domains.
I needed to make product knowledge easier to access without building a system that became increasingly expensive, unreliable, or difficult to maintain as the library grew.
"Is there a way to hook up the Help Center to Claude? Getting access to that info would be a major unlock."
— Lead Solution Consultant
02
THE INSIGHT
Don't make the model know everything. Make the system better at routing.
I explored several approaches to AI-assisted knowledge retrieval.
A general AI assistant seemed like the obvious solution, but it introduced a different problem: every question could require the model to search, read, and reconcile large amounts of content.
Zendesk Guide didn't provide a direct connector for the workflow I needed. Using Claude in Chrome to read help center pages live could retrieve information, but token consumption grew quickly, and cross-topic synthesis was inconsistent. Guru AI offered a lower-cost alternative, but its retrieval approach tended to surface a best-matching card rather than combine information across the domains a question might involve. Neither approach gave me the routing control I needed.
The breakthrough was to separate two responsibilities:
Finding the right expertise and providing the answer shouldn't be the same job.
Instead of creating one assistant with access to everything, I designed a lightweight router that identifies the relevant knowledge domain and delegates the question to a specialist.
03
THE SYSTEM
One router. Fifty specialized knowledge domains.
I built Everything Da Vinci around 50 specialized knowledge skills and a central router, dv-find. The router identifies the right specialist without holding or generating answers itself. It uses a live help center index and two lookup files, with a static routing table as backup.
The system has five components:
Question intake: Users ask questions in natural language.
Knowledge router:
dv-findidentifies and routes questions to the relevant skills.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 maintains skill discovery if the live index is unavailable.
The result: a scalable system that grows through specialized skills, not an increasingly complex central assistant.
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 unavailable dependencies.
The live help center index improves routing, but the system shouldn't lose its ability to find skills whenever that index is unavailable. I added a static routing table as a fallback, preserving skill discovery without relying entirely on a live connection.
05
THE TRANSFORMATION
From searching everything to routing precisely.
Before Everything Da Vinci, users had to identify the right search terms, review potentially overlapping articles, and reconcile information themselves.
A general AI assistant could reduce some of that work, but it still needed to retrieve and process broad context. The routed system changes where that effort happens. The user asks a question once. The router identifies the relevant expertise. The specialist works with 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, Development, and Enablement.
In the comparison captured during development, routed queries used approximately 5,000–15,000 tokens, versus 10,000–50,000+ tokens for the browser-based Claude approach on comparable questions. This supported an approximately tenfold reduction in query cost in the measured comparison, although the exact ratio varies by question.
"Is it okay for me to share Everything Da Vinci with my wider team? It's been amazing!"
— Lead Solution Consultant
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 five interconnected components:
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.
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 required 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 to create specialists with clear responsibilities while keeping the system easy to navigate and extend. The lesson: a useful AI knowledge system depends as much on information architecture as it does on the model answering the question.
As the trial expands, I'd focus next on evaluating answer quality, identifying routing failures, and establishing a sustainable process for updating skills as the product changes.
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!