An 8-part series on going from delivery team to agent-native organization — lessons earned, not borrowed. Genesis · → Anxiety · Names Matter · Proof of Value · The Pivot · Co-Creation · The Garage · The Flywheel
Most AI transformation stories skip Phase 2.
They go from “we built some agents” straight to “adoption soared and everyone loved it.”
That’s not what happened for us.
When we introduced the first agents to the delivery team, the reaction wasn’t excitement. It wasn’t curiosity.
It was anxiety. Real anxiety. The kind that doesn’t announce itself clearly. It comes out as skepticism, low usage, polite questions with an edge underneath them.
The edge was: is this going to replace me?
Nobody said it that way. But it was in the room.
There was a second layer too. A small squad had gone off and built things, and now those things were showing up in workflows that had been their workflows. It kind of felt like change being done to them.
“I feel like I’m on the outside looking in at my own job being replaced.”
That’s not a technology problem. That’s a trust problem. Technology solutions don’t fix trust problems.
We made two structural choices. Both matter.
The first choice: we doubled down on agents being teammates, not tools; we gave them all personas and personalities.
This sounds like semantics. It isn’t.
A tool is something you use, or don’t. It sits there. It doesn’t get better. It doesn’t respond to coaching. It doesn’t care if it’s valuable or not.
A teammate is different. A teammate can be given feedback that actually changes how they work. You can advocate for them. You can push for them to be more capable. You have a stake in whether they succeed.
When people have a stake in something, they engage with it differently.
The second choice: every agent got a name.
Reese. Casey. Theo. Mona. George.
Not product names. Not “AI Assistant v2.3.” Real names, each one tied to the function, each one introduced the way you’d introduce a new hire; with context, with expectations, with a clear path to give feedback.
More on this in the next post, but the short version: named agents get coached. Unnamed tools stay static and get ignored. When was the last time your garden rake got an upgrade?
The anxiety didn’t disappear overnight. But it had somewhere to go.
The question shifted from “is this replacing me?” to “how do I best work with this?”
That’s the crack in the door. That’s what Phase 3 is about.
You can build the best agent in the world. If your team doesn’t trust it, you’ve built nothing of value.
Next: Why naming your agents isn’t branding; it’s adoption strategy.
An 8-part series on going from delivery team to agent-native organization – lessons earned, not borrowed. → Genesis · Anxiety · Names Matter · Proof of Value · The Pivot · Co-Creation · The Garage · The Flywheel
We Started in Our Worst Quarter. On Purpose. Q4. Our busiest quarter. The one where we’re all running flat out and nobody has margin for anything extra.
That’s when we decided to pull a small group off delivery and dedicate them to building AI agents.
People thought we were crazy. The timing was bad. But here’s the thing about timing: there’s never a good quarter to change how you work. If you wait for a slow moment, you’re waiting forever.
Three decisions made Phase 1 work. They’re worth naming clearly, because we got all three right (and had gotten them all wrong in an earlier attempt).
Decision 1: Delivery resources. Not new headcount.
The instinct is to hire specialists. Build a separate AI team. Find people with “AI” in their title.
We did the opposite.
We took people already doing the work – people who knew exactly where the friction was, who understood what “a bad Monday looks like” in our workflow – and we gave them dedicated time. Not 10% time. Not a side project. A real squad with a real mandate.
The people who know the pain are the ones motivated to build the cure.
Decision 2: Low-code or nothing.
We made it a mandate: no code-based solutions. No Foundry builds. No MCP servers. No deep engineering.
Partly practical; code means maintenance, and we didn’t have a team to own that. But mostly strategic. The platforms were moving faster than we ever could. Our edge wasn’t engineering. It was application. Low-code kept us in our lane.
Decision 3: Start embarrassingly small.
We had tried the big project approach before. A large-scale agent initiative run as a hobby by people with other jobs to do.
It failed. Not because the vision was wrong. Because nobody owned it, nobody had real time for it, and the scope was too big to make rapid, visible progress.
This time: small agents. Single tasks. The thing you do six times a day that shouldn’t require a human.
Not a meta-agent. Not a platform. Just: let’s automate that one thing that people hate doing.
Out of Phase 1, we had a handful of agents doing small, specific, daily automations. Unimpressive on a slide. Genuinely useful in a workday.
That was enough to move to Phase 2.
The biggest barrier to starting isn’t technology or budget. It’s the belief that you need a huge, perfect project to justify the investment. You don’t.
Next: What happened when those agents met the broader delivery team, and why it didn’t go the way we expected.
In the early 1990s, “networking” on a PC was a jigsaw puzzle. You didn’t have TCP/IP. You assembled TCP/IP:
The right stack
The right network card
The right driver
The right OS version
The right configuration (that you’d only discover was wrong at 2am)
If you’re too young to remember this, imagine that the new thing for your work PC was to connect others send messages…but email only worked inside your company, and was not connected to the internet. You carried a briefcase full of papers home if you needed to work on something after hours. You probably didn’t have a mobile phone, and if you did it was mounted in your car – and only made voice calls.
I worked in customer support at a company that lived at the intersection of hardware, software, and networking. Our application ran across multiple protocols, so we didn’t just watch customers struggle—we helped them fight the puzzle: stack + driver + NIC + OS + application. It wasn’t just technical complexity. It was market immaturity.
This is the LLM market today.
Act I: Monetize the Mess
Inside the company I worked for, leadership was on a path to buy a TCP/IP stack to provide a consistent foundation for our applications.
The absurd part: application teams had to make functionality decisions based on disparate network stacks. Test teams had to test them all. Users had to understand them to get them to work. Then someone kicked the cable out of the adapter under their desk and the whole network went down.
Have you tried Hummingbird and Chameleon on both EtherLink and NE2000? What about when the network has both BNC and 10-BaseT connectors?
Networking vendors made tons of money in the confusion…and the switching costs…and the new versions. I believed the stack (and maybe the network cards) were heading toward commodity status. Essential, but not differentiating. I argued against buying or building a stack.
Act II: Standardize It (the Part Everyone Forgets)
TCP/IP didn’t win because one vendor’s stack was the best. Ethernet was technically deficient to Token Ring. But they both won because they became the standard—and standards create gravity. Once the interfaces stabilized, the application didn’t care whose stack you bought.
That’s the key idea: the application shouldn’t care. The user shouldn’t care. Maybe the IT department cares for a while, but eventually just procurement cares.
Act III: Forget It’s There
Once TCP/IP became “default” and the interfaces stabilized, the market stopped paying premiums for stacks.
Networking wasn’t eliminated. Thinking about networking was eliminated. Who knows which network adapter is in their new laptop today? Can you imagine buying a laptop without connectivity? It’s unthinkable.
History continues to prove the pattern:
Monetize → Standardize → Forget
The LLM World Is in Its “Stack Wars” Era
Today’s LLM discourse sounds like the early 90s networking discourse—just with better fonts and worse certainty:
“Let’s build the stack so we control our destiny. Everyone is doing it; we don’t want to be left behind!”
The value today, in the complexity phase, is the model. The value in the future is the thing that uses those models.
Segmentation: Specialized Providers vs Specialized “Application-Layer Engines”
Yes—there are real segments emerging: coding, personal info management, health, and more.
But the more important question is where specialization will live:
Path A: Specialized model providers dominate each segment
“Best model for coding.” “Best model for health.” “Best model for XYZ.”
Path B: Commodity base models + specialized implementations on top
Fine-tunes, adapters, retrieval, tool-use, memory, evals—packaged as product capabilities. In applications.
Path B is the historical match.
The winning move is applications standardize how they connect to intelligence, and the model selection becomes invisible plumbing.
That’s the interoperability point—and it’s where network effects quietly return.
Network Effects: TCP/IP Interoperated with Networks. LLMs Interoperate with Tools.
TCP/IP’s network effect was obvious: the value came from being able to talk to other networks.
LLMs don’t inherently need to “talk” to other LLMs. They compete on capability.
So where’s the network effect?
It moves up one layer.
That’s why protocols like Model Context Protocol (MCP) matter: they standardize how AI systems connect so developers don’t rebuild bespoke, model specific integrations.
Once connectivity is ubiquitous, the LLMs start to disappear.
Phase 1: Value = Plumbing (TCP/IP stacks | LLM providers)
Phase 2: Value = Interfaces (Winsock | MCP)
Phase 3: Value = Outcomes (Connectivity | Apps & Agents)
The Pattern Is Undefeated
Every platform shift starts the same way:
We monetize the complexity.
Then we standardize the plumbing.
Then we forget it was ever hard.
TCP/IP stacks were once a market category. Now they’re invisible.
LLMs are in their stack-wars era.
The winners won’t be the companies with the prettiest model demo…or even the best model. They’ll be the ones who make magical apps and let you forget the model exists.
My dad passed away 14 years ago this week. About a decade before that, he suffered a stroke that slowed him physically but didn’t stop the way he drew insights (although it did remove some of his filters which produced some surprisingly humorous outcomes). His spark was still there. He had a way of pulling together threads no one else thought to connect, and even after the stroke, he could cut through complexity with a clarity that made you stop and rethink your positions.
He was one of the creators of the original concept of “crossing the chasm” — the framework Geoffrey Moore later popularized in his book (original product here and here – I continue to appreciate Warren Schirtzinger’s passion around maintaining that history). The idea that technology adoption moves differently, that those products that have the greatest early success tend to stall out before going mainstream, was theirs. That kind of insight wasn’t born from reading one market report or trend piece. It came from years of seeing patterns where others saw noise, of spotting trajectories when everyone else was focused on the present moment.
Image from 8/23/89 (36 years ago this week!)
That was my dad’s gift: perspective based on deep experience and wisdom from a history of seeing trends in the static where most just saw what was right in front of them. He could look across disciplines — business, politics, technology, science, human behavior — and connect dots that seemed unrelated until he put them together. It wasn’t just foresight; It was synthesis. He was the ultimate example of David’s Epstein’s Rangewhich may explain why it is one of my favorite books.
Today, in the middle of the AI revolution, I can’t help but think how much the world could use his mind. We’re in a moment where the pace of change is faster than our ability to interpret it. Every week brings new breakthroughs, new promises, new anxieties. There’s an event horizon that most of us can’t see over that has shrunk from decades to years to quarters and now to months as the pace of change accelerates. Models can summarize, remix, and predict, but they can’t provide meaning. They can’t tell us what matters, what’s durable, what’s just noise.
That requires humans who have the scar tissue of experience, who have lived through cycles of hype and disillusionment, who can see not just the product demo in front of them but the trajectory it suggests. My dad was one of those people. And if he were here today, I know he would have a great perspective — and would provide it to me and anyone who would listen — to make sense of what AI means beyond the headlines.
So yes, I miss him because he was my dad. I miss his humor, his encouragement, his presence. But I also miss him for what the world could use right now: a steady voice of perspective in the middle of chaos, a connector of dots when the picture feels fragmented, someone who could see beyond the event horizon and help us chart a course.
In an age where AI is amplifying everything — both the noise and the signal — the ability to find clarity has never been more valuable. That was his superpower; I really miss him.
“The process of change that drives market leadership” – Lee James (March, 1989)
This post is part of an ongoing series about what we’ve learned from augmenting our team with agents. This series shares hard-won lessons from integrating agents into our team. It’s not theory—it’s transformation, in motion.
AI agents struggle to succeed when you treat them like tools. We know this because we’ve been down this path, and 82% of enterprise led agentic projects are shelved after 12 months. “FastTrack Tool #17” won’t spark enthusiasm and drive usage. But Reese and Casey? They changed the conversation.
Here’s what we’ve learned by doing the work:
1. Personas Build Teammates
When we first started talking about agents, the most common reaction wasn’t excitement—there was an undercurrent of fear and anxiety. People worried they’d be replaced.
But after we introduced Casey as a teammate, things shifted. The conversation became: “How can we help Casey succeed and do more for us?” That reframing worked because Casey felt like a person, a part of the team—not a bot.
2. Onboarding, Not Launching
We learned quickly that you don’t launch a teammate—you onboard them.
For us, that meant treating agents with the same discipline as new hires: communication plans, awareness sessions, training, and buddy systems. Adoption improves the moment you stop thinking “tool release” and start thinking “new colleague.”
We do regular reviews with our agents’ performance, just like we do with the rest of the team – more frequent right after onboarding (or iterations of new capabilities, just like promotions). Less frequent as our agents get more experience.
3. Scaling Agents Comes with Responsibility
At first, agents were treated casually—something that was just a test, that could be turned on or off at will. That didn’t work.
Now, our agents are roles on the org chart. Adding or retiring an agent requires a process, because their work has real dependencies. One person’s frustration shouldn’t lead to Winston being deleted on a Friday afternoon any more than it should lead to a human being walked out the door. We need to put the same thought, coaching, iteration, and decision process into all of our teammates; human or not.
4. Personas Force Clarity
Our early experiments taught us that tool development drifts—overlap, redundancy, and confusion creep in. But personifying agents forces sharper thinking.
When Mona “graduated” from a personal helper to a team-level role, we treated it like a promotion. We clarified scope, aligned expectations, set up an owner (manager), and eliminated overlap. Without that discipline, grassroots innovation can quickly tip into chaos (more on this in a future post).
The Big Lesson
This isn’t theory. This is earned wisdom that we’ve learned by doing.
Giving your agents personas isn’t just branding—it’s adoption strategy, trust-building, team culture, and organizational clarity.
Because when an agent stops being Tool #17 and starts being Theo, your team doesn’t ask “Do we need this?” anymore. They ask “How do we help them thrive?”
Signal, not Sentiment 