The future of engineering: Agentic engineering 2.0

Most engineering teams that say they are running AI agents are really running something simpler. They have wired a few model calls into a fixed pipeline, given each call a narrow job, and called the result autonomy. There is nothing wrong with that. It works, and it is doing real work in production today. It is just worth being clear about what it is, because it is only the first step.

Agentic engineering, the practice of putting AI agents to work inside real engineering workflows, is splitting into two generations. The difference between them is not a detail. It decides which teams reach the future of engineering and which ones stall along the way. The first generation, the one almost everyone is building right now, is deterministic. You design the path and the agents walk it. The second generation works the other way around. You hand the agent a goal and let it find the path on its own. That second model is where AI first engineering is headed, and the foundation you put down during the first generation is what makes the move to the second one possible.

This piece walks through both generations. We use a single incident as the running example so the contrast stays concrete, though the same shape applies just as well to code review, a release gate, or a dependency migration. By the end you should have a clear picture of where you are today, where this is going, and what to build now so that you are not rebuilding later.

What is agentic engineering 1.0?

Agentic engineering 1.0 is ai agentic development with the path wired in advance. You start with a job, something like incident response, code review, or a release gate, and you break it into stages. Each stage gets its own agent with a narrow scope, a fixed prompt, and a defined hand-off to the stage after it. What you end up with is a deterministic workflow, a directed graph where the agents are the nodes and you, the engineer, drew the edges.

The agents reason inside their own box, but the workflow around them does not. If a situation shows up in a shape the graph did not anticipate, it falls through to a human. That predictability is the point of 1.0, and it is also its ceiling.

A self-healing incident workflow, the 1.0 way

Take a service that starts throwing a p99 latency breach at two in the morning. A deterministic 1.0 pipeline runs the incident in stages, and each stage has a single, fixed job.

1. Triage agent. Its job is to decide whether the alert is real and how serious it is. It reads the alert, pulls the last few deploys and the relevant dashboards, classifies severity, and routes the incident onward. Triage is all it does.
2. Diagnosis agent. Its job is to produce a ranked list of probable causes. It reads logs, traces, and recent commits, lines the spike up against the deploy timeline, and returns a set of candidates without acting on any of them.
3. Remediation planner. Its job is to match the top cause to a known runbook action, whether that is a rollback, scaling out, flipping a feature flag, or restarting a pod. It chooses from a fixed menu of fixes that someone wrote ahead of time.
4. Execution agent. Its job is to apply the fix that was chosen, running the action against the deploy system or the infrastructure. Anything destructive usually waits behind a human approval gate.
5. Verification agent. Its job is to confirm recovery. It checks whether the metrics have returned to baseline, then either closes the loop or escalates to on-call.
6. Comms agent. Its job is to document what happened. It updates the incident channel and drafts the postmortem from the trail the other agents left behind.

Every one of these stages is real and useful. The thing worth noticing is where the thinking happens, which is with you. You decided there would be exactly these six stages, in this order, with these hand-offs between them. The agents fill in the work inside the boxes you drew. So when the real cause turns out to be a bad config in a dependency three hops upstream that no runbook covers, the pipeline has no way to improvise. It routes to a human, because improvising was never part of the graph.

What is agentic engineering 2.0?

Agentic engineering 2.0 takes the model behind today's fully autonomous agents and points it at engineering work. You stop wiring the path and start handing over the goal. Instead of designing a six-stage graph, you give the agent an outcome, such as restoring a service to health without breaking anything else, and you give it the three things it needs to get there on its own. The first is context: what the service is, what depends on it, who owns it, what its SLOs are, and what changed recently. The second is tools: observability, the deploy system, the codebase, the runbooks. The third is guardrails: what it is allowed to touch, how large its blast radius can be, and where it has to stop and ask.

The orchestration logic moves out of the pipeline and into the agent's own reasoning. This is already how the best autonomous coding agents work. Claude Code, for example, reads the context, plans an approach, runs its tool calls, checks its own output, and keeps iterating until the result meets the criteria you set. There is no fixed graph behind it, just a goal and a loop. AI-driven development in 2.0 looks the same, applied across the whole SDLC.

The same incident, the 2.0 way

Picture the same two in the morning latency breach, but without the six node graph. This time there is one autonomous agent, or a small set of them, holding the goal and the context.

The agent starts by diagnosing, much as the 1.0 diagnosis stage would. From there it follows the evidence wherever it goes. It finds that the spike does not match any runbook, traces it to a config change in an upstream dependency three services away, and decides on its own to do two things at once. It rolls the current service back to buy some headroom, and at the same time it writes a fix for the actual config and opens a pull request for review. Then it confirms that recovery held, keeps an eye on the neighboring services it knows depend on this one, and writes the postmortem from what it actually did rather than from a template.

At some point it reaches the edge of its authority. Say the change it wants to make would cross the blast radius limit you set. When that happens it stops and asks. Notice that it does not stop because the situation confused it. It stops because a boundary told it to. The novelty was handled on its own, and only the question of authority brought a human back in.

Nobody drew this path. The engineer set the goal, supplied the context, connected the tools, and defined the boundaries, and then reviewed the agent's judgment after the fact. The same approach would carry a code review, a release, or a migration just as readily as it carried this incident.

This shift already has a name: loop engineering

None of this is a forecast. Engineers are already working this way, and in June 2026 the approach got a name. Loop engineering is the practice of building the system that prompts your agent, rather than prompting it yourself by hand. You define the goal, and a loop runs the agent through cycles of acting, observing, and adjusting until the work is finished or it hits something it cannot get past. The term was popularized by Addy Osmani, an engineering lead at Google Chrome, and the post that started the conversation reached millions of views within days, which tells you how ready the field was for it.

The people building these agents describe the same change in their own words. Boris Cherny, who created Claude Code at Anthropic, put it simply: "I don't prompt Claude anymore. I have loops that are running." The loops decide what to do next. Peter Steinberger describes the new job as designing the loops that prompt your agents instead of typing each prompt yourself. Osmani connects the idea straight back to everything in the sections above, placing loop engineering one level above the harness, where the loop runs on top of the foundation rather than in place of it.

That is the engineer's role in 2.0, described by the people who are furthest into it. You stop being the hand on each prompt and become the person who designs the system that does the prompting. It is worth being honest about the pace, though. Most teams are not running autonomous loops yet, and for a lot of work an interactive session with a good agent is still faster and safer than building a full loop. That gap is exactly the point. Loop engineering is where the field is going, and the foundation you put down now is what lets you meet it when you get there.

Agentic engineering 1.0 vs 2.0

The two generations are not competing products. 1.0 is what you run today, and 2.0 is what you grow into. Where they differ is in three areas that shape how you build, staff, and govern them.

Where each one wins and where it costs you

Agentic engineering 1.0

• Speed: Each run is fast and predictable, with latency you can reason about. The cost shows up over time, because every new scenario needs a new branch that you build by hand, so the long tail of cases never quite gets covered.
• Control: High. You know exactly what runs, in what order, and on what inputs. The system is easy to reason about because you designed every edge of it.
• Governance: Straightforward. Every step is auditable, permissions map cleanly onto each node, and the behavior of the whole thing is bounded by the graph you drew.

Agentic engineering 2.0

• Speed: It handles situations you never pre-built a branch for, which is how it covers the long tail that 1.0 leaves behind. The trade is that any single run is less predictable, since the agent is choosing the path as it goes.
• Control: Lower at the level of individual steps, and that is by design, because you are no longer deciding the route in advance. Control moves up a level, from which steps run to what outcome you want and what boundaries you set.
• Governance: Harder, and a great deal more important. There is no fixed graph to audit, so you govern through identity, policy, blast radius limits, and traceability after the fact. This is what makes or breaks 2.0. The wider the agent's loop runs, the more weight the guardrails have to carry. Anthropic's own engineering write-ups land on the same point: once you describe an outcome instead of reviewing each change, governance gets harder, not easier.

What to build today to be ready for the future of engineering

Here is the part many teams get backwards. The move to 2.0 is not a model upgrade you sit and wait for. It is a foundation you build, and you build it while you are still running 1.0.

An autonomous agent is only as good as the context, tools, and guardrails you give it. Take the harness away and even the strongest model is mostly guessing. The useful consequence is that the work which makes 2.0 possible is the same work that makes your 1.0 workflows better today, so none of it is wasted effort. This is where a control plane for agentic engineering pays for itself, and it is what Port is built to be.

• A context lake: one place where agents can read the real state of your engineering organization, including every service, its owners, its dependencies, its SLOs, and what changed in the last hour. In 1.0 your diagnosis agent queries it. In 2.0 your autonomous agent reasons over it.
• An agent registry: a record of which agents exist, what each one is for, and what it is allowed to do. You cannot govern agents you cannot see.
• A skills registry: reusable, versioned capabilities that agents call instead of working them out from scratch. The skills your pipeline invokes today are the same ones an autonomous agent will compose tomorrow.
• An MCP hub: a single governed gateway to your tools, so every agent connects through one auditable surface rather than a sprawl of point to point integrations.
• Governance: identity, permissions, and policy that bound an agent's blast radius. This is the layer that turns "the agent chose its own path" from a risk into something you can control.

Build this harness now and your deterministic 1.0 workflows run on top of it. Build it now and your autonomous 2.0 agents run on the same foundation, with nothing to migrate. This is also where loop engineering comes back in. The loops your engineers will design sit one level up, and they run on the harness you build here rather than replacing it. Teams that treat their 1.0 work as throwaway scripting will end up rebuilding from scratch. Teams that treat it as laying a foundation will walk into 2.0 already standing on the harness their loops need.

When do we get full AI-first engineering?

The signals are already in the tools. Look at what is shipping in autonomous coding right now. There are agents that run a full loop of observing, thinking, and acting with no human between the steps. There are subagents that spawn with their own context windows and tools so they can work in parallel. There are background sessions that keep coding after you close your laptop, and skill systems where the output of one agent becomes the input to the next. None of that is a wired graph. All of it is goal-directed work with a harness underneath, which is to say 2.0 mechanics, available today and scoped to the codebase.

What is holding back the broader shift is not the capability of the models. It is the foundation around them. That is exactly why agentic engineering platforms are being adopted so quickly for 1.0 work. Teams need the context, the registries, the tool gateway, and the governance simply to run deterministic pipelines safely. Those same platforms are the substrate that 2.0 will run on, so the adoption happening for a near-term reason is quietly building the long-term one at the same time.

Our own read is that 2027 is the year ai driven development goes non-deterministic at any real scale. Not because the models suddenly cross some line, but because enough teams will have built the harness, and earned enough trust in their agents, to stop micromanaging them through fixed workflows and start handing them goals instead. At that point the engineer's role finishes the shift it has already started, moving from drawing the graph to setting the outcome and checking the result. That is what AI first engineering really means, and it is closer than the deterministic pipelines on your screen today would suggest.

The teams that get there first will not be the ones with the best models, since everyone has access to the same models. They will be the teams that spent 2026 building the foundation those agents can stand on.

Book a demo and we will walk through what your 2.0 foundation would look like.