Loop engineering and the missing layer in AI agents

The loop engineering paradox

Loop engineering is the idea that you keep an agent working toward a goal on its own, refining as it goes, so a human does not have to drive every step. The promise is less human intervention over time. The lived experience is often the opposite: the more capable a loop becomes, and the more you ask of it, the more maintenance, checks, and refinements it takes to keep running.

That pattern shows up with real harnesses. Building on tools like Hermes and OpenClaw was genuinely useful, but the work required to keep the system healthy could outweigh the value it returned. Running everything through the Venice API removes one whole class of that pain, the model and provider configuration you otherwise juggle across many models, tools, and modalities. Even with that complexity gone, the hard problem remained, and it was not the model. It was that the agent could not reliably analyze, fix, and learn from its own mistakes inside the loop. A loop lets an agent recover from some failures, but it rarely helps the agent understand why a failure happened, whether it has happened before, or what in the system should change so it stops happening.

The missing layer: agent identity

Prompt engineering did not remove the engineering from talking to a model. It moved it. Loop engineering does the same thing one level up: instead of babysitting the model, you end up babysitting the loop. The human stays in the picture either way.

There is also a layer nobody talks about enough. A prompt tells the model what to say. A loop tells the agent to keep working. Neither one defines the agent itself. An agent identity is the answer to a set of questions the prompt and the loop leave open: what does this agent know, which models and tools can it use, what other agents share its environment, what is it allowed to do, and how should it behave across tasks and conversations. That identity matters far more than it usually gets credit for, and today it is a real gap.

Prompts, minds, and loops

A clean way to hold the three ideas apart:

• Prompt engineering shapes a single response.
• Loop engineering shapes how an agent works over time.
• A mind shapes the agent in between: its identity and configuration.

Instead of hand-implementing every part of a harness, you define what the agent is: give it instructions, models, tools, and knowledge, and connect it to capabilities through Venice so it can work across modalities and act as one entity you plug into a larger system.

A mind still leaves the human in charge of designing the system. It just moves more of that design into intention and configuration rather than infrastructure. And once an agent is explicitly configurable, a harder question opens up: when a system fails the same way over and over, who is responsible for changing the configuration? That question is what pushes past better loops toward systems that can improve their own loops.

Minds is previewed here and is not publicly released yet. Treat this section as the direction Venice is heading, and check Venice for current availability before you plan around it.

Self-improving harnesses: the research

A useful observation from recent research: an agent's behavior is not determined only by the model or the prompt. It is also determined by the harness around it, the tools, the routing, the memory, the recovery policies, the verification rules, and the permissions. Change the harness and the same model, under the same prompt, can behave completely differently.

That reframes the question of who improves the harness. One paper, on self-improving "self-harnesses," lays it out in three pictures:

• Human harness engineering: the agent works inside a system a person designed, and when something breaks, the human drives the fix.
• A meta-harness: a second agent sits outside the target agent and improves the system on its behalf.
• A self-harness: the model itself participates in improving the harness it runs through, studying how it behaved, finding repeated failure patterns, proposing a bounded change, and testing whether that change actually produces better behavior.

A second paper on a "continual harness" arrives at a similar place through a three-stage progression: a human rewrites the harness by hand, then an automated refiner does it while the system runs, and eventually the model and the harness learn together.

Gondola: a self-harness experiment

Gondola is a small open-source experiment built to test these ideas in practice. It is not trying to replace existing harnesses. It takes the pieces that keep coming up and wires them into an agent orchestration that tries to recover from its mistakes and keep learning as it runs. The central bet is that recovering from a mistake and learning from a mistake are not the same thing, and today's loop engineering mostly does the first, not the second.

The architecture has two loops:

• The inner loop, called the entity, does the work: writes code, makes media, searches, talks to you.
• The outer loop, called the gondola lab, has a different job: it watches how the work happened and asks whether the process is working, whether a failure is recurring, and whether there is enough evidence to justify a change.

When the inner loop breaks, a supervisor tries to recover the current run instead of letting the whole workflow die. After a run, the traces go to the lab, which looks for patterns, proposes challenger configurations, and verifies that a proposed change actually performs better before adopting it. Early on those changes are gated behind human approval, with the goal that the system eventually needs approval less and less. All of it, from dictation and file parsing to voice and memory, runs on the Venice API from a single key, with one dashboard for calls and spend.

Watching it fail, recover, and learn

The test gives the agent, named Gary, a deliberately vague, creative goal: find recently released open-source AI projects that are technically impressive, useful to developers, and under-appreciated, research at least five, compare them, pick the strongest, and make a 60 to 90 second explainer video about it. That is a lot of tools and judgment in one task: search, reasoning, video generation, evaluation, revision. The run used GLM 5.2, and failure was an acceptable outcome, since the point was to watch the system behave.

It did fail, usefully. Gary got the script done, then called the wrong tool. Asked to explain and fix itself, it correctly diagnosed the mismatch and set up an execution plan so the runtime could track and recover. Meanwhile the gondola lab flagged recurring issues from earlier runs and drafted harness changes: for example, a rule to inspect generated images before animating them, and a new "ability" the agent created for itself when it noticed a tool it needed did not exist. Gary eventually produced a video that ran the full length that was asked for. The lesson worth keeping: a less capable model with the right tools and a clear identity outperformed a frontier model that was never given that identity. How much an agent understands about what it is changes its behavior that much.

What comes next: minds

Gondola and the gondola lab are early. The lab understands only a few failure patterns, the evaluations are simplified, the recovery system has room to grow, and the right relationship between the outer loop and the acting layer is still an open question. Building it in the open surfaced the harder, more philosophical questions rather than answering them: should an agent understand what it is, should recovering from a failure and improving the system be handled by the same intelligence, and how much freedom should the acting agent have to rewrite its own tools, prompts, or memory. Gondola is open source if you want to try it, break it, or contribute.

This is where minds get interesting. A mind gives you an explicit place to define what an agent is: its identity, tools, capabilities, memory, how it should behave, and how far it is allowed to reach into your infrastructure. That is far more concrete to inspect, evaluate, version, and govern than a harness scattered across prompts and code you no longer remember. Minds are described here as coming soon for public release, a step toward more capable and more independent agents. Until then, this is a preview of the direction, not a feature you can ship on today.

Key takeaways

• Loop engineering moves the engineering work up a level rather than removing it, so more capable loops can mean more maintenance.
• The usual failure point is not the model. It is the agent's inability to analyze, fix, and learn from its own mistakes inside the loop.
• Prompts shape a response, loops shape work over time, and a mind shapes the agent in between: its identity and configuration.
• Recent research frames the next step as self-improving harnesses, where the system helps improve the process it runs through, not just recover from failures.
• Gondola tests that idea with an inner loop that does the work and an outer loop that learns from how the work went, all on the Venice API.
• Minds is previewed, not released. Verify availability in Venice before planning around it.