Where to invest: a maturity model for your team

SAMI
July 10, 2026 4 mins to read
Share

A 5-part series — Part 5/5

The most common mistake isn’t picking the wrong discipline. It’s investing in a layer above where your team actually sits. People want to build a sophisticated harness when they don’t even have a test bench for their prompts. They stack autonomous agents on foundations that are taking on water.

After four parts of definitions, here’s the part that’s useful at work: placing your team, and deciding what to strengthen first.

Four levels of maturity

Level 1, prompts by hand. The team uses a chat or a code assistant, without structure. Everyone tinkers with their own prompts, nobody tests anything systematically, and quality depends on the inspiration of the moment. That’s where almost everyone starts. It’s not shameful, it’s just the beginning.

Level 2, context under control. The team has set up document retrieval, it manages the window, it runs one or two agents in production. That’s real engineering work. It’s also where most teams that describe themselves as advanced actually are.

Level 3, harness owned. Orchestration is real. Tools are clean, state persists across sessions, verification runs, and above all failures are treated as system bugs to fix, not as bad luck. The model has become swappable.

Level 4, the harness that improves itself. The infrastructure observes itself and evolves. That’s the subject of the most recent research on self-evolving agents. Few teams are there, and it isn’t a short-term goal for most.

The number that resets your expectations

Before you rate yourself, a guardrail. ServiceNow’s enterprise AI maturity index measured a drop in scores year over year, with fewer than one percent of organizations above 50 out of 100. And field assessments show a systematic bias: teams overestimate their level by one or two notches, because they judge themselves on their best use case rather than their real average.

Direct translation: you’re probably one level below where you think. A team with a production agent and good context engineering is doing real work. It’s still a level 2 team.

How to move up a level

The good news is that the progression is concrete, not mystical.

If you’re at level 1, don’t build an agent. Build a test bench. Take your twenty most frequent cases, write the expected result, and measure your prompts against it. Then standardize the prompts that work in a shared place. And spread the three-layer vocabulary across the team, because you can’t fix a problem you can’t name.

If you’re at level 2, instrument your context. Measure how many tokens go into tool results, into history, into documents. Move from retrieval that loads everything to targeted retrieval, at the right moment. Hunt context rot before it bites.

If you’re at level 3, systematize verification and make the model genuinely swappable. Every production incident should end as a fix to the harness, not a one-off patch.

The rule that ties it together

One rule sits over all of it, and it comes from Anthropic: start simple, add complexity only when it delivers measurable value. Most costly failures come from doing the opposite. People build a harness to escape a prompt problem. They stack agents to mask a badly managed context. Misplaced complexity doesn’t fix the weakness underneath, it hides it.

The real deliverable of this series

It wasn’t to turn you into a harness expert in five parts. It was to give you three words that change how you look at a problem.

Next time your LLM system goes off the rails, don’t ask “what better prompt should I write.” Ask the question in three beats. Is it the phrasing? That’s the prompt. Is it the information available? That’s the context. Is it the system orchestrating all of it over time? That’s the harness.

Naming the layer is already half the repair. The rest is engineering, and you know how to do that.

Practical resources

Leave a comment

Your email address will not be published. Required fields are marked *