Agentic Engineering: Building Software With Fleets of Agents"

For two years "AI for coding" meant autocomplete — a model guessing the next few lines while you drove. That era is closing. The interesting work now is agentic engineering: systems where an AI agent takes a high-level goal, plans the steps, edits files across a codebase, runs the tests, reads the failures, and opens a pull request — with you supervising rather than typing.

This post is about what that phrase actually means, the design patterns that survive contact with production, and how the job changes when your output is no longer code but the agents that produce it.

What agentic engineering actually is

Forrester's working definition is a good anchor: the use of AI agents that can plan, generate, modify, test, and explain software artifacts across multiple stages of the SDLC, working alongside humans with a degree of autonomy.

The key word is autonomy. A code assistant waits for you between every step. An agent runs the loop itself:

An agent is a loop with a goal: it picks an action, executes it, observes the
result, and decides what to do next — without asking permission at each turn.

That single shift — from "suggest the next token" to "execute multi-step work and verify it" — is what separates agentic engineering from the autocomplete era.

The patterns that hold up in production

Most agent demos work because the operator knows exactly what to type. Production is messy: vague requests, flaky tools, models inventing APIs that don't exist. A handful of patterns consistently separate systems that ship from systems that impress on stage.

1. Single-responsibility sub-agents + a router

The most durable architecture in 2026 isn't one giant do-everything agent. It's a set of tightly scoped sub-agents — one for retrieval, one for codegen, one for test-running — coordinated by a supervisor that routes work to the right specialist based on intent.

SPECIALISTS = {
    "retrieve": retrieval_agent,   # finds relevant files / docs
    "edit":     codegen_agent,     # writes the change
    "verify":   test_agent,        # runs tests, reads failures
}
 
def route(task: Task) -> Agent:
    """Send each task to the agent that owns that responsibility."""
    return SPECIALISTS[classify_intent(task)]

Narrow agents are easier to prompt, cheaper to run, and far easier to debug — when something goes wrong, you know which agent owns the failure.

2. Design tools, not prompts

The biggest lever on agent quality is the tool interface, not clever prompting. Keep tools narrow, well-named, and strict about their inputs.

from pydantic import BaseModel, Field
 
class RunTestsInput(BaseModel):
    path: str = Field(..., description="Test file or directory to run")
    pattern: str | None = Field(None, description="Optional -k filter")
 
def run_tests(args: RunTestsInput) -> dict:
    """Run the test suite and return a structured pass/fail summary."""
    result = pytest_runner.run(args.path, k=args.pattern)
    return {"passed": result.passed, "failed": result.failed,
            "failures": result.failure_messages[:5]}

A typed schema gives the model a contract and gives you validation for free.

3. Make failures legible

An agent can only recover from an error it can understand. Return failures as data, not stack traces.

4. Close the loop with verification

The thing that turns a flashy demo into a trustworthy system is that the agent checks its own work before handing it back. Generate the change, run the tests, read the output, iterate. An agent that writes code but never runs it is just a faster way to produce bugs.

5. Keep the human in the loop at the right altitude

Autonomy is a dial, not a switch. The high-leverage human checkpoints are at the boundaries: approving the plan before work starts, and reviewing the diff before it merges. Babysitting every intermediate step throws away the speed; removing the boundary checks throws away the safety.

How the engineer's job changes

The 2026 engineer spends less time writing foundational code and more time:

• Designing system architecture the agents work within.
• Defining clear objectives and acceptance criteria for agent tasks.
• Building the tools and guardrails agents operate through.
• Rigorously validating output — the human becomes the quality bar.

Your value moves up the stack: from how do I write this function to how do I specify, equip, and verify the thing that writes it. The teams winning with this aren't the ones who let agents run wild — they're the ones who got good at delegation: clear goals, sharp tools, tight feedback loops.

Where to start

You don't need a multi-agent swarm on day one. Start with one well-scoped task — say, "fix the failing test in this module" — give the agent exactly two tools (read files, run tests), and watch the loop. Tighten the tools and the goal until it's reliable, then add a second responsibility. Agentic engineering is less about bigger models and more about the unglamorous discipline of scoping, tooling, and verification.

The model supplies the intelligence. You supply the engineering. That division
of labor is the whole discipline.