All posts
6 min read

Agentic Engineering

What it means to engineer systems where AI agents are first-class participants — and why we think it deserves a job title of its own.

agenticaiengineeringclaudemcp

By Nick Meinhold & Claude

TL;DR: An agentic engineer doesn't just use AI to write code faster. They design the systems in which AI agents work — the tools, the contracts, the orchestration, the verification. The deliverable isn't a feature; it's a feature plus the machinery that lets agents extend it without you. Robin Langer is one. We think you'll see the title more.

There's a thing happening in software that didn't have a clean name a year ago, and now it has several. Agentic engineering, agent engineering, AI engineering past vibe coding — they're all reaching for the same shape. The thing in the middle is real, even while the label settles.

I want to give it the version of the name we use, and explain why we treat it as a discipline distinct from "engineering with AI as a tool."

The shift, in one sentence

Simon Willison has been writing about this longer than most, and his framing is the cleanest I've seen: agentic engineering is what happens when you stop treating an LLM as autocomplete and start treating it as a participant that can be delegated to, with guardrails. IBM's working definition compresses it further: the discipline of designing, evaluating, and orchestrating non-deterministic AI systems using explicit specification, feedback loops, and operational guardrails.

Those are good definitions. They miss what it feels like to do.

What it feels like is this: you stop writing the code and start writing the contract. What outcome must hold? What invariants must be preserved? What's the verification you'll run after the agent has produced output? The actual implementation is increasingly something the agent generates from the contract — and your job is to make the contract good enough that the agent can succeed unsupervised.

Why it deserves a title

I can hear the objection: isn't this just "engineering"? With a different toolchain?

Maybe in five years. Right now, the gap between someone who reaches for Claude as autocomplete and someone who designs multi-agent systems with proper contracts, isolation, and verification is the gap between someone who can use a database and someone who can design a schema. Both are valid. They are not the same job.

The numbers say the field is institutionalising fast. Gartner expects 40% of enterprise applications to embed AI agents by the end of 2026, up from less than 5% a year ago. ICSE 2026 has its first workshop dedicated to agentic engineering. The AgentEng conference bills itself as "the engineering behind agentic AI." MCP — the protocol most agents use to call tools — has 97 million SDK downloads and was donated to the Linux Foundation last month. This is no longer a frontier; it's a stack with a roadmap.

When someone says they're hiring an agentic engineer, they're saying:

I need someone who can extend our systems by extending the agents that build our systems. Someone who reasons about tool design and orchestration as first-class concerns, not as afterthoughts on top of normal engineering.

That's a real distinction, and it deserves real language.

The four core skills

Distilled from a year of doing this for clients and on our own infrastructure:

1. Tool design. When we built Dreamfinder, our team-running Claude agent, the unit of work wasn't "feature" — it was "tool." A new capability is a new MCP function with a strict signature: input schema, output schema, error modes, idempotency. Building those tools well is the difference between an agent that succeeds 80% of the time and one that succeeds 99% of the time. The 19% gap is almost entirely about tool design.

2. Orchestration shapes. One agent doing one thing is the easy case. The interesting cases: many agents working in parallel; agents with different inductive biases reviewing each other's work; agents that decompose a task, fan out subtasks, aggregate results. Knowing when to use which shape — and what failure modes each has — is the new skill. Subagents that ping the orchestrator mid-flight are an antipattern; well-briefed subagents that ship without coming back are the goal.

3. Verification on the production reference. "I ran the tests" is not the same as "the bytes on the production branch match the fix." When agents are touching real systems, the closing ritual matters more than ever: read state from the actual production source, confirm the deployed bytes, watch one cycle of any cron-driven workflow before declaring done. We learned this the hard way after a fix sat unmerged behind a CODEOWNERS gate while a different bug corrupted production overnight.

4. Knowing when not to delegate. The skill that compounds slowest. There are tasks where the round-trip cost of briefing an agent and verifying its output exceeds the cost of just doing the thing yourself. Spotting them quickly is what separates good agentic engineers from people who delegate everything by default and call it productivity.

A week in the life

What it looks like in practice at Enspyr last week:

  • Monday. A client's invoicing flow has a bug. Instead of fixing it directly, you write the contract: the agent should add idempotency keys to the payment-creation handler, with a regression test that proves duplicate submissions don't double-charge. You hand it to a sub-agent in an isolated worktree. It opens a PR. You review the diff (because trust but verify). It merges itself.

  • Tuesday. You add a new MCP tool to your team's project-management agent so it can read Linear issues. You don't write the integration; you specify the input/output schema, the auth model, and the rate-limit behaviour, and the agent implements it from the spec. You test the spec by giving it five queries that exercise edge cases.

  • Wednesday. A multi-agent debate isn't reaching closure. You realise the orchestrator's phase-transition logic is too eager — it cuts off rebuttals before they've landed. You don't patch the bug; you write a contract describing what good closure looks like and let the agent rewrite the phase logic against that contract.

  • Thursday. A junior engineer joins the team. You spend the morning teaching them not how to write code, but how to design tools an agent will use. The hardest part is unlearning the instinct to write the function themselves.

  • Friday. You ship three PRs. You wrote zero lines of the diffs. You wrote every line of the contracts the agents satisfied to produce them.

That's not science fiction. That's last week.

The bar is going up

Agentic engineering raises the bar for the engineer, not lowers it. The agents are extraordinarily good at filling in implementation detail, which means the load-bearing skill becomes specifying the right thing — the right contract, the right tool boundary, the right verification, the right orchestration shape. If you can't articulate what success looks like, the agent can't deliver it. If you can, the agent is faster than you've ever been.

So when you see Agentic Engineer on a profile, don't read it as a buzzword. Read it as: this person can extend the systems that build the systems. Read it as: this person has thought hard about what the next layer of leverage looks like.

We hire for that. We think you should too.

Robin Langer is one of our agentic engineers at Enspyr. If you're hiring for one — or you'd like to be one — get in touch.