This is the text of a keynote address I gave at the AI Accelerator Conference in Los Angeles in August 2026
The question for today is: what happens when every team at your company wants an agent? Okay, maybe not every team, but lots of teams…you get the gist.
I'll be talking about how we tackled this at one of our clients which is one of the largest asset managers in the world.
We've supported this company's AI journey from the beginning. Over the past few years we've partnered with them to:
Roll out Microsoft Copilot to thousands of employees, reaching over 80% active weekly use
Onboard 2,000+ developers to GitHub Copilot and making that a meaningful part of how they work
And most recently, building an operating model for enterprise agent delivery, what we've all ended up calling the factory
The need for this factory became obvious once the first agents went live, started proving useful, word spread, and business demand accelerated. But this was a very different kind of demand than the IT organization was used to: lots of relatively small, fast-moving engagements coming from all over the business, so we had to rethink the operating model.
The factory is structured like this:
At its simplest, there are three components. Product managers embedded with the business shape demand before engineers get involved. At the engineering level, it provides a clear build path to get agents in and out quickly. And it gives engineers a supporting platform so they're not rebuilding from scratch every time.
I want to share three key lessons with you from our factory experience so far.
***
LESSON 1: The right amount of process is just enough, which is more than you think
Everyone always wants to go fast. The default mindset is often that process is bad because it slows things down.
In fact, there was an interview with the product manager for Claude Code. The interviewer asked "How do they ship product features so fast?" Her response: they strip away all the process they can.
The interviewer then asked how they let their source code get published to the universe and what they're doing to stop that from happening again. Unironically, she said they are adding more process.
We also started lean in the pursuit of 'going fast'. Not having process can feel fast, but it's actually a huge time suck: every build is a one-off, people are constantly asking what to do next, how to get access, where to start…it's a mess
So we have added more process to keep the factory running effectively. Setting up environments, getting access for other teams, knowing what you can and can't build, navigating legal, compliance, infosec, dealing with edge cases -- it's a lot to navigate in a regulated company.
There's a saying that "Slow is smooth, smooth is fast". A little extra process lets us be smooth.
LESSON 2: FDEs are overhyped, but you do need a Forward Deployed somebody
If I had a thousand dollars for every time I see FDE mentioned somewhere, I'd have a bajillion dollars and be somewhere on a yacht.
I'm not saying the role shouldn't exist or doesn't add value, but they are being positioned as the only answer to all your AI questions, and the price tag follows… I heard that Ode is billing out 2 FDEs at $1M/month at one of their clients, so that tells you where the market is.
Here's my problem with this "FDE as the default path" thinking.
One, companies already have an engineering bench and not every engineer can or should be an FDE. I've worked with many talented engineers over my career that would not have enjoyed the role or been successful in it.
Two, more importantly, it's confusing a role with the work that needs to get done. How you get that work done is a choice.
There are really two things needed. First, figuring out what should be built. Second, building it.
If we focus on the first part, what does that involve?
Understand the business problem, figure out what the users actually need, identify nuances such as whether sensitive data is involved, or if it might violate company policy, assessing whether the ROI is worth it, and so on
By the way the answer could be: you don't need an agent, you just need a better prompt, or you need a skill, or something else basic
Think about what I just described. That sounds a lot like a product manager, right? You could even call them Forward Deployed Product Managers.
Now lets talk about the second part: building a solution.
By the time anything gets to the engineer in the factory, it is well scoped. They're not wasting time on business discussions that go nowhere. And, because we've got our well-defined processes, they can just crank. It's a higher leverage use of their skill and capacity.
PMs will pull in an engineer early when it makes sense, but it's not the default go to market approach.
The other important role the PMs play is evangelizing to the business. Your average employee is not AI pilled and doesn't understand what's possible with AI, so they self-limit what they think AI can help with. The PMs can show what's possible.
LESSON 3: The factory is only as good as its supply chain
What I'm about to say may be obvious, but the factory only works when you've got the right inputs in place. And the inputs in this case include things like environments, patterns, controls, etc
If you don't have your environment strategy figured out, then the factory team can't quickly spin up environments.
If you don't have your patterns defined, then the factory team wastes time deciding how to solution an agent. Or gets stuck in reviews with infosec.
If you don't have your control plane in place then you're flying blind.
I could go on here.
All this plumbing exists within a platform team. They are like a pit crew on an F1 team. Not having this centrally owned pushes the work on to the engineers, which slows them down and breaks the model.
***
