Beyond the Prompt

Most companies are here. They have bought access to a frontier model. They are having conversations with it. Results vary significantly based on how questions are phrased, which engineer wrote the prompt, how much context was included, and which direction the wind is blowing. This is the "prompt-craft lottery" phase: some inputs produce excellent results, similar inputs produce poor ones, and the team has no systematic explanation for the difference.

Teams at L1 are constantly surprised by inconsistency. The same prompt produces different outputs across sessions. Output quality correlates with individual skill at phrasing rather than with any reproducible system. The mental model at L1 is that the model is a conversational partner: you talk to it and it responds. The better you are at conversation, the better the results. This mental model is not wrong -- it is just insufficient for anything that needs to be reliable, repeatable, and maintainable at production scale.

L1 is adequate for personal productivity tasks where quality variance is acceptable and every use is one-off. It is not adequate for anything that runs repeatedly, touches external systems, or produces outputs that downstream processes depend on.

The L1-to-L2 transition is conceptual. It requires adopting a specific mental shift: the conversation with the model is the input to the work, not the work itself. Before invoking an agent, you write a structured specification -- clear task definition, explicit constraints, defined output format, success criteria. The specification is the work. The agent invocation is execution against a spec.

Teams at L2 see immediate quality improvements because they are giving the agent deterministic instructions rather than conversational hope. The output variance drops dramatically when the input is a structured specification rather than an open-ended request. Engineers who make this transition often describe it as "obvious in retrospect" -- the model is better at executing clear instructions than at inferring what you want from conversational fragments.

L2 is achievable by most teams within weeks of deciding to try. It does not require new tools, new infrastructure, or new team members. It requires a decision to invest 20 minutes in writing a proper specification before invoking the agent instead of iterating conversationally after the fact. Most teams that make this transition report that L1 starts to feel visibly wasteful -- the time spent in conversational iteration was always greater than the time spent on upfront specification.

L3 is where most teams plateau. The technical step is straightforward: encoding expertise into reusable, versioned, composable units rather than one-off prompt chains that live in a single engineer's head or a shared Notion document that nobody trusts. Skills are the difference between "ask Sarah how to write the prompt for this" and "here is the versioned, tested, documented skill for this task." One scales. The other does not.

The blocker at L3 is not technical. It is organizational. Building a skill library requires the team to agree on standards: what belongs in a skill, how skills are documented, how they are tested, how they are versioned, who can modify them and under what review process. That is a cultural shift. It requires someone to own skill quality -- not a committee, because committees diffuse accountability, but one person whose job it is to maintain the library's reliability and coverage.

Teams that plateau at L3 are typically stuck because they started building skills without the organizational infrastructure to maintain them. Skills get created, used once, and never updated when the underlying task changes. The library grows but becomes untrustworthy. Engineers stop using it. The pattern reverts to ad-hoc prompting. The fix is not technical: it is assigning a DRI, establishing a review process, and treating the skill library as a product with users and owners rather than a documentation project that nobody is responsible for.

At L4, agents are deployed, monitored, and maintained like any other production service. They have owners. They have on-call rotations. They have defined SLAs. Failure modes are documented before they are discovered in production. Rollback procedures exist and have been tested. This sounds like table stakes for any software system -- because it is. The surprising thing is how few AI deployments reach it.

The L3-to-L4 transition requires treating agents as infrastructure rather than features. A feature is owned by the team that built it. Infrastructure is owned by the organization. That shift changes how it is funded, how it is maintained, how failures are handled, and how improvements are prioritized. Features get deprecated. Infrastructure gets upgraded. The teams that succeed at L4 made this distinction explicitly, early -- usually after their first significant production incident, which forced the question of who owned the broken system and what the remediation process was.

L4 also requires standardizing the observability and monitoring that makes infrastructure manageable. Which metrics matter for agent quality? What constitutes a degraded state versus a normal variance? What are the alerting thresholds? These questions have to be answered before the incident, not during it. Teams at L4 have answered them. Teams below L4 typically discover the questions exist when they are already in an incident.

A single context window is finite. A fleet of specialized agents is effectively infinite. L5 teams have decomposed complex tasks into parallel workstreams, built specialized agents that handle specific domains, and implemented a coordinating layer that assembles results into coherent outputs. The velocity improvement at L5 compared to L1 is significant -- tasks that took hours at L1 complete in minutes at L5, not primarily because the models are faster but because parallelism eliminates the sequential bottleneck of a single context window handling everything.

L5 requires both technical and organizational infrastructure that L4 builds. Without versioned skills (L3), parallel agent fleets cannot coordinate reliably -- each agent makes different decisions in equivalent situations. Without production-grade monitoring (L4), orchestration failures are opaque and hard to diagnose. L5 is not a shortcut to skip the earlier levels. It is the natural destination for teams that have worked through them.

The engineering pattern at L5 is decomposition: identifying which parts of a complex task are independent (can run in parallel), which are sequential (must wait for upstream outputs), and which require coordination (must reconcile conflicting outputs from multiple agents). That decomposition is domain-specific. It cannot be templated across industries. The teams that do it well have developed deep familiarity with both the task domain and the failure modes of agentic systems -- which only comes from time at L3 and L4.

L6 is the rarest maturity level. Every agent output is evaluated against a defined quality benchmark before it reaches the downstream consumer or triggers a downstream action. This is not periodic sampling. It is systematic: every output, every time, evaluated against criteria that were defined precisely enough to be benchmarkable.

L6 is rare not because it is technically hard but because it requires something culturally difficult: treating agentic engineering as a discipline with standards. Standards require defining what "correct" means precisely enough that a benchmark can evaluate it. Most teams have not done this work because it is uncomfortable -- it forces explicit answers to questions like "what does good actually look like, and how would we know if we were not getting it?" These questions are harder to answer than they sound, especially for novel tasks where human judgment has been the de facto quality standard.

The teams that reach L6 typically arrive there after a production failure that made the absence of systematic validation very expensive. The failure reveals that they had implicit quality standards they had never made explicit, and that the implicit standards were not reliably enforced. L6 is the response to that recognition. The goal is to make quality enforcement explicit, automated, and non-negotiable -- not as a constraint on velocity, but as the infrastructure that makes sustainable velocity possible.