What is agentic engineering?
Agentic engineering is the discipline of getting useful, trustworthy work out of AI agents running with limited supervision. It has four parts: scoping the task so an agent can succeed at it, constructing the context it needs, supervising and recovering it while it runs, and reviewing what comes back. Only the second of those is what most people mean by prompting, and it is not the part that fails.
The distinction from ordinary software engineering is narrow but consequential. In ordinary engineering the worker is deterministic. Given the same input it does the same thing, and when it breaks it breaks loudly. An agent violates both properties. It can produce a different result on identical input, and it can fail in a way that produces no error at all: plausible output that happens to be wrong, or no output while remaining perfectly healthy from the outside.
Why the generation half stopped being interesting
There is a version of this topic that is entirely about model capability, and it dates quickly. Ours is not that. The useful observation is that the capability curve outran the operational practice, and the bottleneck moved. Once a model can competently produce a change to a codebase, the questions that decide whether you get value from it are almost all questions about the surrounding system.
The evidence that this is a real gap rather than a rhetorical one is that measured productivity has been stubbornly hard to demonstrate. A 2025 randomised controlled trial by METR gave experienced open-source developers AI tooling on their own repositories and found they took roughly 19% longer to complete tasks, while believing they had been faster. The interesting finding is not the slowdown, which is specific to that setting. It is the gap between measured and perceived performance, which is exactly the gap an operating discipline exists to close.
The four disciplines
1. Scoping, which is where the returns are
A badly scoped task cannot be rescued by better instructions. This is the single most reliable pattern we have: when an agent produces bad work repeatedly, the cause is almost never the wording, and rewording is almost never the fix. The fix is a smaller, better-bounded task with a checkable definition of done.
A well-scoped agent task has three properties. It fits in one context window with room to spare. It has a verification step the agent can run itself, so success is not a matter of opinion. And its blast radius is known in advance, meaning you can say what it is allowed to touch before it starts.
2. Context construction
Context is a budget, not a container. The failure mode is not running out of room; it is filling the room with material that dilutes the relevant part. In practice the highest-value habit is deleting from the context rather than adding to it, and the second is being explicit about what the agent must not do, because agents default to doing more than they were asked.
Long-running agents need a policy for what happens as the window fills. Ours compacts at 55% occupancy and recycles the session at 60%, which sounds aggressive and is: a session that runs to its limit degrades noticeably before it fails, and the degradation is subtle enough that you notice it in the output quality rather than in any metric.
3. Supervision and recovery
This is the part that separates a demo from an operation, and it is the least written-about. We run three layers deliberately designed not to overlap:
- A passive heartbeat. The agent emits a signal; absence of the signal is the alarm. Cheap, and catches hard crashes.
- A local supervisor with access to the process, its environment and its output buffer. It owns recovery, because it is the only layer with enough signal to distinguish a stuck agent from a busy one, and restarting a busy agent destroys real work.
- An external prober that periodically asks each agent to do something small and verifies it happened. This is the only layer that catches the failure where the process is healthy but the connection to the outside world has quietly died.
The third layer exists because of a specific class of bug we hit repeatedly: an agent whose supporting subprocess never started. The process tree looks fine, CPU is normal, logs are quiet, and every restart re-fails identically. Restarts do not fix it; reconnecting the subsystem does. We lost several hours to that shape before recognising it, and the lesson generalised: a recovery action that has not worked twice will not work the third time, and an escalation ladder needs a rung that does something different rather than the same thing harder.
4. Review
Review is where the non-determinism gets absorbed, and it is the piece teams try hardest to automate away. The specific danger is that agent output is fluent, and fluency reads as correctness to a tired reviewer. The countermeasure that has worked for us is adversarial: a second agent asked to refute a change rather than assess it, with the human reading the disagreement rather than the diff. It is not a replacement for human judgement. It is a way of pointing human judgement at the right forty lines.
The failure modes worth designing for
From operating a fleet of agents continuously, these are the ones that recur. None of them is a model problem, which is the point.
- Alive but silent. The agent is running and answering nothing. Only an end-to-end probe distinguishes this from deep work.
- Confidently wrong. Output is well-formed and incorrect. Cost scales with how much downstream work trusted it.
- Scope creep. Asked to fix one thing, the agent improves four adjacent things nobody reviewed. Bound this in the instruction, explicitly, every time.
- Context exhaustion. Quality degrades before anything errors. Manage the window; do not wait for it to complain.
- Concurrent collision. Two agents working the same repository will clobber each other. Worktrees or serialisation, not hope.
- Recovery that destroys work. The restart that fixes the outage also throws away an hour of correct reasoning. Recovery design is a first-class concern, not an afterthought.
What this means for how you staff
The role that this work actually needs is not "prompt engineer", a title whose half-life is nearly up. It is closer to an engineer with operational instincts who is comfortable deciding what a problem is before writing anything. The scoping skill and the supervision skill rarely live in the same person, and teams that accept that and pair them do better than teams hunting for a unicorn.
For the organisational version of this argument, including where the accountability sits, see our writing on AI team design and the chief AI officer role. For the security surface these systems create, see agentic AI security, and for the question of whether an agent is the right tool at all, when not to use AI agents.
Where to go next
This is the hub for the practice. The pages below go one level down into specific parts of it:
- Agentic coding: what changes in the day-to-day craft of writing software this way.
- AI coding agents: an honest comparison of the tools, and what the differences actually are.
- Autonomous coding agents: what "autonomous" costs once nobody is watching.
- Agentic workflows: the orchestration patterns, and when a workflow beats an agent.
- AI-native development: what it means to build this way from the start.
Two pieces of first-hand evidence rather than argument: our spec-driven development run, and the system-scale hallucination write-up. Both are reports of things that happened rather than positions we hold.