'Agentic engineering' stopped being a LinkedIn word

A founder posts a screenshot of one Python function, one system prompt, and one API call to a calendar tool. The caption reads: agentic engineer. The same week, a different agent, built from the same four lines of glue code, reads a customer’s cancellation email as a reschedule request and rebooks the meeting four times before anyone notices. Both agents shipped. Only one of them survived contact with a real user.

If you went looking for an agentic engineering definition six months ago, you got the LinkedIn caption. Now you get a workshop.

Agentic engineering is the systems-level discipline of running many agents reliably in production: verification, guardrails, observability. It’s the layer that turns a company’s system of record into a system of action.

This post defends a narrow claim: the gap between the LinkedIn version of agentic engineering and the real one is not vibes, it is three specific engineering disciplines applied to every agent that touches production, and the field just got institutional proof that people who study software systems for a living, not just people who sell it, take the distinction seriously.

An agentic engineering definition, courtesy of ICSE

The naive read treats “agentic engineer” as a title you award yourself the day you connect a model to a tool. Nothing checks the claim, so the word means whatever the poster wants it to mean, and it fails exactly there: a title with no external check is not a discipline, it is a costume.

Here is the fact that changes the argument. ICSE, the International Conference on Software Engineering, is co-locating the International Workshop on Agentic Engineering, AGENT 2026, on April 14, 2026, in Rio de Janeiro. Its published topic list is not marketing copy, it is a research agenda: architectural design for agentic systems, verification and validation and testing of agentic systems, AgentOps as the DevOps of agents, evaluation methodologies and benchmarks, and responsible-AI risk assessment. That is a peer-reviewed venue, not a caption, and it names the same three qualities this post keeps coming back to, verification, guardrails under responsible-AI risk, observability under AgentOps, as the actual research problem. A conference does not co-locate a workshop track around a hashtag; it co-locates one around a discipline with open problems worth a paper.

The moment a peer-reviewed venue builds a verification track around a word, the word has left marketing and entered engineering.

Verification: the difference between claiming done and being done

The naive version of verification is the agent reporting its own status. It finishes a task, states that it finished, and the pipeline moves on. That fails for a structural reason, not a bad-luck one: a system grading its own output has no adversarial pressure on it, so it converges toward whatever clears its own bar, not the user’s. That is the exact mechanism behind pilots that demo cleanly and then die in production, a pattern this pillar has already traced in why your AI pilot failed and in most AI pilots die in production: the failure was never visible to the system doing its own grading, only to the real user who hit the path the demo never covered.

Agentic engineering’s answer is mechanical, not philosophical: verification only counts when the thing doing the grading is not the thing being graded. That can be a deterministic test the agent cannot negotiate with, a second agent scoring against a rubric it did not write, or a human clicking through the real surface. Recent formal work on agent contracts, arXiv 2601.08815, points the same distrust at a narrower target, an agent’s resource consumption: it specifies input/output boundaries, time budgets, and success criteria for a delegated agent up front, then enforces conservation laws so a sub-agent can never spend past its parent contract’s budget, a design that held zero conservation-law violations across multi-agent delegation in the paper’s own evaluation. A contract has to be checkable by something other than the agent bound by it, whether what’s checked is the answer or the spend.

Apollo runs that distrust as three connected layers, not a hope. An org’s tasks, docs, CRM records, and agent definitions live in one system of record every agent and teammate reads and writes, so the row holding a task’s acceptance criteria is the row an agent’s output has to land in. A system of intelligence sits on top: a second, independent agent loop scores the first agent’s output against those stored criteria, never against criteria it wrote itself, and Apollo’s task pipeline is built so status can only flip from in-progress to done once that separate loop clears it. That flip writes back into the same record every downstream agent and human reads next, which is what turns a verification layer into a system of action: the verdict becomes the next trigger, not a side note. Software has always distrusted a component that grades itself; agentic engineering is that distrust applied to agents instead of unit tests, and record-intelligence-action is what happens when the applying gets built into the runtime instead of argued about in a doc.

Verification only counts when the system doing the grading is not the system being graded.

Guardrails are a boundary condition, not a content filter

The naive version of a guardrail is a prompt-injection blocklist bolted onto the first turn a user types. It fails because a multi-step agent does not stop after the first turn: it calls tools, writes to memory, and often hands off to a second agent several hops later. A blocklist scoped to turn one says nothing about turn six, so the unsafe action happens downstream of the only place anyone was watching, and by the time it surfaces, the trigger looks nothing like the input the filter was built to catch.

The fix is to treat a guardrail as a boundary condition enforced at every hop: every tool call checked against what that tool may do, every memory write checked against what may persist, every hand-off checked against what the receiving agent may act on. Guardrails and observability are the same discipline pointed in two directions, one constrains what comes next, the other records what happened. Neither alone catches a failure that happens between two tool calls nobody was individually watching.

Observability for a swarm, not a single request

The naive version of observability is a request-and-response logger pointed at the agent. It fails for a specific reason: a single trace tied to one HTTP call cannot reconstruct a plan that spawned six tool calls, two retries, and a hand-off to a second agent. The log shows a clean 200 while the decision that produced a wrong customer-facing answer sits four calls deep, unrecorded, exactly the gap observability for agents is a different sport already names as the core failure of applying request-scoped tracing to a process that thinks in plans, not requests.

The fix is a trace built around the decision, not the call: which plan the agent chose, which tools it invoked and in what order, what it wrote to memory, what it cost, and which other agent it handed off to. That is the difference between detecting that something went wrong and being able to say why, three hops later, without re-running the whole conversation from a hunch.

A system you cannot observe is a system you are guessing about, no matter how confidently it answers.

Observability for a swarm of agents means tracing the decision path, not just the request that triggered it.

The bridge nobody draws: from context to action

Context engineering, the discipline this pillar defined in context engineering is the job now, answers a narrower question: what goes into one agent’s context window for its next step. Andrej Karpathy’s own framing, picked up and structured into a taxonomy on LangChain’s engineering blog, calls it “the delicate art and science of filling the context window with just the right information for the next step.” That is real, hard-won craft, and it is scoped to a single agent’s single turn.

The enterprise version of the ambition sits on the far bank. a16z’s framing of the coming enterprise orchestration layer describes it as “not a chatbot and not a standalone tool, but a coordinated system of agents that runs the workflow and delivers real outcomes across the business.” That echoes a16z’s own earlier call for the shift from a system of record to a system of intelligence, extended one rung further by Bessemer Venture Partners into a system of action, software that acts on data instead of just storing it. QAD operationalizes that move at the ERP layer, building agents that, in QAD’s own words, “don’t just preserve history, they proactively influence future outcomes by initiating and executing next-best actions.” Neither a16z nor BVP nor QAD invented that framing inside Apollo’s walls; the synthesis, laid out further in the system of record becomes the system of action, is what Apollo is built to run: verification, guardrails, and observability as one layer, wired into the record-to-intelligence-to-action path above, not three vendor-shaped point solutions bolted together after the fact.

Agentic engineering is the span between those two banks. Without it, context engineering stays a single-agent trick that works in a demo, and the system-of-record-to-system-of-action vision stays a slide, because nothing proves the middle holds when a dozen agents act on the company’s real state at once. That middle layer has to be built on the same premise this post keeps repeating: agentic engineering is the systems-level discipline of running many agents reliably in production: verification, guardrails, observability. It’s the layer that turns a company’s system of record into a system of action, the same reliability layer that keeps one agent honest, closer to what the loop closes inside one system argues than to a stitched-together stack of separate tools.

What this costs, honestly

None of this is free, and pretending otherwise is the same marketing move this post opened by rejecting. A real verifier, a guardrail layer that checks every hop, and a trace schema that survives a hand-off between agents is overhead a demo does not need and most teams skip precisely because the demo works without it. It is slower to ship the first version, and the slowdown does not disappear: someone has to own the verifier, someone has to own the trace schema, and neither role goes away once the agent is live. Owning verification, guardrails, and observability as one connected layer also means giving up the ability to drop in a single best-of-breed point tool for any one of the three without re-wiring how it talks to the other two, a real coupling cost, not a hypothetical one.

The trade is worth it because the two failure curves point in opposite directions. Pilot speed is a one-time number that looks the same whether the underlying agent is disciplined or not. Production reliability compounds, or it erodes, every single day the agent keeps running against real users, and only one of those paths is survivable past the first quarter.

The turn

Behind every one of those failed hops is a person, not a metric: the customer whose meeting got rebooked four times, the employee who trusted a wrong number an agent buried three tool calls deep, the user who never files a bug report and just quietly stops trusting the product. A discipline is what a field builds when it decides those people are not acceptable collateral damage from a demo. Agentic engineering is the systems-level discipline of running many agents reliably in production: verification, guardrails, observability. It’s the layer that turns a company’s system of record into a system of action, standing between a person and an agent that fails silently. ICSE co-locating a workshop with named tracks for verification, evaluation, and risk assessment is the field admitting the LinkedIn caption was never enough to keep that customer’s meeting booked once, correctly, the first time.

---

Apollo is built for the second agent in that opening scene, the one that has to survive a real cancellation email, not the one that looks good in a screenshot. The verification, the guardrails, and the observability are not features bolted on after launch, they are why an agent gets to touch a customer’s calendar unattended at all, so the meeting gets rebooked correctly once, instead of four times.