The interface is changing

Claude Code’s /goal command lets a developer set a completion condition and then keep working across turns until a smaller model decides the condition has been met. The shift it points at is bigger than the feature itself.

Prompt-based coding
One turn at a time
Human prompt ↓ AI response ↓ Human review ↓ Next prompt
Objective-driven coding
One goal, many turns
Human goal ↓ Agent loop ↓ Verifier ↓ Continue or stop

The unit of work is no longer the prompt. It is the objective. The developer defines what done looks like and the agent decides which intermediate moves to make. Review collapses from every turn to every loop.

Programming is becoming search

Andrej Karpathy’s AutoResearch is the cleanest example of this pattern outside of editors. The agent proposes a change, edits code, runs a short experiment, measures the result, keeps or reverts, and repeats. It is not a chatbot. It is a search loop with code as the move set and a metric as the fitness function.

The developer is no longer directly writing every candidate solution. The developer defines the search space, the success condition, and the evaluation loop. That is a different job than what prompt engineering describes.

The general shape of the new loop:

  1. Objective. A measurable goal or completion condition.
  2. Candidate change. Agent edits code, config, or schema.
  3. Execution. Run tests, benchmark, or experiment.
  4. Measurement. Did the metric improve?
  5. Decision. Keep, revert, or retry, and loop.

Once coding becomes search, the agent stops being a junior engineer that needs instruction and starts being an optimizer that needs constraints. That distinction matters.

Shopify shows this is not just research

Shopify’s engineering team generalized AutoResearch beyond model training and used it to improve more than 40 metrics across the company. That is the proof point that turns the pattern from interesting research toy into mainstream engineering practice.

Once a team can give an agent a metric and a loop, “make this faster,” “reduce memory usage,” “improve conversion,” or “fix all failing tests” becomes an executable instruction. That is powerful. It is also dangerous if the metric is the only thing the agent is optimizing for.

Goal-driven agents optimize for what they can measure. Architectural intent is usually not measurable unless it has been made explicit, retrievable, and enforceable.

Metrics are not architecture

This is where the model breaks down without an additional layer. A loop that scores itself only against tests and metrics can pass while quietly violating things the team cares about:

  • A test suite can pass while architectural boundaries are violated.
  • A benchmark can improve while the agent introduces an unwanted dependency.
  • A performance metric can improve while maintainability degrades.
  • A goal can be completed while the implementation contradicts an ADR.

None of these are bugs in the loop. They are limits of what the loop knows to check. The verifier confirms that the objective was reached. It does not confirm that the agent stayed inside the architecture while reaching it.

The enterprise layer: this is not just a developer-tool shift

IBM’s 2026 CEO study reports that 76% of surveyed organizations now have a Chief AI Officer, up from 26% in 2025, and that 64% of CEOs say they are comfortable making major strategic decisions based on AI-generated input. The broader framing in the report is that AI is forcing companies to redesign decision-making and authority structures.

Software engineering is experiencing the same operating-model shift earlier and more visibly. Coding agents are becoming delegated decision-makers inside the SDLC. The governance question is the same at both levels: when an autonomous system can pursue a goal on its own, what constraints must it obey while pursuing it, and how are those constraints enforced rather than hoped for?

The missing layer: governance before generation

The full stack of a goal-driven agent is not just “goal plus model.” It has five distinguishable layers, and most current tooling addresses only the first four.

Goal
What to achieve — the objective or completion condition the agent is pursuing.
Metric
How to measure it — the signal the loop uses to judge progress.
Loop
How to keep trying — the agent runtime that proposes, edits, and retries.
Verifier
How to check success — tests, benchmarks, or a smaller model judging completion.
Governance
What must remain true — the architectural, dependency, and policy constraints the agent is not allowed to violate while searching.

Without governance, the loop only knows whether it got closer to the goal. It does not know whether it crossed a boundary the organization cares about. Tests and metrics describe outcomes. Governance describes the parts of the system that are not in scope for the agent to change in the first place.

A governed objective loop is an agent workflow where a goal, metric, and verifier drive autonomous execution, while architectural constraints define what the agent is allowed to change along the way.

The governed execution stack

Drawn as a pipeline, the layers look like this. The agent loop and the verifier do not change; governance is the additional checkpoint between the loop’s output and the surfaces it would otherwise write to unchallenged.

Layer 01 Human goal Objective, metric, completion condition.
↓
Layer 02 Goal runtime / orchestration /goal, AutoResearch, managed agents — the harness driving the loop.
↓
Layer 03 Agent execution loop Propose, edit, run, measure, keep or revert — the search itself.
↓
Layer 04 Mneme governance checkpoints Pre-tool hook, pre-commit, CI gate, PR check — deterministic verdicts with provenance.
↓
Layer 05 Code / CI / PR / deployment The execution surfaces the loop writes to once governance allows the change through.

The same stack reads three different ways depending on which question you are asking. Mneme sits on the right-hand side of each axis.

Axis 01
explorationvsinvariant
Axis 02
optimizationvsgovernance
Axis 03
executionvsverification

The orchestration and execution layers above Mneme are the exploration / optimization / execution side. They are where most current investment is going, and they are improving fast. Mneme’s scope is the invariant / governance / verification side — the layer that decides whether what was explored is allowed to land.

Where Mneme fits

Mneme is the architectural constraint layer for governed objective loops. It turns ADRs, dependency rules, scope boundaries, and governance decisions into retrievable, machine-evaluable constraints that an agent receives before it generates a candidate change, and that CI can check after the change lands.

That means a goal-driven agent does not only receive the task. It receives the architectural context for the task: which abstractions it must go through, which dependencies are out of bounds, which ADRs the area it is touching is already pinned to.

Concrete examples of the same goal, governed differently:

Goal Improve checkout performance.
Governance: do not bypass the payment abstraction; no direct Stripe calls outside the payments module; do not weaken idempotency guarantees.
Goal Migrate the orders service.
Governance: use the repository pattern; no imports from the deprecated internal SDK; preserve ADR-007 service-boundary rules.
Goal Fix all failing tests.
Governance: do not delete coverage; do not weaken validation paths; do not bypass ADR-005 (input sanitization).

The loop still does the search. The verifier still decides whether the goal was met. Governance constrains the search space so the goal cannot be reached by violating something the team has already decided.

Worked example: the goal succeeds, the architecture fails

The failure mode that motivates governance is not the agent missing the goal. It is the agent hitting the goal in a way that quietly contradicts a decision the team has already made. A concrete walkthrough:

Scenario
“Improve checkout p95 latency by 30%”
Goal
Objective set
Human delegates: drop checkout p95 from 480ms to under 340ms. Verifier: latency benchmark + existing test suite.
Loop
Agent searches the solution space
Several candidate changes are tried and reverted. The loop settles on a change that calls Stripe directly from CheckoutService, bypassing the Payments module to skip a layer of validation.
Verifier
Goal met — tests pass, p95 drops 35%
The verifier returns success. Without an additional layer, this change would now land. The architecture has silently degraded: ADR-007 ("all payment integrations go through the Payments module") was violated to hit the metric.
Mneme
Pre-commit hook + CI gate — BLOCK
Mneme retrieves the constraints scoped to checkout/ and payments/, evaluates the diff, returns a deterministic verdict: FAIL · ADR-007 violated: direct Stripe import outside payments module. The verdict links back to the source ADR. The change does not land.
Loop
Search resumes inside the governed space
With the blocked path removed from the search, the agent loop picks a different candidate — connection pooling and a batched validation cache inside the Payments module — that hits the latency goal without violating any ADR.
What changed: the verifier still decided whether the goal was met. Mneme did not slow the loop, did not own the agent runtime, and did not replace the test suite. It returned one additional verdict at one additional checkpoint — deterministic, scoped, and traceable to the originating decision — and that was enough to keep the system inside its own architecture.

Glossary

Goal
The desired outcome the agent is pursuing.
Metric
The measurable signal used to judge progress.
Verifier
The mechanism that decides whether the goal has been met — tests, benchmarks, or a judging model.
Governance
The architectural, security, dependency, and policy constraints that must remain true while the agent works.
Drift
The gap between intended architecture and actual implementation, accumulated as agents make locally plausible choices the system never sanctioned.
Governed objective loop
An agent workflow where a goal drives autonomous execution and architectural constraints bound what the agent is allowed to change while pursuing it.

Closing

The next programming model is not prompt engineering. It is objective design. Developers define goals. Agents explore solutions. Verifiers measure outcomes. But teams still need a way to preserve architectural intent while the loop runs.

Goal-driven agents make software faster. Architectural governance keeps that speed from becoming drift.

Frequently asked questions

What is a goal-driven agent?+
A goal-driven agent is an AI coding agent that is given a completion condition or measurable objective rather than a single prompt, and then keeps proposing changes, running code, and checking results until the objective is met or abandoned. Claude Code’s /goal command, Karpathy’s AutoResearch, and Shopify’s metric-driven engineering loops are examples of this pattern at different levels.
Why aren’t tests enough for goal-driven agents?+
Tests verify behavioral outcomes — that the code does the thing it is supposed to do. They do not generally encode architectural intent: which abstractions must be respected, which dependencies are out of bounds, which ADRs the touched area is pinned to. A loop can satisfy the test suite and still violate the architectural rules the team relies on, because those rules were never expressed as something the verifier checks.
What is a governed objective loop?+
A governed objective loop is a goal-driven agent workflow with architectural governance bolted into the same loop as the goal, metric, and verifier. The agent still pursues an objective autonomously, but the candidate changes it can propose are constrained by retrievable architectural rules — ADRs, dependency boundaries, scope policies — not only by the verifier’s pass/fail signal at the end.
How is this different from prompt engineering or memory?+
Prompt engineering tunes a single instruction. Memory persists recall across turns and sessions. Neither is a constraint layer: a model can have perfect recall of a rule and still ignore it under optimization pressure. Governance is the layer that turns architectural intent into machine-evaluable constraints that retrieve before generation and enforce during execution, so the constraint is part of the loop, not part of the model’s discretion.