Introducing Autoloop: the agent optimization engine that keeps agents performing at production scale

Enterprises set the goals for their agents. Autoloop finds where they fall short and fixes the cause without breaking what already works.

Customer: "Hi, can you change the delivery address on my order to 4 Elm Street?"
Agent: "Of course. Your order will now ship to 4 Elm Street. Anything else?"
Customer: "That's all, thanks."

When you read the transcript and it looks like nothing is wrong. That is the problem. The agent never verified who it was talking to before it changed the address, and a check that never runs leaves no words behind. No error was logged, the customer was happy, and a reviewer would score the call perfect. The same three lines from someone who wasn't the account holder would read exactly the same.

Most teams attempt to solve these problems using a manual, iterative workflow. Reviewers manually parse conversation transcripts, attempt to diagnose the root cause behind a failed interaction, manually craft prompt tweaks or policy adjustments, and then redeploy the agent in hopes that the issue is resolved.

While this trial-and-error methodology can suffice for small-scale deployments with straightforward user journeys, it rapidly degrades as complexity increases. In modern enterprise environments, where interconnected networks of specialized agents, custom tools, dynamic handoffs, and strict operational policies govern user interactions, a change intended to fix one path can easily introduce unseen regressions into another that was previously functioning as intended.

Today we’re releasing Autoloop, the optimization engine in Artemis.

Teams define the goals an agent is expected to meet. Autoloop builds the agent, measures its behavior against those goals, and keeps improving it from the first build through production. A change is only retained after it has been verified.

Every proposed change passes a gate and is then re-evaluated against all seven goals. If the change can be verified, it is kept. If it cannot, Autoloop rolls it back and holds it for a person.

From a failed interaction to a verified repair

Here is what Autoloop does with the same refill failure.

1. Goals. Task completion, end-user experience, business-rule adherence, and guardrails and safety all apply to this turn. Any change also has to be evaluated against the other three goals.
2. Evaluate. The scorers evaluate the execution path across the agent network, not only the final response. In this case, the refill never started, the handoff was rejected, and an internal message reached the caller.
3. Diagnose. StateTrace follows the turn across the agents involved. The first agent verified the member, but the handoff condition only allowed order-status requests and did not receive that verification state. The failed refill and the exposed error occurred on the same path, but they came from two different problems.
4. Optimize. ABL maps each problem back to the construct that produced it. The routing rule is repaired so that a verified member asking for a refill reaches the refill path with the verification state attached. The rule that allowed the internal error to reach the caller is fixed where text exits the system rather than by adding another instruction to a prompt.
5. Gate and re-verify. Both changes are checked before they are applied and then evaluated against all seven goals together. A version that reaches the refill path by skipping identity verification fails business-rule adherence and is rejected. A version that hides the error but still fails to start the refill fails task completion and is rejected as well.
6. Apply. In Autopilot, changes that pass are retained automatically. In Copilot, a person approves them first. A routing change involving identity is an example of something a team may want to hold for review. In Advisor, Autoloop provides the recommendation along with the supporting trace.

The ZIP code issue required one edit. The refill problem required two changes in different parts of the system, and both had to be verified against the rest of the agent’s expected behavior.

That is the kind of problem Autoloop is built to handle.

Why improving agents is harder than it looks

Most agent optimization systems today follow the same basic pattern we tried first: evaluate the agent, ask a model to generate a fix, then evaluate it again.

It works for simple failures. It breaks down when the problem is deeper in the system.

A lower score tells you performance moved in the wrong direction, but not which step, handoff, tool, or state caused it.

The generated fix can also target the wrong part of the system. If the actual problem is a missing tool contract, test fixture, or routing rule, changing the prompt does not resolve it. In some cases it simply changes how the same failure appears.

And an improvement against one goal can introduce a regression somewhere else. Reducing token usage, for example, can also reduce task completion or weaken a safety check.

Our early loops spent too much effort generating patches with a model and judging them using a single score. When the underlying problem was structural, they did not converge. In one experiment, giving the model more evidence made things worse: it took more steps and produced no proposals at all.

That shaped the way we built Autoloop.

Problems that can be diagnosed and repaired deterministically are handled that way. Contracts, fixtures, and routing rules each have their own repair mechanisms. The model is used where judgment is actually required.

And every change still has to be verified against the rest of the agent’s expected behavior.

How Autoloop works

Goals become the optimization target

Teams configure goals across seven dimensions: task completion, accuracy and grounding, business-rule adherence, token and cost efficiency, end-user experience, robustness, and guardrails and safety.

These goals become the criteria Autoloop uses to evaluate the agent and every change made to it.

One continuous loop from build through production

Before launch, Autoloop builds the agent and its test coverage from the enterprise’s operating procedures. In production, real interactions trigger new cycles. Every change is evaluated against the configured goals, so improving one dimension does not come at the expense of another.

StateTrace pinpoints where and why a goal was missed

Artemis runtime traces every handoff, state change, tool call, and piece of context across the agent network. Autoloop then uses deterministic scorers to evaluate the execution path and identify the cause of failure, not just the symptom.

ABL gives every change a precise target

Agents built on Artemis are written in Agent Blueprint Language and compiled.

Every step in a trace maps back to the construct that produced it. Autoloop can change exactly that construct instead of rewriting an entire prompt and hoping it works.

Each journey climbs a readiness ladder

Each journey progresses through a sequence of checks: it must compile, have complete contracts, and pass simulation, robustness, and behavior validation. Each stage identifies the exact blocker, showing teams what still stands between the journey and production.

Every change passes a validation gate

Every proposed change is validated before it is applied. If it fails to improve the agent or introduces regressions elsewhere, the change is rejected and the project remains unchanged. If Autoloop cannot verify a change, it retries up to two times before rolling it back and holding it for human review.

Teams decide how much to delegate

Autoloop supports three operating modes: Autopilot applies changes that pass its gates, Copilot proposes changes for human approval, and Advisor only recommends them. Users without permission to apply changes operate in Advisor.

What Autoloop doesn’t do

Autoloop optimizes against the goals and tests it is given.

If a goal has not been identified or stated, the system cannot optimize for it. Weak tests make for weak evidence.

Some fixes require new tools, new data, or a policy decision. Autoloop identifies and presents those blockers and show where they occur, but people still has to resolve them.

That boundary is important. Autoloop is not going to try arbitrary changes just to boost the score up. It identifies where behavior failed, changes the part of the system responsible, and keeps the change only when the resulting behavior can be verified against the defined goals, evidences, and policies

Autoloop is now available in Agent Platform {Artemis}.