How Next Insurance Broke Its Whole Lifecycle Into Agent Skills

Shay Mandel has spent his career on the boundary between engineering and product. A developer at heart, as he puts it, who also likes to see big systems: how we impact customers, how we improve processes. He joined Next Insurance more than seven years ago, when it was quite a small company that then grew almost a hundred percent every year in revenue until it was acquired. They do small business insurance: think about a technician who comes to your house and needs general liability, and workers comp if he has an employee. They provide all these kinds of coverages digitally, so you can just go online and create a policy with no need for an agent. Across engineering, product management and insurance product, that’s around two hundred people building the product.

For the last three or four months those two hundred people have been moving the product development lifecycle onto agents. What he wanted people to take from the conversation was what a nice goal looks like for a company that really wants to adopt an agentic development lifecycle, some of the struggles getting there, a lot of the learnings and the caveats, and even just setting expectations of how long it will take. So that’s what this is: his account of what they broke into skills, where humans still decide, what the agents get wrong, and what they deliberately left alone. My questions are kept where they moved the conversation, and the full episode is linked at the end.

The first surprise is how much stayed the same.

“I think what we did is we didn’t change the process. We still have a quarterly planning and we have sprint planning and we have roadmaps and a list of features that we want to deliver in a quarter.” : Shay Mandel

That was deliberate. On purpose, they didn’t say let’s jump to the end and let’s change everything, all the processes and everything. They kept the roles, kept the boundaries between engineering, product and insurance product, and kept Jira and Confluence. What changed sits underneath all of it:

“We kind of broke down the existing processes. We didn’t change the processes much, but we said, in order to create good requirements, there are a set of steps you need to do, and we created a skill for each one of them. So like describing the problem. Then analyzing the problem, getting some data, maybe doing some user research, creating wireframes. All of these are things that you usually do. And then eventually you articulate everything in one PRD where you define the solution.” : Shay Mandel

Each step is its own skill, and there is a router sitting above them:

“There is like an uber skill that kind of helps you route. You say I want to do this PRD, it can tell you what stage are you in, and then it will direct you. And then it helps you, it’s interactive, it asks you like, okay, you want to define the problem, let’s define it. How do you measure it? What do you expect the impact to be? And it kind of interviews you and eventually it creates the section in the PRD.” : Shay Mandel

The skill I’d steal first is the one they built for the handoff, because it targets the most expensive round trip in the whole lifecycle:

“We know that usually we hand off to engineering and then there are a lot of reviews and questions and there is kind of a lot of feedback. We created a skill for that, so we call it PRD review by engineering. And this is a skill that goes and looks at everything and it makes sure that for every domain, the requirements actually answer the questions or the details that we need. And provides feedback for the PM and also suggestions on how to fix it.” : Shay Mandel

So it preempts the engineering review, in the hope that when engineering does look at it, there’s less rework. After that stage it goes to a real engineering review by a human, and they assume there are humans in the loop and they want them looking until the confidence is there. Then the same treatment on the far side: implementation plan, technical design, implementation, testing, review, all skills, all supposed to be automated, and all of them are. Each domain mapped and wrote its own context to make the reviews and the tech design more accurate and more efficient in their area.

The accountability change is the part that’s hard to copy, and it applies on both sides of the house.

“We have the people in the engineering, and also in products, they are not supposed to write anything on their own anymore. They just need to fix the skills or fix the context. So everything that is written will be written in a better quality.” : Shay Mandel

What I wanted to emphasise back to him is that this is a different instinct from the one most organizations land on. It’s clear that the model is not going to be perfect. But you’re trying not just to fix the model’s outputs, or even to avoid fixing the model’s outputs. You’re fixing the system instead: the inputs into the model, whether that’s the context or the skills. And then see that the model is able to create the right solution. Essentially everybody is developing this system that is the agentic development lifecycle.

Shay had already put that to his own people in a sharper way:

“We definitely talked with all the engineers and also with product and we explained to everyone, you need to change the state of mind. We need a new state of mind. We are now developers, not of the code, we are developers of the system.” : Shay Mandel

Asked how the engineers feel about it, his answer was unglamorous and probably the reason it’s working. It’s an evolution, and any time you adopt something new you see the same adoption curve: early adopters who jump on it, late adopters, and laggards. Most of them are now at the point of saying okay, I understand that I need to do this and I also understand the benefit. There’s still frustration when you write something you think is right and the quality of the result isn’t what you expected. Sometimes not enough detail, sometimes too much detail and too long to read. It takes time to tune. But it’s already saving them time.

I pushed on this, because “keep a human in the loop” stops meaning anything once agents write the artifacts. At the extreme, how to code something is a decision, and if I want humans making those decisions I’m back to humans reviewing all the code. There’s also the decision about what’s important: the feature, the architecture, the outcome we want, the leading indicators. The real question is the altitude.

“When you execute there are a lot of decisions to make, but we are trying to let the machine do this. But there are important kind of decision junctions that we still think there is a place for human judgment.” : Shay Mandel

Their junctions, in order: deciding the priorities and selecting the features. Reading and approving the PRD, even when most of the work creating it was automatic. Reviewing the technical design and the plan before coding starts. And a human before production, after the automated PR review has done its rounds.

“We are not the initial reviewer. We are the last reviewer.” : Shay Mandel

The goal is that the last reviewer has zero feedback. And when there is feedback, the fix goes back into the guidelines or the context, so that next time the work is done better the first time.

Why those junctions and not others is a domain answer, not a principle. Making a mistake in an insurance product can be very harmful, and it might take a long time to see the output. You introduce a new product and you start getting claims only after a year. Then you see if it’s too many claims or too little, and whether you should adjust something. A button position is not that: the agent creates both variants, runs the A/B test in production, and comes back saying this one is winning. Today they still review it and switch manually. Maybe in the future they push that automatically, because if it’s very clear that one solution is better than the other, then they let it go. They’re not there yet. They need to build their own confidence in the system first.

The part that goes furthest is what they call the loops.

“We are also having some teams that are starting what we call the loops, which is kind of the auto improvement loop. So we take a business problem and we say this is a problem that kind of repeats itself and we want it to be continuously improving. So it should go from monitoring what we have right now, deriving from that what’s the new feature, and then going through all the features. There are humans in the loop, but this is like a process that humans should mostly review, maybe tune, and push to the next step.” : Shay Mandel

Pointed at the funnel: improve the conversion, from start to quote or to purchase. Which is worth naming for what it is. You give it a KPI, you give it an area and you say improve this area. You don’t even give it features. You tell it to focus on outcomes, and you run a loop around a goal.

It works partly for a reason that has nothing to do with models:

“Not everyone can do it, but it’s based on the fact that we formalized everything there. So the questionnaire and all of that is very formal, and we moved it to be almost no code in most of the areas, so it’s fairly easy to change.” : Shay Mandel

And what comes back is a mix. It has a lot of ideas, some of them unrelated. It doesn’t have all of the experience their subject matter experts have. Some changes in an insurance product need to be filed and approved by the state department of insurance, so they aren’t easy to just make. And then the one that tells you what’s really going on:

“In some cases it can tell you, all the competitors are doing X, you should do it the same. And we say, okay, but we are digital and they are not, and we don’t want to be the same.” : Shay Mandel

That isn’t a model failure, it’s an information failure. Matching the competition is a reasonable default; the only thing making it wrong at Next is a strategic position that lives in people’s heads. So they can get a lot of recommendations for features, but they still need the human eye to look and make the right decisions. The repair is to write the missing thing down:

“When we understand, okay, if we just knew this, then we add it to the context. And we say, okay, this is our strategy and it’s going against our strategy. Okay, let’s articulate this in the strategy MD file.” : Shay Mandel

His framing for the agent writing a PRD is a junior PM: whatever training he’d give a human PM, understanding what’s the company and what are the goals, gets written into a context file or a background file, and they have multiple files of that nature.

A junior PM is probably not going to be an insurance expert. So I asked whether he’d tried going the other way: if you think about the most senior insurance expert that you have on staff, have you tried systemizing their knowledge, making a digital twin for them that’s available for the agents? And a similar idea: take the ideas from the world’s best growth hackers, the best books and resources on growth hacking, and bring them into what a growth agent knows.

“The state of mind is that everyone should improve the brain that we have in the company. So the best insurance experts, they are helping us write this brain. And we are also looking at asking Claude like, how would you solve this, and let’s build this into the brain.” : Shay Mandel

What they did next is the part I’d copy directly. They created these agents that enable you to ask different functions in the company. So you can have ask insurance expert, and ask engineer.

“If I’m a product manager and I want to do a new feature, but I’m not sure what types of different statuses we have in the system for this user behavior, I can just say I want to ask engineering. What are these statuses? And it will look in the code and everything and all the context that we have and will bring me back the answer. So instead of me talking with an engineer face to face, which is a big problem in our company because we are in very different time zones.” : Shay Mandel

It runs the other way too. An engineer sees a PRD that has been through all the reviews, goes to implement, and still has a question. What will the PM do here? If the PM sat at the next table in the same time zone you’d just ask. Since that’s not the case, he asks the bot, and gets back how that PM usually makes decisions and the specific guidelines. And when I asked whether the agents themselves get that access:

“Yes, of course. It all sits on top of the same brain.” : Shay Mandel

Less than you’d expect. They still run quarterly planning, sprint planning, roadmaps and a quarterly feature list. Jira holds the tasks. An implementation plan eventually creates tickets. Agents working asynchronously in the background write back as comments: this is what I’m planning to do, this is what I’ve done, this is how I reviewed it. That gives both people and other agents somewhere to read the state from.

What did change is capacity, in two directions. One is doing more of the same, faster. The other is less obvious:

“Instead of doing okay, that’s the MVP, that’s phase one, let’s make it as simple as possible, we can in some cases say, okay, we can dream bigger. Maybe the phase one is a bit bigger, or it’s a bigger change. It’s something that is more bold that we can move forward.” : Shay Mandel

Asked what dashboard he looks at, the honest answer was that they’re still working it out. They look at epic-level completion today and are thinking about how to visualise everything in flight once much more is going on. My suggestion was an epic-level Kanban board with statuses that reflect the touch points between agents and humans. The agent finished the PRD and it’s now waiting for human review is a distinct state change, and those handoffs are exactly what you want visible. The flow metrics fall out of that: how long each step takes, and how much of the time work is just waiting.

Set expectations first, before the demo does it for you.

“From idea to POC, like always, it’s very quick. From idea to production level, write this in a way that will pass all the reviews and so on, takes time. We talk about it kind of as grades, so we say the initial version will probably be sixty percent accurate or seventy. And we’ll probably get to ninety percent or ninety-five. And the extra five percent is why we need a human in the loop.” : Shay Mandel

Then decide where the material lives before you train anyone. They chose a repo over a wiki, so they get version control and everything in one place, and people can contribute and review. GitHub gives them a lot of mechanism for that. Then train, and let the people who want to run with it run, because they’ll find the problems and contribute back. A weekly meeting collects the learnings and cross-pollinates them across the organization.

Two failure modes he named. The first is that your harness has users who are not you:

“For product managers and insurance experts, they live in a different place. When you tell them open a terminal and just write these commands, you lost them.” : Shay Mandel

Engineers can do admin or root on their machines and the others can’t, and that makes sense. So the skills have to work for everyone, and the getting-started guides have to come in versions for different audiences. This is a pattern I keep seeing elsewhere. The harness gets created by engineering, very engineering oriented in what it focuses on and how it’s structured. Then you give it to anybody who isn’t an engineer, and people don’t really know what to do with it. They don’t even understand what the benefit is. You need to think from a product perspective even about your AI harness, the same way you would about any AI context you build.

The second is skill sprawl:

“Some companies, they have a lot of skills because everyone builds its own skill. They don’t use the generic skill, and then when you look at the statistics, every skill is used by maybe one or two users. And then a lot of what you build and all these brains, they are not really utilized.” : Shay Mandel

Next’s counter is an AI enablement squad that builds the infrastructure, the guidelines and the methodologies. One of its people is embedded in the business squads, to make sure what gets built is what those squads need and that they can contribute back. A forward deployed engineer. And the funding decision underneath it:

“Part of their definition of work for this squad is not to deliver the feature, it’s to build a system that can deliver more features in the future. They also shifted some of their OKRs with

approval of management, that it’s okay that the first quarter will be slower because we understand it will accelerate the next quarters.” : Shay Mandel

The machine also has to be extendable by other teams and usable by other squads, because if every squad and every engineer has their own way of working it won’t be productive and it’ll be very hard to maintain.

I closed by asking about the rest of the business, and what AI-first means beyond product and engineering. His answer inverted the usual assumption:

“We already implemented this in the support and the claims and the customer facing, we did this already about a year ago, and we continue to improve. We have product managers that we deploy there and a team that supports these different teams, and they are applying the engineering mindset.” : Shay Mandel

So product and engineering is actually behind some of the rest of the organization when it comes to going agentic. Which is worth sitting with if you assumed, as most technology leaders do, that engineering leads this and the rest of the company follows.

The way I’d generalise it: we look at product and engineering like a factory, like a pipeline. There is a value stream, a flow, a set of stages. You create a skill for each stage, and you work on optimizing the system. The question is what other factory lines are material to your business. Claims processing, closing the books each month, whatever it is. Then apply the same concept there. The mindset you need, that engineering mindset of constantly tuning the process, is somewhat more difficult to find in other business processes. So applying AI outside of engineering means bringing an engineering mindset to the rest of the organization, whether by applying engineering capacity to it or by building that mindset where it doesn’t exist yet.

Shay Mandel leads product and AI enablement at Next Insurance. He’s on LinkedIn at linkedin.com/in/shaymandel, and he runs the Product Leaders AI meetup, which is Bay Area local and also on Zoom.

The full episode: Developers of the System, Not the Code: Inside Next Insurance’s Agentic DLC, also on Spotify.

If you want my own argument about the sequencing underneath all of this, why changing who writes the artifacts before you change your process is the move, and how you know when the process change is finally due, that’s the companion piece.