Every company is experimenting on how to best utilize AI to get more done. A coworker automates a task that used to take hours. It feels like magic.
Until it isn't. The moment you try to reproduce that result is where most AI transformations quietly die.
Earlier this year I joined a new role at delight.ai, AI Engineer for Internal Operations. There was nothing to model the job description after. But the goal was clear: find the highest leverage places to apply AI inside the company and implement them quickly. Agents that handle outbound, agents that build marketing campaigns, agents that reconcile billing. Leadership was enthusiastic and I was greeted with docs full of ideas.
The order of operations matters
The first project we thought we would build was the company brain. One layer that everyone could build on top of.
The vision was right. But even if the company brain existed, we ran into questions nobody had answered. Where do apps live? How do you connect to the CRM? Who maintains what gets built? Is any of this compliant? What services are we even allowed to use?
Without answers, Claude started making the decisions for us. Some apps on Netlify, others on Vercel. Some using Neon, others Supabase. Vue here, Next.js there. Google auth on one app, a passphrase on another. Everyone was building, just in completely different directions.
We needed a way to think about where we actually were before we could decide what to build. The AI Transformation Model gave us that.
- Stage 01: One-Off AI. People copy-paste between tools and lean on AI to move their own work along. Gains are real but individual. Nothing builds on itself.
- Stage 02: Connected AI. AI plugs into the company brain. No more copy-paste, it pulls data across systems and aggregates context better than any one person could.
- Stage 03: Autonomous AI. Agents act on their own, making decisions and taking steps that advance the goals we set, without a human prompting each move.
- Stage 04: AI Native. Agents running critical workflows across all teams. Revenue per employee compounding at scale.
To get to Stage 2 we needed to make a set of decisions that would define how everything got built. And from that came three paths.
Path 1: Connectors and Skills. If it could live inside Claude, the answer was an MCP connector. Wire up the data source, add a skill, and the work gets done inside the conversation.
This is the headless approach: Claude becomes the interface and the underlying tools become invisible. A sales rep no longer opens Salesforce to pull a deal summary. A manager no longer logs into Looker to check a number. Instead of 20 clicks to perform an action, you just ask.
Path 2: n8n Workflow. If it needed more coordination across APIs and endpoints that weren't already wired into Claude, n8n serves as a good middle ground. Connect the services, set the trigger, and the workflow runs without anyone thinking about it.
Path 3: Vercel App. And if it needed a real interface, or we wanted something more durable that could scale to the whole company, it became a Vercel app.
For this we built an app template that abstracts the setup problem entirely. Every new app comes out of the box with everything already wired: Supabase for the database, Okta for SSO and permissions, audit logs, credentials pre-wired to BigQuery, Salesforce, Google Workspace, and the rest of the stack, Anthropic and OpenAI tokens routed through the Vercel AI Gateway, and usage analytics with token and model tracking built in. A setup skill walks the builder through what they're trying to make and runs the first pass. The app deploys to Vercel. The whole thing is live in under five minutes.
Even a busy sales rep who has never pushed a line of code to production can build something useful. You don't need to know anything about the underlying infrastructure. The hard work is already done.
The three paths play directly into getting us to Stage 3. Skills and n8n workflows that run on repeat get turned into scheduled tasks or event-based triggers. Slack bots live inside team channels, calling skills and workflows on demand so information moves faster without anyone having to go looking for it. Vercel apps are going headless, exposed back to Claude as MCPs so the work stays inside a single chat window.
Internal adoption
In parallel to building out the infrastructure we also built a platform to focus on adoption.
The Automators Guild is how we organize it. At the moment it includes the following:
- Quest Board
- Leaderboard
- Skills Marketplace
- Building Guides
- Internal Apps
- LLM Wiki
Quest board
Anyone at the company can post a quest, a specific thing they want automated or built. Before it gets picked up, an AI intake process asks the right questions to scope it down to one clear problem: what the current process looks like, where the data lives, who else is involved. A coding agent takes the first pass and opens a PR. From there anyone can drive the quest to completion by approving the PR or making changes as needed. 51 quests are active right now.
Leaderboard
We initially built a token leaderboard to gamify AI usage and exploration. Five tiers, from Beginner to AI God, based on daily token usage. The goal was to get everyone to move up the AI tiers. The leaderboard grew into three: one for token usage, one for the skills marketplace, and one for overall AI engagement.
We solved for usage. Now we are evaluating ROI. The cost of tokens to features shipped to production. The cost of tokens to booked leads for the sales team. The cost of tokens to completed QBR decks for customers. That is the metric that matters now.
Skills marketplace
The platform also has a skills marketplace. Anyone can submit a skill and each team has a plugin that auto-enables the ones relevant to them, so a sales rep opens Claude and the institutional knowledge their team has built is already surfaced. Skills are self-improving. We log usage and results back to the platform so maintainers can see what is working and what is not, and every skill goes through an automated security scan before it ships.
Building guides
Building guides are how-to docs designed to be handed directly to a coding agent. They cover best practices, engineering patterns, test cases, evals, database setup, security requirements, and our internal tooling across all three paths. They take the guesswork out of how to build something the right way from the start.
The guides are self-improving. Our Automators bot in Slack automatically triages AI enablement questions across the company and drafts new guides based on where people get stuck. The more people build, the better the documentation gets.
Internal apps
As tools we build mature they get absorbed into the platform. Our social sharing app Buzzboard, started as a standalone build. So did our competitive intelligence tool. Both are now tabs inside Automators. One app that does many things, not many apps that each do one thing. The goal is to put all our apps behind one pane of glass.
LLM wiki
Underneath all of it is an LLM wiki: a live knowledge base built from every public Slack message, GitHub commit, Gong call, Zoom transcript, Jira ticket, and Google Drive artifacts the company produces. It was the company brain we set out to build on day one. We just got there from the bottom up.
The non-engineers won
Every engineer defaults to coding agents. That was expected. What we did not expect was the depth and creativity of what non-technical teams identified as their biggest problems, and what they built to solve them.
Our marketing and demand gen team built the GTM Command Center, and it is probably the most impressive thing that has shipped on the platform. It runs our marketing campaign plan, coordinates field events, powers an internal tool that mobilizes employees to share company news and social posts, generates creative and copy for Google and LinkedIn ads, and mocks paid landing pages. Built and maintained by marketers.
The data team built Signal Scout, which pulls first and third-party signals including page visits, ZoomInfo, G2, LinkedIn activity, recent news, and new hires at target accounts, and surfaces the highest-intent ABM accounts to AEs with specific plays attached. They also built a competitive intelligence app that uses Browserbase to crawl competitor websites, track changes to pricing pages, landing pages, and ad campaigns, and generate ready-made battlecards. It does what we used to pay a third party tool to do.
None of these started with a roadmap item. They started with someone living a problem. Without the right infrastructure, that problem stays a problem. With it, it ships.
Where we're going
The company brain gets better every day, a shared knowledge layer every team member is wired into that compounds with every interaction. After that, Stage 3. Agents that show up in Slack threads, attend Zoom meetings, and take the next step without being asked. Not as a feature. As a fundamental shift in how work gets done.
But none of that happens without the work that came before it. The unglamorous decisions about where apps live, who maintains them, what services are allowed, how permissions work. We built with InfoSec instead of around them. We standardized before we scaled. We answered the boring questions first so the interesting ones could move fast.
If you are trying to do this at your own company, the instinct will be to start with the most exciting use case. Resist it. Start with the foundation. Decide how things get built before you build them. Give people a path that is already safe, already structured, already ready. Then get out of the way.
The people who surprised us most were the ones we never would have put on a list of AI builders. They just needed the infrastructure to exist.
AI does not feel like magic until you wire in the infrastructure behind it. We are wired in.
Want to go deeper? Check out our podcast episode with Claire Vo on How I AI →