Prompt engineering starts with a person telling a model what to do. That is useful. But a real task often needs more than a good first instruction.
It needs an agent to work toward an outcome, check what happened, change its next move, and know when it is done. It may also need that agent to ask another agent for help with the right facts already attached.
That is the part of loop engineering I find most useful. It is not mainly about putting a daily job on a schedule. It is about moving from “do this next” to “work toward this goal until the evidence says you are done.” A Practical Architecture for Reliable Multi-Agent Systems puts that choice beside prompts, graphs, and a governed service layer.
You can use that loop without building a standing service. One owner with a clear goal and a useful check may be all the system needs. The loop is an alternative for work that needs iteration, not a required step on the way to a larger architecture.
This article stays with the loop itself.
A loop is a goal with feedback
The term is still new, so people do not use it in exactly the same way. But the goal-driven meaning is now common. IBM’s overview of loop engineering describes the cycle as goal, action, observation, and adjustment. The agent returns to the goal after each pass instead of waiting for a person to write every next prompt.
That is closer to what some people call goal mode. A recent practitioner guide reduces the smallest version to three things: a goal, a way to verify it, and a stopping condition. The guide’s goal-mode example is a good, plain statement of the idea.
Here is a small loop for a research brief:
Goal: Publish a two-page brief that answers the requested question.
Work: Find sources, extract the useful evidence, write the draft,
and check the claims.
Verification: Every material claim has a source. The brief answers
the question in the agreed format.
Stop: Deliver the brief when it passes the checks. If a required source
is unavailable after the agreed attempts, stop and report the gap.The loop has room to try several actions. It does not need a person to say “now search,” then “now inspect that source,” then “now rewrite paragraph three.” The goal and the evidence guide the next move.
The loop can run once. It can also run every morning, on a new ticket, or after a failed check. Scheduling answers when it starts. The loop answers how the agent keeps working after it starts.
The best next prompt may come from another agent
This is an underappreciated benefit of a multi-agent system.
An owner agent can see the job as it develops. It has the goal, the work already tried, the error, the relevant evidence, and the exact decision it needs. That lets it write a much better prompt to a specialist than a person could write before the task began.
Compare these two requests to a tooling specialist:
Can you help with this API?I am preparing the weekly research brief on electric-grid investment.
The source connector returned HTTP 404 after I called /v2/series with
the account's read-only credentials.
Please identify the current read endpoint for this data and explain
whether the account needs a different scope. Do not change credentials
or send data outside this task. Return the endpoint, the required
parameters, and a short reason for the earlier failure.The second prompt is better because the work created it. It names the goal, the failed action, the evidence, the decision needed, and the limits of the request. The specialist does not have to guess what “help” means.
That is an agent making a better prompt for another agent. It is not merely passing a message along. It is turning the state of a real job into a focused request for expertise.
The request still does not grant permission. A tooling specialist can explain the correct endpoint without gaining the right to change credentials, publish the brief, or make a business decision. That boundary matters enough to deserve its own article: Authority Should Not Travel with the Prompt.
Better prompts come from the loop, not just the template
The first prompt in a task often has to make assumptions. The next prompt can be more specific because it has feedback.
In a simple coding loop, an agent writes a change, runs a test, reads the failure, and uses that result to decide what to try next. In a research loop, it finds a weak source, asks a specialist to check it, and uses the answer to refine the brief. In both cases, the prompt improves because the system learned something about the work.
This can happen inside one agent or between agents. An agent may revise its own next instruction after reading a test result. Or it may ask a separate reviewer, researcher, or tooling expert for the piece it cannot responsibly infer on its own.
Either way, the prompt should be a small case file, not a vague request. A useful handoff normally includes:
- the outcome the owner is trying to reach;
- the relevant state and evidence;
- what has already been tried;
- the narrow question or action requested; and
- the result the owner needs back.
That structure prevents a common failure: sending a fresh agent a generic request and making it rediscover the task from scratch.
The loop needs a check, not just more attempts
An agent that keeps trying without looking at evidence is not improving. It is repeating itself.
The check may be a test, a source review, a comparison with the request, an independent review, or a human decision. The important point is that the loop has something outside the agent’s first impulse that can say “this worked,” “this failed,” or “this needs a different approach.”
That check should shape the next prompt. A failed API call should supply the error. A reviewer should supply the exact gap. A failed source check should name the claim that lost support. Generic feedback creates generic retries.
The loop also needs a real stopping condition. “Keep improving” is not one. “Run until the required checks pass, or return the documented blocker after three failed approaches” is closer. A stop rule protects attention, cost, and review time. It also gives the requester an honest answer when the work cannot continue.
Where graphs fit
A graph and a loop solve related but different problems.
A graph makes the expected path visible: research, review, approval, publication. A loop gives one owner a way to work toward a goal through feedback. A graph can contain a loop at one stage, and a loop can use a graph to choose its normal next step.
The distinction becomes important when the expected path is not enough. If the work reaches a problem nobody anticipated, the owner may need to form a new help request. That is where the broader multi-agent architecture matters: it gives the owner a responsible way to find expertise, recover, and return to the job. The pillar article explains that larger system without turning this leaf into a second version of it.
Keep the lesson after the task ends
The final step of a useful loop is deciding what should change next time.
For the API example, the owner might record that the source moved to a new endpoint. A person can then decide whether that belongs in the connector instructions, a test, a short runbook, or a new graph branch. It may also be a one-off issue that should stay with the task record and go no further.
Learning is not automatic memory. Someone still needs to judge the evidence and choose the right place for it. But without that step, the next agent starts from the same incomplete prompt and repeats the same failure.
How to Make an Agent System Learn follows that lesson from one completed task into closeouts, manager reflection, and approved change.
Put prompts to work toward a clear goal
Loop engineering does not replace prompt engineering. It puts prompts inside a process that can learn from what happened.
The basic ingredients are simple: state the outcome, let the agent act, inspect the result, improve the next move, and stop when the evidence is good enough. In a multi-agent system, there is an extra advantage: the owner can turn live task state into clear, specific prompts for the agents best placed to help.
That is a more useful promise than a daily automation. It is a way for an agent to make progress on a goal without making a human rewrite the whole task after every surprise.