How to engineer an AGENT?

The biggest bottleneck in AI is no longer intelligence. It is attention.

A year ago, the limitations of AI coding tools were obvious. Models could only read a limited amount of code, their context degraded during longer tasks, and they often forgot decisions made earlier in the conversation. As context windows expanded and models became more capable, those limitations began to matter less. Compute then became the next practical constraint, especially when developers started running multiple agents, browsers, test suites and development environments simultaneously.

Cloud environments, cheaper inference and remote execution are gradually reducing that problem as well. What remains is a more difficult constraint: how frequently the agent needs a human to step in.

An agent may be able to generate thousands of lines of code, but that does not mean it has saved the engineer any meaningful time. If it stops every few minutes to ask a question, requires constant correction, or returns a large implementation without enough evidence to verify it, the human still carries most of the cognitive load.

This is where agent engineering begins. The objective is not simply to make the model more capable. It is to design a system in which the agent can move from instruction to a trustworthy outcome while requiring as little unnecessary human attention as possible.

A Better Model Does Not Automatically Create a Better Agent

Most attempts to improve an AI agent begin with the model. Teams provide it with a larger context window, more tools, detailed system prompts and access to a greater portion of the repository. These changes can improve its raw ability, but they do not necessarily improve the overall engineering workflow.

A powerful model that requires supervision every five minutes is still close to an advanced autocomplete system. The developer gives it a task, waits for it to generate code, answers a question, corrects a misunderstanding, explains the architecture again and eventually reviews a large diff without fully understanding how the agent arrived there.

The system may have produced more code in less time, but it has not necessarily reduced the developer's mental workload. In some cases, it simply converts implementation work into review and debugging work.

The real goal should therefore be different. Instead of maximizing the quantity of code an agent can produce, we should minimize the number of moments in which the agent needs a human to re-enter the process.

An agent is not truly engineered by connecting a language model to a terminal. It is engineered by designing the complete path between receiving an instruction and presenting a verified result.

An Agent Loop Is Really a Workflow

The term “agent loop” is often presented as something fundamentally new. In practice, most agent loops are structured engineering workflows with an AI model coordinating the steps.

A useful coding agent should first understand the task and inspect the relevant parts of the system. It should then form a plan, implement the change, run the appropriate tests and review its own work. When it finds an issue, it should correct it and repeat the verification process. Only after it has collected enough evidence should it return the task to the human.

The value of the loop is not that the model continues running for a long time. A long-running agent can still waste time, repeat itself or move confidently in the wrong direction. The value comes from giving the workflow enough context, tools and verification mechanisms for the agent to progress without constant supervision.

A weak agent returns after writing code. A stronger agent returns after building confidence that the code is correct.

That distinction matters because code generation is now relatively cheap. Understanding whether generated code is safe, appropriate and complete remains expensive.

Preserve the Process, Not Only the Final Diff

Consider receiving a pull request that contains several thousand changed lines. One version may have been produced in a minute from a vague prompt such as “fix issue 248.” Another may have been created after careful investigation, architectural analysis, failed experiments and multiple rounds of testing.

The final diff may not clearly reveal the difference between those two processes.

This is why the transcript of an agent session can become part of the engineering artifact. A sanitized transcript can show what the developer asked the agent to do, which files it inspected, what assumptions it made, what approaches it considered, what failed and why the final implementation was selected.

The transcript does not prove that the implementation is correct. A detailed conversation can still lead to poor code. However, it provides something the diff alone cannot provide: the path that produced the result.

This information is useful for both human reviewers and future agents. A reviewer does not need to reconstruct every architectural decision from the final code, while a future agent can understand why the system was changed instead of treating the existing implementation as unexplained history.

As AI becomes more involved in software development, the process that produced the code will become almost as important as the code itself.

Use a Separate Agent for Review

The agent that implements a feature is naturally biased toward its own solution. It remembers what it intended to build, which can make it less sensitive to gaps between intention and execution.

A separate review agent begins with fresh context. Its role is not to continue implementation but to challenge the work. It can compare the result with the original requirement, inspect whether existing behaviour has changed, evaluate architectural consistency and look for missing error handling, weak tests, unnecessary complexity, security concerns or performance risks.

The review should then return to the implementation agent. The original agent can evaluate the findings, correct legitimate issues and reject suggestions that do not fit the intended design.

This review loop needs boundaries because AI reviewers can easily become overenthusiastic. They may attempt to handle every imaginable edge case, introduce abstractions that are not needed or recommend changes outside the original scope. A system that blindly accepts every review comment may produce more complexity rather than better software.

The workflow should therefore include clear invariants. These may state that the agent must not modify generated files, change public API contracts, introduce new dependencies without approval, rewrite deployed database migrations or redesign unrelated parts of the application.

These rules prevent the review process from expanding a focused task into an uncontrolled refactor. The purpose of review is not to create more changes. It is to increase confidence in the changes already made.

Give Every Agent a Clean Environment

Running multiple agents locally can quickly turn a laptop into a noisy and unreliable development server. The larger problem, however, is not resource usage. It is that the local machine is rarely a clean environment.

A developer's computer may contain cached dependencies, global packages, old build files, environment variables, uncommitted configuration changes and services that happen to be running in the background. A feature may work locally because the machine has slowly accumulated everything required to support it.

That is not strong verification. It is familiarity.

A better agent workflow creates an isolated environment for every task. The agent should be able to start from a clean machine, clone the repository, apply its changes, install dependencies, run the application, execute the relevant tests and verify the result in the required runtime or operating system. Once the task is complete, the environment can be discarded.

Moving execution away from the developer's machine reduces local resource pressure, but the more important benefit is reproducibility. The system is no longer asking whether the implementation works on one familiar computer. It is asking whether the implementation can work again from nothing.

This makes isolated environments valuable not only for agents but also for the quality of the engineering process itself.

Verification Should Be Visible

An agent saying that an issue has been fixed is not evidence. A passing test is better, but a test only proves the behaviour it was designed to check.

For visual products, the agent should produce visual proof. A UI task may include a screenshot of the original problem, another screenshot showing the corrected state and a short recording of the interaction. It should also explain the steps used to reproduce the issue and the steps used to verify the solution.

This changes the role of the human reviewer. Instead of opening the project, navigating to the relevant screen, recreating the issue and manually checking whether it has been resolved, the reviewer can first inspect the evidence produced by the agent.

The human can then decide whether the change requires deeper investigation. The developer is no longer watching the agent complete every step. The developer is evaluating the result and the evidence supporting it.

This is a much better use of attention.

The same principle applies outside user interfaces. Backend changes can include test output, relevant logs, database assertions or performance comparisons. Infrastructure changes can include deployment previews and health checks. The form of evidence may change, but the principle remains the same: the agent should not merely report completion. It should demonstrate it.

The Human Should Move Higher in the System

The purpose of agent engineering is not to remove the human from software development. It is to move the human away from repetitive supervision and toward decisions that require judgment.

An agent can decide how to implement a button, but a person should decide whether the button belongs in the product. An agent can refactor a service, but a person should determine whether the service supports the long-term direction of the system. An agent can inspect logs, execute tests and compare screenshots, but a person must still decide whether the overall experience feels correct.

Agents are effective when working within a clearly defined task. That focus is also one of their limitations. They may optimize one part of the system without understanding how the decision affects the rest of the product, the company or the customer experience.

Someone still needs to understand the whole system. That remains the engineer's responsibility.

The engineer's role does not disappear as agents become more capable. It shifts from manually producing every implementation detail to designing the environment, constraints and verification systems within which implementation happens.

The Next Engineering Bottleneck

AI allows teams to produce more code, test more ideas and run more experiments than before. However, every increase in output creates additional work that must be understood, reviewed and maintained.

The future of software development will not belong to whoever can run the greatest number of agents. It will belong to those who can design systems in which agents produce trustworthy outcomes without consuming all the attention they were expected to save.

A well-engineered agent does more than generate code quickly. It understands the task, inspects the system, creates a plan, implements the change, reviews its work, verifies the result and presents evidence before returning control to the human.

The final product of automation is not more code. It is more space for engineers to think.