You’ve been in this meeting.
The exec sponsor opens with: “We need to be doing agentic engineering by end of financial year.” Around the table, nine people nod. Three of them are picturing a software agent that files its own Jira tickets. Two are picturing their dev team using Claude Code to write tests faster. One is picturing the vendor demo they saw last week with an autonomous swarm closing PRs overnight. Three have no picture at all and are waiting for the next slide.
Everyone nods again. The meeting ends. The roadmap gets written. Six months later the board asks how it’s going, and nobody around that table can agree on what “it” was.
The costs when you can’t agree on what you mean
This is a semantic problem with a commercial downside!
When the word “agentic” carries different meaning to different people, the downstream damage stacks up fast:
Budgets get sized to the wrong level A multi-million-dollar investment case built around autonomous swarms lands in a delivery team whose day job is running a Claude Code chat in their IDE. The gap between the promise and the delivery becomes the story the board remembers.
Vendor pitches stop being evaluable Every vendor now says “agentic”. Without a shared ladder you can’t tell which of them is selling you a plan-execute-review CLI and which is selling you an event-driven system that replaces a team. You end up comparing prices on apples and orchards.
Governance requirements are different at every level, and nobody names which level they’re governing for A developer using an agentic CLI needs the same controls as any other engineer: code review, PR approval, branch protections, an existing SDLC. An autonomous event-driven agent operating without a human in the loop needs something entirely different: token-spend caps, tool-use policy, runtime guardrails, and audit trails your existing pipeline does not provide. If your team says “agentic” and the Head of Risk hears “Copilot autocomplete”, the controls that actually match the level never get built. The ones that do get built create approval fatigue without reducing the real risk.
Each of these is a specific enterprise-tech-team failure mode. You’ve likely seen at least two of them this year.
The six levels
The framework below is the one Terem uses internally and with clients. It is a synthesis of two pieces of work: Anthropic’s Building Effective Agents(2024) and OpenAI’s five levels of AGI (2024).
One nuance up front: this is not a strict maturity ladder. Some organisations reach Level 3 before Level 2. That’s fine. The point of the ladder is shared vocabulary.
Broadly, higher levels deliver more productivity impact, require bigger changes to your ways of working, and cost more to get to.
- Level 0: Conversational AI-Assisted. Chat-based AI with no file access. You paste code in and paste changes back (or Cursor in edit mode). Most organisations claiming to “use AI” are here.
- Level 1: Single-Agent Tool Use. A single agent inside an agentic CLI (Claude Code, Cursor (in agent mode), Windsurf) in a plan-execute-review loop; the developer triggers every run.
- Level 2: Orchestrated Multi-Step Workflows. A single agent across a structured pipeline with skills, hooks, and non-engineering roles in the loop. The first level that needs Risk in the room.
- Level 3: Parallel Multi-Agent Execution. Multiple agents running simultaneously via split-and-merge across git worktrees.
- Level 4: Headless / CI-Integrated Agents. Event-driven. Tickets, PRs, and failed tests trigger the agent; humans review at critical breakpoints.
- Level 5: Managed Long-Horizon Agents & Swarms. Goal-driven. Agents run for hours or days on one objective, handing off to one another. Still emergent in 2026.
Each of these deserves its own post, and each of them will get one. Deeper walk-throughs of the patterns, tooling, governance shifts, and Terem engagements at each level are on their way in the posts to follow.
What to do with the six levels on Monday
How can this help you immediately?
- Define where you are at each level. Your organisation isn’t at one level. Different teams, different products, different codebases, all sitting in different places on the ladder. Map each of them against the six levels, honestly. A team running Cursor in Edit Mode is at Level 0, however advanced the slide deck says they are.
- Define where you want to be at each level. Again, per team and per product. Pick targets that are one or two levels up from current state, with a realistic timeframe attached to each one (usually a 4 week focused effort is enough to uplift a level).
- Define the governance you need at each level. Governance requirements change at every step of the ladder. Level 0 needs the same controls as any engineer. Level 4 needs token caps, tool-use policy, runtime guardrails, and audit trails. Name what’s required at every level you’re operating at or moving toward, and name who owns it.
- Sort each software pitch you’ve received into one of the six levels. Every vendor now says “agentic”. Go back through your last six vendor briefings and place each one on the ladder. You will almost certainly find one was selling you Level 1 priced like Level 4, and another was doing the opposite.
The cost of not having a shared vocabulary is real: budgets sized for the wrong level, vendor pitches you can’t evaluate, governance built for the wrong risk.
The shared language doesn’t magically solve the rollout, but it does mean everyone’s solving the same problem.