On May 13, 2026, we launched a starting point of an enterprise AI harness for Nokia’s engineers. By day 100, around 2,500 engineers were using it. Today we have more than 3,000+ users. Along the way, we’ve shipped 9 releases and gone from v1 to v3.

In this post, I like to share some reflections on how we achieve this.

What we actually built

“Enterprise harness” can sound abstract, so here is what it means for us. It has three inter-connected parts:

• A marketplace: It hosts 600+ agents, tools, and skills covering the full product development lifecycle (PDLC) at Nokia, from product definition and design to coding, testing, and deployment and beyond.
• An efficiency platform: It monitors, guides, and enforces how effectively AI is used, through telemetry, skill optimization, and customized telecom models.
• An agent control plan: It lets engineers orchestrate, run, and deploy those 600+ assets with ease, without needing to understand the plumbing underneath.

Together, these form the layer that connects our engineers to AI inside their real development workflows.

Here are the three lessons that got us here. None of them are about models 🙂

Key-point #1: You can’t ship AI with an old org chart

The first thing I realized was uncomfortable: we could not build AI products and systems with the team structure and operating model we had.

The issue wasn’t talent alone. It was mindset and design. When people operate inside a fixed charter, with fixed scopes and fixed boundaries, every new idea starts with a question about ownership instead of a question about users. In a field that changes month to month, that’s fatal.

So I rebuilt the organization from the ground up, around two very different talent profiles:

• AI builders: The leaders of this cohort are general product leaders.They know the numbers, understand the systems, and drive outcomes. They lead truly full-stack engineers. One builder takes an idea from product definition through design, architecture, implementation, testing, and deployment, and keeps going after launch. The difference in daily work is striking. There’s far less alignment and roadshow, and far more building. More than one of our partners was surprised that a team our size could ship a marketplace, an efficiency platform, and a control plane in a matter of months.
• Applied researchers: Their leaders sit side by side with the builder leaders. These are product and system researchers, not academic ones. Their job is to understand where the product is heading and to think strategically about which ideas and implementations to start now, planting seeds that will matter in three or six months. Our customized telecom models are one example of a seed that grew into a core part of the platform. I asked the researchers to sit within the builder cohort and implement alongside them. Research that never touches the product doesn’t survive in this model, and it shouldn’t.

Put together, this is what I mean when I say we need to revitalize both the “R” and the “D” in R&D. For years, many R&D organizations have quietly become mostly “D”: execution against roadmaps. AI rewards teams that do both at the same time, in the same room.

None of these leaders or individuals came off the shelf. These profiles barely exist in the job market. Over the past year, I hired and grew a handful of phenomenal leaders to run this AI-native experiment with me. This fall, we’re seeing the results.

Key-point #2: Treat AI systems as products, not tools

The most common fallacy I see in enterprise AI is treating AI systems as tools.

A tool has a fixed purpose and a fixed scope. You build it, hand it over, and move on. That framing is the same obstacle as the old org chart, just in a different form.

A product is different. A product exists to solve a user’s pain, and when that pain shifts, sometimes quickly, the product has to shift with it.

From the start, every major idea in our harness came from carefully sensing what was hurting developers across the organization, and why existing platforms and tools couldn’t close that gap. That’s where we started, not with “what can this model do?”

Then we ran it like a product, because it is one:

• We study the landscape: For every major release, we do a competitive review and make sure we understand our positioning, both against what’s available internally and against what’s on the market.
• We live in the numbers: Every day, we look at user counts and the full funnel, from first click to conversion to repeat use. I look at them myself. The number I watch most closely isn’t total users. It’s how many keep coming back (93% of users are active on the system). Engineers don’t keep using something because they were told to. They keep using it because it solves a real problem.
• We built our own growth engine: We created a new notification platform that connects users directly to the system. Experience from consumer-style user growth helped us write tailored messages for different user cohorts. It turned out to be one of our strongest levers for adoption.
• We dogfood everything. I’m an early test user of every release. In meetings, I ask leaders and engineers to bring the live product to the screen rather than present slides about it. A product culture starts with leaders who use the product.

Key-point #3: Get in the room with your users every week

Early this year, I started a weekly Monday AI forum, open to hundreds of engineers across the company.

The format is simple. Engineers demo real outcomes from using AI in their own development work. We don’t use pure slide shows or status updates. We asked presenters to cut the number of decks, and yes, I interrupted presenter multiple times when there are too many pages of PowerPoint.

The forum quickly became more than a showcase. It became our nervous system. Every week we learned who our heavy users were, what questions kept coming up, and where people were getting stuck. That signal flowed straight back into the what we build.

Over time, it also became one of our launch channel. All nine of our releases so far have been rolled out and demoed there first, in front of the people who will actually use them.

My mandate to the team is to iterate and keep moving forward. Going from v1 to v3 in under five months only works if you’re willing to change course. That sometimes means making hard calls. When the user numbers made it clear an area wasn’t solving a real pain point, we stopped pursuing it, even when we liked the idea. The numbers speak, and we listen.

The space is more open than it looks

Building at the front row of an enterprise-scale AI system has been one of the most fascinating experiences of my career.

Here is the counterintuitive part. With so many AI platforms and tools launching every week, it’s easy to conclude that the space is crowded and there’s nothing left to build. From the outside, that looks true.

From the inside, it’s not. Every large company in AI transformation has specific, deeply contextual pain points that no off-the-shelf tool fully solves. Our 600+ assets exist because Nokia’s engineers needed things that weren’t on the market, like telecom-specific workflows that fit how we actually build products. If you pay close attention to those pains, there’s a lot of open space to build modern AI products and systems.

We didn’t do this alone. We built it with important partners, including Cursor, Google, AWS and AG2, and I’m grateful for what we’ve learned together.