What Is Agentic Engineering, and Where Does It Break?

You built the agent. You ask it the thing it was built for, and it does the thing. There is a real pleasure in watching it go.

Then you ask again, worded slightly differently, and it does something else. Not wrong. Different. You ask a third time and get a third answer, and now you are sitting there deciding which of the three you would be willing to put in front of a customer.

That gap, between "it works when I try it" and "I can tell you it works", is what agentic engineering is actually about.

What agentic engineering actually means

Agentic engineering is building the machinery around a model instead of building the model. You are not training anything. You are deciding what the agent is allowed to touch, how many steps it gets before you stop it, what happens when a tool call fails, what it carries between turns, and how anyone reconstructs what it did after the fact.

The prompt is part of it, and it is the small part. Most working agents have a prompt somewhere around forty lines. The rest is retries, tool definitions, a step budget, permission boundaries, traces, and somewhere in there the thing that checks whether a confident answer was actually right. That is the engineering.

The name is new. The shape is not. Anyone who has put a non-deterministic component into production has done a version of this before, usually without a word for it. EleutherAI's lm-evaluation-harness has been doing the measurement half for language models since well before anyone said "agent".

Where agentic engineering breaks

Rarely at the model. Almost always in the same four places.

Nobody wrote down what correct means. You have a test suite and it passes. It was written by the same person who wrote the prompt, on the same afternoon, out of the same assumptions, so it agrees with the prompt about what a good answer looks like. It cannot see the thing you need to know, which is whether a stranger asking in their own words gets something usable.

The second reviewer. Show one agent output to two people on your team and ask each to score it out of five. If you get back a 4 and a 2, you do not have a measurement problem yet. You have a definition problem, and every number you produce before you fix it is decoration.

Cost, quietly. An agent that loops does not throw an error. It takes eleven tool calls to do a two-call job, and the only place that shows up is the bill, a month later.

The upgrade. The model underneath you changes. It is better on every public benchmark and different on your workload. Better and different are not the same thing, and nothing in your pipeline can tell them apart unless you built something that can.

The half nobody budgets for

Here is the honest limit, and you should hear it from me rather than find it in month three.

The building half of agentic engineering is the fast half. Wiring up tools, giving the agent a loop, getting it to do something impressive in a demo. That is a good week, and it feels like the whole job.

The half that decides whether the thing survives real users is the verification half. An evaluation set built from what people actually sent rather than what you imagined they would send. Rubrics precise enough that two readers land on the same score. A decision about where a code check is enough and where a human has to look. A passing bar chosen from what a failure costs you, not from a number that sounded respectable in a meeting.

That half takes longer, it is less fun, and almost nobody plans for it. It also has its own name now. It is called harness engineering, and if you have got as far as asking what agentic engineering is, it is probably the half you are about to need.

Start with the smallest possible version. Take twenty real requests, not invented ones. Before you run any of them, write down what a good answer to each would contain. Then run them. The distance between what you wrote down and what came back is the only honest measurement you have, and you can have it this afternoon.