The Agentic Engineering Exosuit

I keep coming back to the same idea: the real work in agentic engineering is not getting one agent to do one impressive thing.

It is building the systems and loops that let you scale yourself.

The metaphor I keep reaching for is an exosuit. Not because it replaces the engineer, but because it amplifies the engineer. It gives you more reach, more leverage, and more ability to move heavy things, but only if the frame is well-built. A bad exosuit does not make you stronger. It injures you faster.

That is roughly where I think we are with agents right now.

A lot of the public conversation is still about the model, the IDE, the prompt, or the demo. Those things matter, but they are not enough. The durable advantage is in the operating system around the agents: the docs, tests, routing, review loops, feedback cycles, conventions, and safety rails that let the work compound instead of merely happen.

The Agent Needs A Map

The first failure mode I see is treating every agent session as if it starts from zero.

It should not.

A serious codebase needs a map. Maybe that starts with an AGENTS.md, but the file itself is not the point. The point is routing. The agent should know where to find the workflow, which docs explain the system, which tools are expected, which tests matter, and what kind of review should happen before the work is considered done.

That map should not be a giant wall of instructions. I want something closer to wayfinding. If the agent is touching payments, point it to the payment docs. If it is changing UI, point it to the visual checks. If it is working on a risky subsystem, point it to the review expectations.

The same applies to workflow. I do not want every session to rediscover how I like work to proceed. I want a repeatable shape: understand the problem, inspect the code, make the smallest useful change, run the app, validate the behaviour, fix what breaks, and leave enough context that the next person or agent can continue.

This is not about making the agent obedient in some theatrical way. It is about reducing ceremony. The more the environment explains itself, the less energy goes into prompting and re-prompting.

I also like important docs to start with a short, useful summary. The first few lines should answer what the doc is, when to read it, and what decisions it helps with. That makes the docs greppable, skimmable, and easier for agents to discover without needing the whole repo stuffed into context.

This sounds boring. It is. Most good engineering leverage is at least a little boring.

Evidence Beats Confidence

Agents are very good at producing plausible work.

That is useful, and also dangerous.

Plausible code is not the same as working software. So the agentic loop needs evidence built into it. The agent should run the thing it is changing. If it is a web app, open it and click around. If it is a CLI, run the command. If it is a service, exercise the endpoint. If it is a library, write or run the smallest useful consumer.

“I changed the code” is not enough.

“I changed the code, ran the app, saw the behaviour, found a problem, fixed it, and re-ran the validation” is the shape I want.

Tests matter more in this world, not less. Especially end-to-end tests around important flows. I want agents writing targeted tests during implementation, improving tests when they find gaps, and using docs that explain how this codebase tests things well.

I also want agents to question the tests themselves. A false-confidence audit is just asking: are these tests evidence, or decoration? Do they exercise the behaviour that matters, or implementation trivia? Would they fail if the feature were actually broken?

That is a very testing-shaped question. It is not new just because an agent is asking it. It is the same old discipline with a new worker available to do some of the grinding.

For UI work, visual regression is part of the loop. Take screenshots. Compare them. Have a tool check the diff, and then have an agent review the result visually. If performance matters, give agents benchmark and profiling commands they can run before and after a change.

This is not about making every change heavy. It is about making the important evidence cheap enough that agents will actually collect it.

Review Is A System

I do not want the same model that wrote the code to be the only model that reviews it.

Review gets stronger when it has shape. Sometimes that means a different agent or model. Sometimes it means a different persona. “Review this code” is weak. “Review this as the maintainer who will own it during a production incident” is much stronger.

Different reviewers can look for different risks: maintainability, security, performance, domain correctness, operational failure modes, or the weird little “AI smells” that show up when code looks reasonable but is spiritually cardboard.

This can happen at a few points in the work, not just at the end. Review the research when the problem is still being framed. Review the plan before a large implementation. Review the code before it is treated as done. Review the wrap-up when the agent says the work is complete.

I especially like review that improves the system, not just the patch. If a reviewer notices a recurring issue, maybe that becomes a convention, a lint rule, a test helper, a doc update, or a reusable command. Good review should leave the codebase a little more reviewable next time.

This is where custom linting gets interesting. Some feedback should not stay as prose. If a pattern is objectively wrong and fixable, the best version of the lesson is a pre-commit check with --fix. If it cannot be fixed deterministically, maybe the command can call a cheaper model to produce the smallest safe repair.

The point is not to create more scolding. The point is to turn repeated judgement into infrastructure.

Memory Is Leverage

Agents are transient. Codebases are not.

That mismatch matters.

If an agent discovers something important, the knowledge should not evaporate when the session ends. Architecture docs, testing notes, runbooks, conventions, and review guidance should all be treated as living infrastructure. If a command changed, update the docs. If a pattern changed, update the pattern. If a surprising failure happened, capture the lesson where the next agent will find it.

I also want a context trail during meaningful work. Not a raw transcript. Raw transcripts are noisy. I want the useful trail: the avenues explored, the decisions made, the things ruled out, and the evidence that got us to the current state.

The test is simple: if we lose the thread halfway through, can another agent or future me pick it back up without starting from zero?

That is the point of the context trail. Not paperwork. Recovery.

There is another memory loop too: agent feedback. At the end of a session, I want to know what made the work harder. Was a doc missing? Was a command confusing? Was a test slow? Did the agent keep needing context that should live in the repo?

That feedback is gold if you periodically fold it back into the workflow. The exosuit gets better by noticing where it pinches.

Automation Becomes Infrastructure

Not everything needs fresh reasoning.

Some tasks are mostly deterministic: run the standard review, collect diagnostics, compare screenshots, profile a change, check recent commits for gotchas, prepare a release. Those tasks should become scripts or commands.

The script may still contain agentic steps. That is fine. The important part is wrapping the repeatable shape of the task so daily agents can use it as a building block instead of rediscovering the procedure each time.

A tools or bin folder becomes part of the agent environment. If running reviews requires awkward CLI incantations, wrap them. If profiling needs setup, make a command. If screenshots need comparison, make the happy path obvious. If a task is painful twice, consider turning it into a tool.

This is one of the places where the exosuit metaphor really works for me. The scripts, docs, workflows, and review tools become the frame. They hold the repeatable weight so the engineer can spend judgement where it matters.

Autonomy Needs Boundaries

The more autonomy you give an agent, the more explicit the boundaries need to be.

That starts with a queue the agent can actually read. It might be Linear, GitHub Issues, Jira, or a humble TODOS.md. The sophistication matters less than the accessibility. The agent needs to know what is ready, what is blocked, what has already been attempted, what “done” means, and where the result should be written back.

Without a visible queue, autonomous work becomes improvisation. Sometimes improvisation is useful. But sustained leverage needs a queue and a definition of done.

The closeout matters too. For a short interactive session, targeted tests might be enough. For longer autonomous work, I want the agent to come back with evidence: the app ran, relevant tests passed, visual and performance checks happened where they mattered, docs were updated, and review happened if the change was meaningful.

The loop is not finished when the code changes. It is finished when the system is a little easier to work in next time.

What I Would Start With

If I were starting from scratch, I would not try to build all of this at once.

I would start with the smallest version of the exosuit:

A map that points agents to the right workflow, docs, tools, and tests.
A habit that agents run the app and bring back evidence.
A review loop that uses a different model, persona, or perspective.
A context trail for work that might need to be resumed.
A few reusable commands for the tasks agents perform repeatedly.

Then I would add stronger gates: visual regression, performance benchmarks, false-confidence audits, richer documentation, periodic sweeps across recent work, and more specialized review personas.

The full version is powerful, but it is also machinery. Machinery has maintenance costs. If the process gets too heavy, people route around it. The right answer is not maximum process. The right answer is the lightest system that preserves judgement while increasing leverage.

The Point Is Still Judgement

I do not think agentic engineering makes the engineer less important.

I think it changes where the engineer’s importance shows up.

Less time typing every line. More time designing loops. Less time remembering every convention. More time deciding which conventions deserve to be encoded. Less time manually checking every surface. More time deciding what evidence would actually prove the work is good.

The engineer becomes the person designing the system that produces, checks, improves, and remembers the work.

That is the state of agentic engineering for me right now. Not magic. Not replacement. Not a pile of prompts.

An exosuit.

One that needs maps, evidence, review, memory, infrastructure, and boundaries.

And, as always, someone inside it who still knows what good work looks like.