I'm the one who stood up AI at my company. It started as tools I built for my own work and turned into owning the roadmap: I run the AI meetings, I own the infrastructure and scaling plan, and anything AI-related gets routed to me. There is an AI research group, but its output was research. My job has been turning that into things people across the company can use.
Going to the workflow first
A lot of this starts before there's a tool at all. I sit down with someone and have them walk me through how they work: the steps, the manual parts, the tasks they repeat every week that nobody wrote down. I'm listening for where an agent fits, then I tell them what I see and build it.
I've done this with more than ten people across most of the company: the dev team and senior developers, support, QA, product, legal, and the CEO. With support it was mostly shared practices for using AI on client-facing ticket work. With QA I updated some of their tooling. With legal it was a brainstorm on where AI could help at all. Several of those are turning into agents those teams will use daily, which I'm sharing out now.
Some of the work is written up here: the CEO's PDF-import problem, the developers' accessibility and SQL backlogs, the support-ticket questions that used to mean digging through SVN. Others haven't had a writeup: a ticket-triage agent that sorts and routes incoming support tickets, knowledge agents that answer against our internal documentation instead of sending someone to find the right person. The effect over time is that "build an agent for it" is on the table for the big resource-intensive tasks, the ones measured in hundreds of hours, where it wasn't a year ago.
Not every conversation produces an agent. Some are where I learn which tasks should stay with a person, like the fiscal-data entry behind the PDF problem. Knowing where not to put an agent is what makes people trust the call when I say a workflow is a good fit.
Running the AI meetings
I've never rolled one of these out with a memo. I run our internal AI meetings, and the format is to show something working and let people react. The SQL agent demo is where a senior developer asked me to turn the agents into a shared library. The MCP server demo prompted the same for the dev-workflow tools. Most of what I've been handed to lead came out of that room.
One expedited reporting project landed on me for the UI/UX work. During the breakdown I demoed an AI workflow that extracts KPIs from our reports, in front of the PM, a senior developer, and the CEO. It became part of the CEO's reporting initiative and is now also being looked at as a product to pitch.
The clearest case of the pattern was a meeting with our networking team and three AWS engineers about where to take our AI use. Nobody put me in charge going in. About ten minutes into the technical part, the networking lead asked me to take it from there, because I'd built the things we were discussing. I walked the room through all three MCP servers and how AgentCore, Bedrock, and Lambda would host them for the team.
Nineteen licenses, hub and spoke
We have 19 GitHub Copilot licenses, provisioned after the first round of interest in what I'd shown. I'm the point person for all of them, and I'm interviewing every license-holder one on one: what they do, how they're using the tools, where they're stuck.
The holders are my spokes. It started as roughly one designated person per team; I've expanded it to several developers per team and pulled in senior developers who had a license but weren't really using it. Each of them is a multiplier for their own team, which holds up better than me trying to reach everyone directly.
The constraint now is token budget, not access. The agents have to be token-efficient to run at any scale, which is a real part of the design work, and the results from that are what's driving a reassessment of the budget to expand adoption.
Removing the reasons not to
Getting a team to adopt a tool is mostly removing the reasons not to.
- The first MCP server shipped with a README before anyone asked. The dev-workflow servers are accessible to every developer and have been demoed to the whole team.
- The ADA agent generates SVN patch files, so another developer applies the fixes to their own branch instead of trusting mine.
- The internal site rebuild was built as reusable CSS classes and AI skills, not one-off prompts, so the styling travels.
- The workflow tools (a QA worksheet agent, support triage, a Teams agent) are available to everyone with a Copilot license.
- The agents live in a shared library other developers pull from and contribute back to, so the team improves one instead of everyone rebuilding their own.
Each is a small decision. Together they're the difference between "here's a tool I built" and "here's something you can run."
Teaching a team is not mentoring one person
I've mentored one developer closely. Driving adoption is a different skill. With one person you course-correct in the moment; with a team, the artifact has to stand on its own, so someone who wasn't in the room can use it correctly from the documentation alone.
Four senior developers each pair with me on a piece of it: one on AI capabilities and evangelism, one on the ADA agents, one on the product MCP server, one on the dev-workflow tools, with a fifth likely on our Bootstrap migrations. It's peer collaboration, not me directing a team. I own the direction; they bring depth on their piece.
Adoption is a trust problem
The feature that makes the ADA agent adoptable is the one that looks like a limitation: it proposes changes in two tables and won't touch code without a person approving each one. It reports its own WCAG citations as something to verify rather than a source of truth, and the PDF import tool scores how recoverable a file's data is before anyone commits to it. People run a tool they can check.
Where this goes
Right now I'm building and operating the company's AI function on my own: the roadmap, the infrastructure, the rollout. Five years out I want that to be the job at a larger scale, owning AI infrastructure and the systems that keep it usable by a whole organization rather than one person.
There's also a more independent version. The local AI agent I self-host started partly as a test of whether privacy-first, self-owned AI is something people would pay for. If that holds up, the skills are the same: build the thing, document it, hand it over.