Agentic Engineering: The Full Technical Guide (Principles, the Loop, and the Math)

There is a name now for the thing the best builders actually do, and it is not prompting and it is not coding. It is agentic engineering: designing systems where AI agents plan, act, test, and ship under structured human oversight. The one-line version from practitioners is blunt. You are not writing the code 99% of the time. You are orchestrating agents that do, and acting as oversight. Agentic, because the work is now autonomous. Engineering, because doing it well is a real discipline with real rules.

Most people are still stuck one layer down, tuning prompts, and wondering why their agent works in a demo and collapses on a real task. This guide is the layer up: the principles, the core loop, and the math that tells you, before you build anything, whether your agent will hold together or fall apart.

Where agentic engineering sits

Three layers, each containing the last.

Prompt engineering is one message: what do I say to the model. Context engineering is one window: what should the model see at this step. Agentic engineering is the whole system: how do agents plan, use tools, verify, recover, and ship a finished result with a human at the right gates. Loops, graphs, sub-agents, memory: those are all tools inside this discipline. Agentic engineering is the discipline that decides how to wire them together and when to trust the result.

Three principles you engineer around

A frontier model is not uniformly smart. It is brilliant in one direction and brittle in another, sometimes inside the same task. Its capability map is jagged. You do not fix this with a better prompt. You engineer around it: route each subtask to where the model (or the tool, or the specific model) is strong, and fence the parts where it is weak.

Karpathy's framing: an LLM is not a person. It is a statistical simulation of reasoning, with no motivation, no fatigue, and no continuous self. So stop pep-talking it and stop assuming it "understands" like a colleague. Design for a ghost: explicit instructions, no reliance on it "remembering" or "caring", and a system that assumes it will confidently do the wrong thing some fraction of the time.

You are not in the loop on every step, and you are not out of it either. You place yourself at the specific gates where the cost of a mistake is high, and you let the rest run. The whole art is choosing those gates well. The math below tells you where they go.

The core loop of the discipline

Every agentic system, stripped down, runs the same five stages.

Spec  ->  Plan  ->  Execute  ->  Verify  ->  Ship
                (subagents)   (separate reviewer)

Spec: a crisp, written definition of done. Plan: the agent proposes an approach and you approve it at a gate before any work happens. Execute: specialized sub-agents do the work, each in its own context with its own tools and permissions. Verify: a separate reviewer agent, not the one that did the work, checks the output against the spec. Ship: the result goes out, with a human gate on anything irreversible. The loop repeats on whatever fails verification.

The math: will your agent actually hold together

This is the part almost nobody runs, and it is the part that predicts success. Five formulas.

An agent that takes n steps, each correct with probability p, succeeds end to end only if every step is correct:

P(task success) = p^n

This is brutal. A 95% reliable agent (p = 0.95) on a 20-step task:

0.95 ^ 20 = 0.36

It fails almost two times out of three, despite being "95% good". Reliability that looks fine per step decays exponentially over a long task. This one formula is the entire reason agentic engineering exists: naive chains do not scale, and the fix is not a smarter model.

Add a verifier that catches a bad step, and retry until it passes. If a step is retried up to k times, its effective reliability climbs:

p* = 1 - (1 - p)^k

Then the task succeeds with (p*)^n. Watch what it does. Take a shaky p = 0.9:

no verify:      0.90 ^ 20        = 0.12
verify + 3 tries: p* = 1 - 0.1^3 = 0.999
                  0.999 ^ 20      = 0.98

From a 12% success rate to 98%, same model, just by verifying each step and retrying the failures. This is why the verifier is the backbone of the discipline, not an add-on.

You cannot review every step, so review by expected damage. For each action, the expected loss is its chance of being wrong times what it costs if it is:

ExpectedLoss(action) = P(wrong) * cost(if wrong)

Gate any action where that number is high; automate the rest. A low-probability, catastrophic action (delete the production database) has huge expected loss even at tiny P, so it always gets a human gate. A high-probability but cheap-to-undo action (reword a paragraph) does not. This turns "how much should I supervise" from a vibe into a sort.

Because capability is jagged, the same task has a different p on different executors (models, tools, sub-agents). Route to the best one:

p_effective = max( p_executor_1, p_executor_2, ... )

Do not run everything through one model. Send code to the strong coder, retrieval to the tool that actually fetches, math to the executor that runs it. Effective reliability is the max of your options, so having options is itself an engineering decision.

The more you automate, the more an error runs unchecked. Keep a simple ceiling: an action runs autonomously only if

P(wrong) * cost(if wrong)  <  your risk threshold

Everything above the line is fenced behind a gate or a permission. This is how you let an agent run a thousand steps unattended without one of them being able to do real damage.

The architecture, in code

The discipline compiles down to something small.

def agentic_run(goal):
    spec  = write_spec(goal)                       # definition of done
    plan  = planner.propose(spec)
    approve_gate(plan)                             # human gate before work

    results = []
    for task in plan.tasks:
        exec = route(task)                         # jaggedness: pick best executor
        out  = retry_until(                        # verify + retry beats the exponent
            lambda: exec.run(task),
            check=lambda o: verifier.approve(o, spec),
            k=3)
        results.append(out)

    if high_blast_radius(plan):                    # blast radius gate
        approve_gate(results)
    return ship(merge(results))

Spec, a plan gate, routed execution, verify-and-retry per task, a blast-radius gate, then ship. Every formula above maps to one line here.

The 5 ways agentic systems quietly break

What to build this week

The takeaway

Agentic engineering is the discipline of getting real work out of a ghost: capability is jagged, so you route around it; per-step errors compound as p^n, so you verify and retry; and autonomy is bounded by blast radius, so you gate by expected loss. Do that, and a model that fails two thirds of long tasks starts finishing almost all of them.

The people who win the next few years are not the ones with access to a smarter model. Everyone has that. They are the ones who engineer the system around it, and who know the math well enough to trust it when they walk away.

If this helped, follow me. I break down AI systems and prediction markets every week, no fluff.