How to AI-pill an AI company
Karen Chalco
This article was developed in collaboration with Daniel Liem and expands on the "AI Pilled" playbook he developed at Decagon: how an AI-native company is building internal AI adoption across non-technical teams.
Decagon spends every day building AI agents to handle customer service and support operations for other companies.
Yet even the most innovative AI-native organizations are still working out how to rewire the way their own people work with AI. At Decagon, this meant asking the following: how do you guide AI adoption to facilitate that transformation?
Answering that question became part of Daniel Liem’s work in Decagon’s Founder’s Office, a task force focused on removing company bottlenecks as quickly as possible.
But first, Daniel’s key observation: not every company is ready to make internal AI adoption a priority. In Daniel’s view, companies first have to earn the right to focus on it. They need strong product-market fit, enough operational complexity for the work to matter, and the follow-through to turn experiments into systems. Decagon had reached that point, signaling conditions were ripe for transformation.
This is Daniel’s expanded playbook for AI-pilling Decagon: the field notes behind what actually worked, what stopped scaling, and what it takes to create “aha” moments inside a company that already lives and breathes AI.
1. Systematize grassroots movements, ensure nothing is forced
Early AI enablement at Decagon worked the way it works at most companies: run a training, show a few workflows, answer questions, create some momentum. But as the company grew, that motion eventually stopped scaling. AI adoption could no longer depend on a few people manually showing up team by team. The playbook had to become repeatable.
At Decagon, new-hire onboarding became one forcing function. New hires join on Tuesdays, and AI onboarding became part of that first-week experience.
The company also added:
- Org-wide sessions with different teams
- Small-group trainings across time zones, including non-US sessions with 10 to 20 people in the room
- Public Slack channels for grassroots sharing
- More intentional playbooks
- Events and community work to keep momentum alive between formal trainings
The goal was to create more places where people could see what was working, copy it, and feel a useful kind of FOMO. Done right, this would inspire people to ask themselves, “Why am I still doing this manually?”
2. Build the context layer
Building a context layer into your AI infrastructure makes complex, higher-value workflows possible. The more context AI can safely access, the more it behaves like part of an operating system.
Daniel's approach was straightforward: build out non-native MCPs like Salesforce and Gong, start locally before moving to cloud MCP, and make it as easy as possible to ingest all the context.
For Decagon, adding context from Salesforce was one of the biggest unlocks. Once reps could work with Salesforce data through AI-powered workflows, they no longer had to go into Salesforce directly for every update or lookup.
3. Package the useful stuff before people ask for it
Connecting the systems is only half the work. The next step is making the relevant plugins and integrations easy to invoke at scale, with proper governance and access controls.
Daniel's approach included hosting org-wide skills on GitHub, adding RBAC so teams get the right org-specific integrations pre-installed from the get-go, and building on-ramp mechanisms that drive people to "aha" moments fast.
In plain English: don’t make every employee start from zero, and don’t skip the governance layer.
If someone in sales opens an AI work surface, the useful sales workflows should already be available. If someone in recruiting needs AI support, the relevant skills should already be there. If someone joins the company, they should not need to understand env files, repos, configs, or how to wire together half a dozen tools before anything useful happens.
At the same time, as AI gets access to more systems and more sensitive data, governance stops being optional. Who can access what, and through which agents, becomes a critical design decision for any company scaling internal AI.
Not everyone at a company needs to have access to the same tools and the same data. Some people need Salesforce and Gong pre-installed. Others need recruiting tools. The goal is that each person's AI environment reflects what's actually useful and appropriate for their role, from day one. That is both a security decision and an efficiency one, because people who are more focused on the right context are more likely to find AI immediately useful.
4. Engineer the “aha” moment
For Daniel, an “aha” moment often comes from showing someone that one or two shots can automate a workflow they assumed would stay manual. With the right AI infrastructure, that moment doesn't just stay with one person, and can truly compound across the company.
However, engineering that first “aha” moment can look different from one organization to another. At older or less AI-native companies, a simple automation can feel transformational. At Decagon, the baseline was already higher: employees expected tools like Wispr Flow and Granola as table stakes, so the “aha” moment had to be tied to removing real bottlenecks by enabling more complex workflows.
Once AI adoption is tied to real bottlenecks, it becomes easier to measure whether the playbook is working. Decagon also tracks weekly active usage, AI spend, time-saved surveys, skill usage, and artifact usage. But Daniel’s notes point to a broader goal: moving from isolated experiments to reusable workflows that can spread across teams without one-off enablement every time.
5. Build toward zero friction from new hire to power user
Daniel’s vision is compelling: a one-click internal AI experience that turns everyone into “vibe builders.” He describes the ideal system as having connectors, collaboration features, model pickers, and pre-built workflows available out of the box. No env files, configs, or hosting skills on repos.
Decagon’s playbook maps to this core principle: make the useful path the easiest one. Give people the right context, the right permissions, the right workflows, and enough visibility into what others are building that adoption starts to compound.
That is the shape of Decagon’s answer so far. Daniel figured out that to facilitate the transformation of how your people work with AI, the key is to build an internal system that makes AI feel immediately useful to the people doing the work, instead of simply forcing adoption from the top down.