The DigitalOcean Copilot Journey
From a docs widget to a copilot platform: a year of building AI that users actually trusted
What started as a question box on the documentation site is now a copilot platform. It answers inside the control panel, acts on your account when that makes sense, and other companies build their own documentation copilots on it. The Database Create Copilot was the first product feature built on top.
That took about eighteen months. The question stayed the same the whole way: how do you build AI that people trust enough to rely on?
The answer was four words. The copilot had to be embedded, explainable, editable, and trustworthy. Each word shaped a different part of the design.
Cloud infrastructure is complicated, and pretending otherwise never helps a user. The work was making AI carry some of that complication instead of adding to it.
The criteria
Embedded. Explainable. Editable. Trustworthy.
Four words sat on a slide that the team came back to every week. Embedded means the assistant lives where the work happens, never as a destination of its own. Explainable means every answer shows its sources and reasoning. Editable means every output can be corrected, refined, or rejected by the user. Trustworthy is the outcome the other three produce: when AI is in your product, the user only keeps using it if they know what it knows and what it doesn't.
Where it started
A widget on the documentation site.
The first version was small and contained. You opened the docs site, asked a question in plain language, and got an answer with citations back to the documentation it came from. It was low-stakes on purpose, and it set the bar for everything after: every answer had to trace back to a real source, with no made-up commands or invented flag names. We had to get that grounding visibly right before we'd earned the right to put AI anywhere else in the product.
The leap
From a chatbot to a UX layer.
The leap was deciding the docs widget had to move. The team was treating it as a chatbot. We shifted perspective: the assistant is a layer of help, available wherever someone needs it, able to act on their account when it makes sense, and quiet when it doesn't. That changed everything. We stopped designing one feature and started designing something that could spread across the product without taking it over.
The embedded version lives in the control panel as a docked panel you can call up or dismiss. It knows what page you're on, what resources you have, what role you're in. It can explain a billing chart, walk you through creating your first Droplet, or generate a config file you copy into your terminal.
It doesn't replace the parts of the product that work. The Droplets list stays the Droplets list. Billing stays billing. The copilot adds help on top. It doesn't pull you away.
We built three small things around it: an indicator showing what the copilot can see, suggested prompts so the blank box doesn't sit empty, and a "cite sources" toggle on by default. Trust gets built in small moves like these.
The product
Then we shipped it to everyone else.
Strategic partners started asking how they could build something similar. We had a working product and a clear idea about embedded AI. So we productized it. DocsBot lets a company create their own documentation copilot with their branding, analytics, and training. The hardest part was onboarding, because the person we were now designing for might never have trained an AI before.
Most teams assume regular users can't train a bot. Most people are curious about AI and willing to try, with guidance. We built an onboarding pattern called the Golden Dataset: you define ideal answers with real examples, and the bot trains on those instead of the generic web, so it ends up sounding like your company.
Configure is small on purpose: three ways to connect docs, one name field, and a style step for colors, voice, logo, and suggested prompts, with a live preview that updates on every choice.
Training is where the Golden Dataset comes in. You review sample answers, approve what sounds right, edit what doesn't, and skip what you'll come back to. After about thirty examples the tone is consistent, and customers can't tell bot from person.
What it became
It turned into a platform.
PMs, designers, and engineers at DigitalOcean now build on the platform. The next round of copilot surfaces came faster because the trust criteria, the design patterns, and the engineering scaffolding were already there. Nobody had to argue about what good AI design looks like each time someone wanted to add it.
What I'm proudest of is how it changed the design team. AI stopped being a special case and became something we design. We critique it with the same language, hold it to the same trust standards, and test it with the same rigor. The team can ship AI at production quality without a separate AI team becoming the bottleneck.
The four words still live on the wall, and they're how the team explains the work to new hires, executives, DocsBot customers, and themselves. Those words mean something now because the product behaves that way.
A customer said the copilot felt like "a coworker who actually read the docs." We got it right: AI you can trust because you see what it knows and what it doesn't.
Why
- DigitalOcean
- Cloud and Developer Tools
- AI
- Design Leadership
- Product Strategy
- AI Experience Design
- Product Design
- UX Design
- Design Systems
- Wireframing
- AJ Zichella (Design)
- Soyun Park (Design)
- Isabel Shic (Design)
- Kevin Carrillo (Engineering)
Up next
