Goal-Based Loop Engineering: From Spec-Driven to Outcome-Driven

Loop engineering is how we get agency from AI. Prompt engineering got us through 2024, Context engineering in 2025 (and continues to be important) and now loop engineering is all the rage in 2026. Whether it’s development lifecycles managed as compounding/continuously improving loops, scheduled routines, or truly autonomous agentic workflows, these all rely on effective loop engineering.

What does a loop look like? the /loop and /goal capabilities you can find in agent harnesses such as Claude Code, Codex and Antigravity are good examples.

/Goal lets you set a completion condition and have the AI keep working across turns until the condition holds: a lightweight autonomous loop without you having to prompt each step. It is a genuinely useful step toward higher-agency AI.

But look at the canonical examples from Anthropic:

• migrate an API until every call site compiles and tests pass
• implement a design doc until all acceptance criteria hold,
• split a large file
• empty a labeled issue backlog.

Reading through this list, something jumped at me. Every single one of these /goals is output-oriented (or you can argue they are activity-oriented)).

Nothing in the example list asks whether a feature was actually adopted, whether a page works well for visitors, or whether a presentation landed with the audience.

When you give AI (and humans…) output-oriented goals, they tend to focus on the output. The result might be a working feature that nobody uses, a page that nobody reads, or a presentation that nobody understands.

To really unlock high-agency AI, we need to set outcome-oriented goals and instrument the system so that the agents can actually measure whether the outcome was reached.

Spec-driven development is a real step up from prompting your way through a change. You write down intent, the agent works against it, and you get something reviewable. But look at what the spec is describing: it is a description of a deliverable. Build this, change that, make these tests pass. The loop terminates when the thing exists.

Goal-based loops move the termination condition. Instead of “produce this artifact,” you give the agent a condition to keep working toward and let it decide what to build. That is a genuinely different instruction, and it is the mechanism that could carry agentic work from a software lifecycle into a product one.

Could, not does. Almost every goal I see in the wild is still a deliverable wearing different clothes: tests pass, backlog empty, coverage above eighty. Those are outputs with a completion check bolted on. The loop got more autonomous without getting any more connected to whether the work mattered, and that gap is the actual subject of this piece.

Anthropic recently shipped a capability called completion goals: you set a target condition with /goal, and Claude keeps working across turns until the condition is met. After each turn, a lightweight model checks whether the condition holds. If it does not, Claude starts another turn instead of returning control to you. No more nudging, re-prompting, or babysitting a multi-step sequence.

Seeking a goal this way is meaningfully different from a one-shot prompt. It is closer to delegating a problem to someone and telling them not to come back until it is done.

This is referred to as Loop Engineering. Engineering effective agentic loops that unleash the power of agents using a core concept in designing complex systems - using tight feedback loops to try, sense, and respond to seek a goal.

In my own agentic workflows for developing and evolving my web presence and delivery capabilities I have been building something similar manually: a Ralph loop script.

This is what these scripts do more or less:

• Run an AI LLM with a prompt
• Evaluate the result against an exit/success condition
• Exit if the condition it met
• Repeat the loop

The /goal feature moves that pattern into the harness itself, which makes it accessible to anyone without custom scripting.

When Anthropic introduces a feature like this, the canonical examples they choose are telling. It’s not a coincidence that all the examples above are technical.

That list is not wrong: those are real, useful things to automate. But look at what is not on the list.

There is no example of “Landing page that converts” No “Feature that users find useful and are willing to pay for” No “Audience that learns something useful that sticks with them and changes their behavior from the presentation” No “Podcast that earns downloads and listens”

In other words, Nothing that ensures we build something that moves the needle.

Those absences are not accidental. They reflect a real constraint: AI agents can close the loop on technical correctness far more easily than they can close the loop on human behavior and value.

Whether tests pass is observable by a machine.

Whether people use a feature, whether a page works for real visitors, whether a talk lands: those require a fundamentally different kind of signal.

This is the core tension. Output is easy to measure inside the system. Outcome lives outside it, in the behavior and experience of the people you were trying to help.

When you set a completion goal around a technical criterion, the agent has clear stopping conditions it can evaluate autonomously and reliably. When you set one around an outcome, you immediately run into the question: how would the agent observe whether that condition holds? The agent can write the code. It cannot measure whether the code moved the metric you care about. It can publish the blog post. It cannot tell you whether anyone read it, thought differently as a result, or took a meaningful next step.

Scaling output production is valuable. But the real goal isn’t activity or even output.

Organizations are looking for business impact. Revenue growth. Improved margins. Reduced Risk.

And pages, features, presentations, live artifacts, don’t necessarily connect to impact. The impact comes from creating leverage - fewer people (and other agents!) able to deliver better value, safer, happier.

Isn’t the answer to simply adopt outcome oriented goals?

Let’s pick on one example from that list - split a large file.

Earlier this week I facilitated a workshop with an AI GTM team, where one of the use cases they were working on involved integrating an AI agent to a huge google sheet that was used by a finance team. Claude Cowork was complaining it cannot work with this google sheet.

So it makes total sense to open a thread with a goal of splitting the large google sheet. But here are some ways this could go wrong:

• The split might still not fix the Claude Code access problem
• The split might make it harder to maintain the integrity of the financial data, or make it harder to maintain the workflow overall.
• Even if Claude Code COULD access the file, it doesn’t necessarily mean it could use/serve the data in it in a useful manner.
• Even if it COULD - it might be the wrong solution approach
• Even if it was the overall right solution approach - it might not move the needle when it comes to behaviors on the finance team.

There are so many assumptions we’re making. (And we know what happens when we ASS-u-Me…)

Asking why several times helped us frame a goal that is closer to the outcome we were really looking for - Enabling the finance team to work with Claude Code to analyze, get insights, and clean up their financial data in a more timely and efficient manner. (Excuse me for staying a bit vague here on purpose when sharing the full real life example…)

But coming up with an outcome-oriented goal isn’t enough. Consider the example above. Shifting towards outcomes increases our alignment to what our users want, what they really really want (or need). But it also makes it much harder for an agent to declare success.

Because measuring outcomes is much harder than measuring outputs or activity.

And as long as agents cannot see whether their actions and outputs are really helping, they cannot close a real feedback loop. The can spend a lot of tokens building tons of stuff, that is beautiful, well designed, works well, but useless.

In the real world, what I often observe when giving an agent an outcome oriented goal without the observability loop, is that rather than running endless turns, they simply stop and hand it back to me, essentially saying “I did what you asked, but I don’t know if it helped. Time for you to figure it out”.

If you want to give AI agents outcome-oriented goals, you need to solve a prior problem: how does the agent know whether the outcome was reached? This means instrumentation. It means closing the feedback loop between what AI produces and whether that production moved the needle. It means building the observability layer that lets a completion condition like “users adopted this feature” or “this content performs” actually be evaluated, not just assumed.

Most organizations do not have that instrumentation today: not for AI outputs, and often not for human outputs either.

We track task completion, story points, PRs merged, tickets closed.

We are much weaker on adoption rates, usage patterns, business metric movement, and the causal chain between what we built and what changed. And even some of the strongest SaaS product companies I’ve worked with that have great telemetry for their product, lack any sort of telemetry when it comes to internal technology.

In my experience, the typical IT team, even in a strong product company, is still often deep in project and feature factory world focusing on outputs or even activity theater.

That’s simply not enough when you’re trying to leverage AI for real impact.

The work of building telemetry and closing the observability loop is not glamorous. It does not feel as exciting as shipping a feature. But it is what separates the organizations that will use agentic AI to drive real impact from those who will use it to drive impressive-looking activity.

You do not need to wait for full observability infrastructure to start reorienting your AI goals. The first move is to ask, for every goal you set: is this a completion condition for an output, or for an outcome? If it is output, is that output reliably connected to the outcome you actually care about, and do you have enough signal to know when it is not?

That question will quickly surface the gaps. It will show you where you are measuring task completion and calling it progress. It will point toward the observability investments worth making. And it will make visible the distinction between AI as an accelerant for activity and AI as a driver of actual impact.

Can your agents only effectively seek output-oriented ‘/goal’ statements right now?

That might be a good place to draw the border between agent autonomy and human responsibility.

Your end to end feature flow might include several segments where AI agents operate autonomously towards output goals (e.g. to build the feature) or even activities (e.g. verify nothing breaks through regression testing) and then return control to humans to help observe outcomes and apply judgement where there isn’t quantitative evidence.

In parallel, build the telemetry and observability systems that will let agentic AI take over more and more of the work in that end to end pipeline, especially at the points where work is currently accumulating.

Prefer audio? Check out the accompanying podcast or directly on Spotify.

The gap between what AI produces and whether it mattered is the next frontier. Build for that one.