Agentic Goal Engineering: First the Right Goal, Then the Agent

Short answer: Agentic Goal Engineering clarifies, before an AI agent starts work, which outcome counts as success. The AI asks for the desired result, poses targeted follow-up questions and derives testable acceptance criteria. Both end up in a Goal Contract (a written goal agreement) approved by a human. Only then do agents plan, build and verify against that contract. A first pilot from October 28, 2026 does not yet show any advantage over Spec Kit or over a model without a method.

As of: October 28, 2026 · Author: Alexander Weipprecht, Provimedia GmbH · Reading time about 35 minutes

What this is about

An agent is asked to make a dashboard faster. At the end there is Lighthouse 100 (the top score in Google's performance measurement) and nothing but green tests, and the figures in the dashboard are an hour old. What was meant was fast and up to date. What was said was only "faster".

No test fails in this case. Coding agents now work independently for hours and improve in loops until a stop condition is met. The industry calls the design of such loops Loop Engineering, and the linking of many loops and agents Graph Engineering. A loop, however, only checks against the condition it was given. Whether that condition matches what the human wanted is something neither discipline notices.

This is where this article comes in. After reading it, you will be able to check a /goal condition (the stop condition in Claude Code) for goal errors, separate an agent's suggestions from your own requirements, and write acceptance criteria that an agent will find harder to reinterpret.

The honest status: Provimedia is currently developing the method as a skill called /goalengine for Claude Code and Code Guardian. A first comparison with 120 dialogues is available, and it turns out unfavorably: against Spec Kit (GitHub's tool for specification-driven development) no advantage is demonstrated, and the same model without a method came closest to the intent. Section 9 shows all the figures. The article therefore describes a well-founded method whose benefit has not yet been demonstrated.

What you can do tomorrow

Five steps you can apply immediately, without a skill and without prior knowledge. They are sorted by strength of evidence: first what the pilot measured, then what is merely reasoned. Where a technical term appears, it is given in parentheses; the later sections explain it.

1. Let the agent ask first. Allow follow-up questions and limit them to about eight, for example with: "Before you start: ask me up to eight questions about how I would measure the result." You do not need a ready-made method template for this. Measured: this arm (the same model, without a method) came closest in the pilot, with 89.4 % of points correct. There was no arm with no follow-up questions at all.
2. Write down who each requirement comes from. Either you said it, or the agent proposed it. Example: "Response time at most 5 seconds (AI proposal, not yet confirmed)". Only when you confirm does it count as a requirement. In the method this label is called AI_PROPOSED. Measured on method B, which uses such labels: 0.2 % wrongly assumed points instead of 4.4 and 6.8 % respectively. The contribution of the label alone has not been isolated.
3. Keep open points visible. Whatever nobody has confirmed is not struck out but noted as open. Example: "Open: How old may the figures be at most? Not yet clarified." A lesson from the pilot.
4. In the /goal condition, describe the state, not the solution. Not: "Add Redis caching." But: "The dashboard loads in at most 1.5 seconds and shows figures that are at most 60 seconds old." That way the agent is free to find the best route itself. One question helps here (section 6): does the answer change what counts as success? Reasoned, not measured.
5. Write success criteria so that someone can verify them. Example: "Given: the dashboard with test data. When: I open it 20 times in a row. Then: every call takes at most 1.5 seconds, and the figures are at most 60 seconds old. How verified: measurement script, raw data saved." This format is called an acceptance criterion (section 7 shows it in full). Reasoned, not measured.

At a glance

Which question is on your mind? The table gives the short answer and the section in which it is substantiated.

1. The problem: An agent can solve the task and miss the goal

First, the question of why agents work past the goal despite green tests. An agent that completes a task flawlessly has not thereby solved its client's problem. The gap between the two is old, but agentic systems widen it. The longer an agent works without asking, the further a wrong assumption from the first prompt carries it.

An example makes this tangible. Someone writes: "The dashboard should get faster." An agent measures the load time, adds a cache, reaches 100 points in the Lighthouse test and reports success.

Afterwards the dashboard shows figures that are an hour old. The agent has met its own test criterion. It has missed the user's goal of quickly seeing current figures. No test was red, and no loop noticed, because every loop checks against the criterion it was given.

This pattern is well documented. Four findings support it:

• DeepMind describes it as specification gaming: behavior "that satisfies the literal specification of an objective without achieving the intended outcome" (Krakovna et al. 2020).
• Anthropic notes in the system card for Claude 3.7 Sonnet: in agentic environments such as Claude Code, the model occasionally builds in special cases to pass test cases. In individual cases it adapts the tests themselves to the output of the code (Anthropic 2025, section 6).
• METR found, in a current model, attempts to trick the evaluation in 39 of 128 runs of a research benchmark (von Arx, Chan and Barnes 2025).
• A study from October 2026 examined whether coding agents can build the agent that a requirement actually calls for. None of the agents tested comes close. Typical are overfitting to visible test cases, hollow runtimes behind code that looks finished, and unsubstantiated completion reports (Wang et al. 2026).

Behind this stands a law that is older than any AI. The economist Charles Goodhart formulated in 1975 that any observed statistical regularity collapses as soon as it is used for control. Marilyn Strathern gave it the form that is quoted today in 1997: "When a measure becomes a target, it ceases to be a good measure" (Strathern 1997).

For agents this means: an agent optimizes whatever has been made measurable. If the wrong thing was made measurable, it reliably optimizes the wrong thing.

On top of that comes a second, quieter source of error: goals shift during the work. Two studies document this:

• Arike and colleagues define goal drift as an agent's tendency to move away from its original goal over time. They demonstrate it in all tested models, to varying degrees (Arike et al. 2025).
• A paper from October 15, 2026 describes the same for multi-agent systems that deviate from the overall goal in the course of execution (Shen et al. 2026).

From both findings follows the starting question of this article: Who makes sure the goal is right before the agents begin, and that it stays the same during the work?

2. Terms: What Loop, Graph and Goal Engineering mean today

The question at the end of the first section presupposes that it is clear who is responsible for what. The terms in this field are young and not standardized. This section fixes the meaning in which the article uses them and substantiates them. How Goal Engineering relates to research is placed in context in section 10.

Agentic Engineering

Agentic Engineering is software development with coding agents that do not merely write code but run, test and further develop it. Simon Willison describes it this way: the agents work independently of step-by-step guidance from their human supervisor (Willison 2026). It is the umbrella term for the following three disciplines.

Loop Engineering

Loop Engineering is the practice of designing agentic workflows, or loops, that guide AI agents iteratively toward user-defined goals with as little human intervention as possible (Belcic and Stryker 2026). This is how IBM defines it.

A study of building blocks and adoption summarizes the shift: developers build systems that prompt the agent for them instead of prompting themselves (Lulla et al. 2026). A post by the developer Peter Steinberger from June 7, 2026 is considered the trigger of the debate. One should no longer prompt coding agents, but design loops that take care of that (Claburn 2026). Who coined the term itself is not documented.

One detail of the definition matters: Loop Engineering works toward user-defined goals. Where this goal comes from and whether it is correct lies outside its area of responsibility.

Graph Engineering

A survey with 35 authors describes Graph Engineering like this: the construction of explicit, dynamic and evolving graph structures that represent tasks, agents and system states (Feng et al. 2026). Nodes are agents, tools, deterministic code, tests or human reviews. Edges are handovers and dependencies.

Practitioners call it connecting several agent loops into an orchestrated system (Bouchard 2026). The term is not standardized and circulates in at least three meanings: as an execution graph, as a graph of loops and controls, and as a knowledge graph. This article uses the first: Graph Engineering organizes who does what in which order.

Goal Engineering: The term is already taken, but differently

The term "Goal Engineering" already exists. Goal Engineering in the sense of Cobus Greyling is the replacement of one-off prompts with verifiable goals that an agent works on until they are met. Greyling ties the term to the /goal command of the Grok Build CLI (Greyling n.d.). All the major coding agents now have comparable commands:

• Claude Code: after each round, a model checks whether the set condition is met; if it is not, Claude starts the next round. Technically, /goal is a session-scoped, prompt-based stop hook. The checker itself does not run any commands and does not read any files. It judges what is in the conversation history (Anthropic n.d.).
• OpenAI Codex: a goal stays permanently attached to a thread, can be paused and resumed, and counts as done only after comparison with concrete evidence. A budget that has been reached expressly does not count as completion (OpenAI n.d.).
• Grok Build: several checking subagents evaluate the result. The goal is reached only when the majority agrees (xAI n.d.).

All three commands answer the same question: Is the condition met? None answers the question before it: Is it the right condition? The text of a /goal condition comes from the human, and its quality decides when the agent stops. A vague condition results in stopping at the wrong time, a wrong condition in stopping at the wrong result.

Agentic Goal Engineering in the sense of this article starts exactly there. It does not work through a goal but identifies, sharpens, checks and preserves it. It supplies the condition that a /goal command later checks, and the yardstick against which every later check must be measured.

Working definition. Agentic Goal Engineering is an AI-assisted methodology with which an AI identifies, sharpens and checks human goals and holds them fixed across the entire implementation. Its result is a solution-neutral, traceable and verifiable Goal Contract that serves as the binding basis for the autonomous achievement of goals by AI agents.

The terms at a glance

The table places the five terms side by side. Each answers a different core question.

3. Delineation: Who answers which question

With the terms in mind, the question arises of which of them takes on which task. Goal, Graph and Loop Engineering are not competitors but different levels of responsibility. Each answers a different question and produces a different artifact. If they are confused, one level answers another level's question, and that is exactly where the errors from section 1 come from.

Two sentences sum up the delineation. A loop can run flawlessly and reach the wrong goal. A graph can be perfectly organized and deliver a result that nobody wanted. Both assume that the goal is sufficiently clear. Agentic Goal Engineering establishes that prerequisite.

From this follows a simple rule of responsibility: Goal Engineering decides on the what, the why and the success. Downstream systems decide on the how, the when and the who. The implementation may report feasibility problems. It may not weaken the Goal Contract.

The depiction is conceptual, not a necessarily linear architecture. Graphs can themselves contain loops, and checks take place during and after execution. What matters is the direction of dependency: every lower level refers to the one above, never the other way round.

4. The methodology: Six steps from a vague wish to an approved contract

Once the level of the goal is delineated, the question is how to proceed there. Agentic Goal Engineering runs in six steps, GE-01 to GE-06. The method is deliberately narrowly scoped: it does not plan, it does not build, and it does not break the goal down into tasks. Its only result is an approved Goal Contract.

What the pilot supports of these building blocks (figures in section 9):

• Supported: the origin labels. Method B wrongly assumed 0.2 % of the points and wrote 2.7 requirements without a basis per document; the other arms 4.4 to 6.8 % and 16.0 to 17.1.
• Refuted in its current form: striking unconfirmed points and the minimum number of questions. B left out 21 % of the points and asked 5.0 questions for clear goals. The best arm at the same time asked the most.
• Not measured: state model, frozen contract, separate verification, drift detection and the effect on the later implementation.

This narrowness is the most important design decision. As soon as the same instance that clarifies the goal also thinks about the solution, the solution begins to shape the goal.

GE-01: Intent Discovery. What should be different, and for whom?

The first step asks about the desired state, about those affected and about the actual problem. In doing so it separates four things that are almost always mixed together in a human formulation: the result, the proposed solution, the context and the assumption.

A user who writes "Add Redis" is formulating a solution. Behind it there may be "reduce response times", just as well as "reduce database costs". Both goals call for different success criteria and possibly different solutions.

Agentic Goal Engineering therefore first notes Redis as a hypothesis. It becomes a binding requirement only if the user expressly sets it as a constraint, for example because the infrastructure is already designed for it.

GE-02: Context and ambiguity analysis

In the second step, the AI checks what is known so far against seven goal dimensions (section 5) and reads the existing project documentation, as far as it influences the meaning of the goal. An existing implementation supplies a baseline, not a target requirement: the fact that a page takes four seconds to load today says nothing about how fast it should load.

Every statement receives an origin label. It is the most important tool against a problem that is easily overlooked in AI-assisted requirements work: AI suggestions that unnoticed look like requirements from the user.

In the pilot: 2.7 binding requirements without a basis per document instead of 16.0 to 17.1 (section 9).

GE-03: Adaptive goal interview

Only now does the AI ask questions, and at most one to three per round. Which questions these are is decided not by a fixed catalog but by the uncertainty model from GE-02. If the goal is already clear, the questions should be dropped altogether. In the pilot: 5.0 questions even for clear goals, not yet delivered on (section 9). Section 6 describes the question logic in detail.

GE-04: Model the Goal Contract

From the intent and the answers, a draft contract is produced. It contains only outcome-related statements and links them in a fixed chain: origin of the intent, decision, requirement (REQ), acceptance criterion (AC) and verification protocol. Section 7 shows this chain in a complete example.

GE-05: Validate the definition

This step checks the definition, not the software. It asks whether the draft reflects the intent faithfully, is complete, free of contradictions and testable, and contains no unjustified solution requirements. If a success-critical clarification is missing, the result is NEEDS_CLARIFICATION, and the flow goes back to the interview. Section 8 describes the verification criteria.

GE-06: Approval and handover

The user sees a concise, complete summary: goal, user group, must criteria, non-goals, limits, verification methods and open points. They approve a specific version. Only then is an immutable file created, for example contract-v001.md. An "looks fine" before the contract has even been shown is not an approval.

Equally important is what the approval does not mean. Whoever approves a goal contract thereby approves neither the implementation nor expenditure nor a deployment. The handover to planning and execution is a separate, explicit step.

5. The seven dimensions of a complete goal definition

The interview (GE-03) needs a yardstick for when a goal is complete. For the AI to recognize where a goal is still unclear, it needs a model of what a complete goal definition consists of. Agentic Goal Engineering uses seven dimensions. They are not a form the user fills in but an internal completeness check.

The AI first enters everything it already knows from the description and the project. It asks only where a decisive gap remains.

The dimensions take up well-known categories of goal-oriented requirements analysis. Goals and their refinement are in Outcome and Observable Behavior, stakeholders and their intentions in Beneficiary (as in i*). Obstacles and invariants are in Boundaries (as in KAOS), conflicting goals in Trade-offs.

New is the dimension Evidence as a duty in its own right: a goal for which no proof is conceivable cannot later be established as reached by anyone, not even by an agent.

During the interview, the AI maintains a state for each dimension. Figure 3 shows this uncertainty model with an example that section 7 develops further.

6. The question logic: How the right questions arise from the outcome

Once the gaps are known, the question remains what the AI then asks. The core of the methodology is the question of which question gets asked. This is where it is decided whether Agentic Goal Engineering sharpens the user's goal or unnoticed replaces it with the AI's solution.

The delineation criterion for every question

A single rule separates goal questions from all others:

A question belongs in goal clarification if its answer changes which outcome counts as successful, and not merely how that outcome is technically achieved.

One exception is important: the user's explicit limits belong in the contract, even if they sound technical. "The existing infrastructure must not be changed" or "We are staying with Qdrant because the rest of the company uses it" are valid constraints. They appear in the contract as a constraint, not as a goal, and never replace the description of the desired outcome.

Discovery questions before precision questions

Agentic Goal Engineering distinguishes two kinds of questions and asks them in a fixed order.

Discovery questions help the user recognize their actual goal. They are open and solution-neutral. Examples: What do you want to achieve in the end? Why is that important to you? What does not work today? What would be different if the problem were completely solved? What would disappoint you even though the software works technically?

Precision questions come only once the intent is understood. They make an already recognized goal quality measurable: What does "fast" mean to you, would five seconds be fine? Should the system say openly when an answer is not sufficiently substantiated?

The order has a reason. Language models tend to propose solutions already during requirements clarification. After five technically flavored questions, a user who originally wanted A suddenly describes B as their goal, because the questions suggested B.

The methodology calls this solution bias. It checks every planned question for whether it presupposes a particular solution or widens the scope of the goal without the user's request. The principle: The AI may help express the user's will more precisely. It may not replace it with its preferred solution.

In the pilot: 0.6 % solution-anticipating questions instead of around 10 % (section 9).

Adaptive Goal Elicitation: asking effectively instead of asking a lot

An interview that asks about every unknown tires the user and dilutes the important questions among unimportant ones. The AI therefore rates every possible follow-up question in advance against five criteria:

1. Impact: How strongly could the answer change the interpretation of the goal?
2. Cost of error: How expensive would a wrong assumption be at this point?
3. Determinability: Can the information be obtained from reliable project sources instead of asking the user?
4. Responsibility: Is it a decision of values or preference that only the human can make, or may the AI make an uncritical suggestion?
5. Information gain: Which question clears up the largest part of the still relevant uncertainty?

From this follows a stopping principle that the methodology calls Minimum Necessary Clarification. The AI asks until all decision-relevant ambiguities are resolved, and no longer.

A missing edge case may be documented as an open point and handled later. An unresolved core requirement must never be silently assumed. If the user gives a complete, clear goal definition from the start, the interview is dropped entirely. A rigid catalog of twenty mandatory questions would then be a mistake, not a quality feature. That is how it is intended; in the pilot, however, the skill still asked 5.0 questions on average for clear goals (section 9).

Five question types

Questions about the database, framework, number of parallel working copies or the distribution of modules among agents, by contrast, do not belong in the goal interview. They are legitimate, but only in planning.

7. A worked example: The AI search for a forum

Up to here it was theory. Now the whole path runs through one example. A user writes: "I want a really good AI search for my forum." The pattern is the same as with the dashboard: a vague wish quickly turns into the wrong solution. This one sentence can be used to show the whole path from wish to testable criterion.

What an ordinary agent would ask

A coding agent without goal clarification typically starts technically: Which vector database? OpenAI or Claude? Should embeddings be cached? Which interface should the search offer? Each of these questions makes sense for the implementation.

Together, however, they silently presuppose that the solution is a semantic search with a vector database. Perhaps the user does not want a hit list at all, but a substantiated answer within seconds from millions of old discussions. That would be a different problem with different success criteria.

What Agentic Goal Engineering asks

In the first round, the Goal Engine asks discovery questions, none of which presupposes a technology:

1. What should a visitor be able to do better after using it than today?
2. Should the search deliver a list of matching discussions or formulate an answer directly?
3. How important is it to you that every statement traces back to specific forum posts?

In the second round, depending on the answer, boundary and precision questions follow: What must on no account happen, even if the search becomes slower as a result? What does "fast" mean to you? By what would you recognize, after launch with real visitors, that the improvement was worthwhile?

The refined goal intent

From the answers, a goal intent emerges that is not yet a technical specification:

"Visitors should receive understandable answers to naturally phrased questions from the existing forum discussions, with traceable sources. If sufficient evidence is lacking, the system should say so openly instead of inventing an answer."

The Goal Contract in three levels

The contract is divided into three levels: the intent (why and what), the requirements (success criteria, limits, exclusions, priorities) and the evidence (verification paths agreed in advance). It is supplemented by the origin of every binding decision and the approval note.

From outcome to acceptance criterion: the origin chain

Every acceptance criterion in the contract must be traceable back to the user's literal intent. Figure 4 shows this using the response time.

The format of the criteria follows the Given-When-Then scheme that Dan North introduced in 2006 for behavior-driven development: an initial state, an event, an observable result (North 2006).

The complete chain reads: origin of the intent → decision → REQ ID → AC ID → verification protocol. It has three practical consequences. A later test or a milestone can refer to an AC ID without rewriting the wording. A requirement without an origin stands out immediately. And whoever wants to change a criterion sees which decision of the user they are touching in doing so.

A criterion in the contract therefore has a fixed form:

AC-03 | Muss | Gegeben: Fragenkatalog v1 (40 Fragen)
       | Wenn: je Frage eine Anfrage über die Suche, 3 Läufe
       | Dann: mindestens 95 % der Antworten in höchstens 5 s
       | Prüfung: Messskript, Rohdaten gesichert
       | Evidenz: Messdatei mit Commit-Bezug
       | Prüfer: Prüfinstanz, nicht der Umsetzer | Status: PENDING

Properties of good requirements

Every requirement in the contract must have six properties. They are modeled on the quality characteristics of individual requirements that ISO/IEC/IEEE 29148:2018 describes in section 5.2.5, including unambiguous, necessary, implementable and verifiable.

Where numbers do not fit

Not every goal can honestly be translated into a number, and the methodology expressly prohibits false precision. Four special cases are covered:

• Subjective quality: "The design should look high-end" does not become an invented Lighthouse value but an agreed acceptance with representative examples and named decision-makers.
• Business goals: "30 percent more revenue" depends on factors outside the software and only shows up over months. The contract therefore separates product acceptance (what the software must deliver) from impact measurement (what is to be observed afterwards). It does not promise a revenue increase.
• Exploratory goals: A valid goal can also be a reliable basis for a decision. The methodology then does not force a product build.
• Multiple stakeholders: If the wishes of different stakeholders contradict each other, the AI puts the conflict on the table. Without a legitimate decision there is no approval.

The same holds: Goal clarity is not a feasibility guarantee. Whether all criteria are achievable technically, economically and within budget is clarified by the downstream planning. If it finds that a criterion is not achievable, the question goes back to the human as a change request.

Applicable today

Usable even without the skill: the steps under "What you can do tomorrow" above. You write the acceptance criterion (AC) in the form from this section: Given (starting situation), When (event), Then (expected result), verification and evidence (how and with what it is proven).

8. How the approach is meant to improve quality

The example shows the flow, but not why it catches errors. This section explains that. Whether it actually works is examined in section 9.

Agentic Goal Engineering does not improve quality by making agents program better. It is meant to catch a class of error that no downstream check can see. And it ties the downstream checks to a yardstick that the agent cannot shift itself. Five mechanisms carry this.

Mechanism 1: Two separate quality checks

Almost every discussion about agents asks whether the AI has reached the goal. Before that comes a second question that is usually skipped: was the goal defined correctly in the first place? These are two different problems, and they need two different checks.

• Check 1: Goal Definition Validation takes place before implementation. It checks whether the goal definition reflects the intent faithfully, is complete, free of contradictions and testable.
• Check 2: Goal Achievement Verification takes place during and after implementation. It uses independent evidence to check whether the agreed goal state has actually been reached.

Check 1 asks nine questions that the draft must pass before it is presented to the user for approval:

Mechanism 2: Five safeguards against proxy optimization

The biggest risk of autonomous agents is that they optimize for their own definition of success. Section 1 showed the dashboard example: Lighthouse 100, outdated data. Against this proxy optimization, the methodology sets five safeguards:

• Intent Preservation: The original, literal intent remains permanently stored and is part of every verification report.
• Goal Freeze: The approved contract is immutable. A change creates a new version; the old one is retained.
• Evidence Separation: The instance that implements and the instance that verifies are separated as far as practicable.
• Goal Drift Detection: Changes to the implementation are regularly checked against the original intent, not only against the tests.
• Human Reapproval: Every substantial change to the goal state, limits or must criteria needs a new approval by the human.

From this follows a sentence that holds for every agentic development environment: A successfully completed loop is no proof of an achieved goal. The loop delivers results and evidence. Whether this evidence supports the approved criteria is judged by an instance that knows the contract and is not responsible for the implementation.

Mechanism 3: Independent verification instead of self-assessment

The separation of implementation and verification is established in software engineering. For its independent verification and validation (IV&V), NASA describes three dimensions of independence: technical, organizational and financial (NASA n.d.).

For language models this principle has a special reason. Panickssery, Bowman and Feng showed that LLM evaluators recognize their own texts and rate them higher than those of others. This self-preference grows with the ability to recognize oneself (Panickssery et al. 2024).

Even early research on LLMs as evaluators named position, length and self-preference effects as limits (Zheng et al. 2023).

In practice this means: an agent that checks its own result against a criterion it formulated itself checks itself twice. Agentic Goal Engineering breaks both. The criterion comes from a contract approved by the human, and a separate instance does the checking.

That is why a /goal command alone is not enough: if its checker reads only the conversation history, it sees the agent's claim, not necessarily the measurement.

Mechanism 4: A state model that separates approval from success

The methodology knows eight states of a goal: DISCOVERING, CLARIFYING, DRAFT, NEEDS_CLARIFICATION, READY_FOR_APPROVAL, APPROVED, SUPERSEDED and CANCELLED.

Two distinctions are decisive here. READY_FOR_APPROVAL only means that the definition is technically verifiable. APPROVED only means that the goal definition is authorized. None of these states means "achieved". Whether the goal is achieved is decided solely by check 2, later and with evidence. The Goal Engine itself must never claim that a goal has been achieved.

Mechanism 5: Freedom of solution for the agent, goal binding for the result

A goal is not a task. "Implement Redis caching for the dashboard" prescribes the solution. "The dashboard is usable within 1.5 seconds with data at most 60 seconds old" describes the state.

In the second case, the agent may find out whether an index, a better query or a leaner frontend achieves more than a cache. The human controls the result. The agent optimizes the path to it.

This very freedom is the reason why agents with good goals can find better solutions than with precise instructions. It is safe, however, only if the result is firmly anchored.

9. Measurement: What the first comparison shows, even against us

So far the method rests on reasoning. Whether it works has to be shown by a measurement. A methodology that promises quality must be measured against its own yardstick. An impressive interview dialogue proves nothing. This section describes three levels of verification: an acceptance catalog for the skill itself, a comparative study against a baseline and an impact measurement in everyday use.

The comparative study has been run as a pilot, and its results are given under level B, including the unfavorable ones. The acceptance catalog and the impact measurement have not yet been run.

Level A: Acceptance catalog for the skill

The acceptance catalog checks whether the skill keeps to its own rules. Each case is an input prompt with expected behavior and a named failure mode that makes the case fail. The 16 cases are also useful as a checklist for your own agent configuration.

The catalog counts as passed if six rules are met:

• There are zero implementation, milestone or task actions.
• No approval occurs without unambiguous consent to one version.
• Every binding requirement has a substantiated origin.
• The skill asks no questions about points that are already clarified or close to implementation.
• Every must criterion is verifiable under defined conditions.
• Approved versions remain unchanged.

Every run is logged with test ID, skill version, input, actual answer, result, observed error and proposed correction. A separate verification instance judges, not the executing AI alone. After every change to the skill, all cases run again.

Level B: Comparison with Spec Kit and with a model without a method

In short: The pilot ran on October 28, 2026: 40 vague goals, three methods, 120 dialogues. The result does not favor our methodology. Against Spec Kit no advantage is demonstrated, and the same model with no method at all came closest to the hidden intent.

The acceptance catalog checks whether the skill keeps its rules. Whether the rules lead to better goal definitions is shown only by a comparison.

Conflict of interest. Provimedia designed arm B and carried out the experiment itself. The design was therefore fixed in writing before the first run and frozen with checksums: all prompts, both halves of the corpus and the evaluation script. The check after all runs showed zero deviations.

Three arms. All ran with the same model (Claude Opus 5.5) in its default settings and with the same framing text:

• Arm A, Spec Kit: the command templates specify and clarify including the specification template, as of commit 222a973f.
• Arm B, Goal Engine: the skill /goalengine as it is shipped.
• Arm C, no method: only the framing text. It shows what the model can do on its own.

The same budget applied to all: at most eight follow-up questions until the finished document. Sub-questions on the same point counted as one. If an arm asked more, the rest went unanswered.

Corpus. 40 scenarios in two halves:

• Half 1 (20 cases) was written by a separate agent with no knowledge of the skill or the metrics. The eight categories, however, were specified by the experimenter, and they coincide with the acceptance catalog of arm B.
• Half 2 (20 cases) was written by a model of a different family (GPT-5.5) with request types of its own choosing. In at least a quarter of them the goal is already clear, so follow-up questions are unnecessary.

Simulated client. GPT-5.5 plays the customer. It knows the hidden intent as a flat list of facts, without any hint as to which facts are decisive. It answers only what is asked and volunteers nothing.

Evaluation. A model converts each final document into a neutral list of requirement, threshold and verification path and removes all traces of the method. Two model evaluators, GPT-5.5 and Claude Opus 5.5, rate independently and without knowing the arm. For every critical ambiguity and every must property, they decide: correctly asked, correctly assumed, wrongly assumed, marked open or missing.

Main metric P is the share of these points that are correct in the final document. None of the three prompts mentions them. The evaluators agreed across 831 points with a Cohen's kappa of 0.82, a measure of agreement without chance hits. The minimum threshold set in advance was 0.6.

Hypotheses were fixed in advance: H1, B hits better than A, and H2, B hits better than C. Testing was done per scenario in pairs, with a one-sided permutation test and Holm correction, plus 95 % confidence intervals by bootstrap, referred to below simply as range. Demonstrated means: the advantage is so large that chance is an unlikely explanation, even after correction for two tests.

Result. Means across all 40 scenarios:

The two hypotheses under test:

• H1, B against A: not demonstrated. In short: B was not demonstrably better than Spec Kit. B was ahead by 5.3 percentage points on average, range −4.4 to +14.6, p = 0.29 after Holm. B was better in 18 scenarios, worse in 14 and equal in 8.
• H2, B against C: not demonstrated, rather the opposite. In short: B was not better than the model without a method, if anything worse. B trailed by 11.1 percentage points, range −17.7 to −4.9. Arm C hit better in 18 scenarios, B in only 7. The one-sided p is 0.999, after Holm likewise 0.999.
• For comparison: Spec Kit trailed the model without a method by 16.3 percentage points (range −23.2 to −9.6). This was only described, not tested.

What the figures say. Arm B is cautious but incomplete. It almost never assumed anything wrong and hardly wrote down any requirements without a basis. It pays the price with gaps: points it did not get confirmed it left out instead of marking them as open.

On top of that comes a tension that concerns the method itself: the best arm asked the most follow-up questions (6.1 per dialogue). The pilot thereby calls into question whether "asking as little as possible" is the right goal.

Counted together across all points and both evaluators, 21 % are missing for B, 23 % for Spec Kit, and only 4 % for the model without a method. This count pools all points and therefore differs slightly from the scenario means in the table. Compared with Spec Kit, B thus has hardly fewer gaps but markedly fewer false assumptions. Compared with the model without a method, B loses mainly through gaps.

Two further findings speak against the skill in its current form:

• Too many questions for clear goals. In the 11 scenarios with a clear or almost clear goal (at most one critical ambiguity; 3 from half 1, 8 from half 2), B asked 5.0 follow-up questions on average, Spec Kit 3.7. Acceptance case GE-T07 expressly demands no superfluous questions there.
• Advantage only on the matching half. On half 1, B hit 88.0 % and was clearly ahead of Spec Kit (70.8 %). On the independently written half 2, B trailed Spec Kit with 68.6 % (75.2 %). The advantage on half 1 may stem from its categories matching B's acceptance catalog.

What we are changing as a result. The skill must flag unconfirmed points as open instead of striking them. And it must recognize a clear goal and then refrain from asking questions. The revised version will be measured on a new corpus frozen in advance, so that it is not tailored to the known cases.

What you take away from this.

The steps are given above under "What you can do tomorrow". The figures behind them: in the pilot, the same model without a method template, with the same follow-up budget, beat both methods. The measured advantage of B lies in origin and assumptions: wrongly assumed 0.2 % against 4.4 % (C) and 6.8 % (A), binding requirements without a basis 2.7 against 16.0 and 17.1 per document.

Limits of this pilot. Six restrictions apply to all the figures above:

• Simulated client: A language model answers more patiently and consistently than a human. A sample with real people is missing in the pilot.
• Model evaluators: Two models did the rating, not humans. One comes from the same family as the arms, which can reinforce preferences (Panickssery et al. 2024).
• One model, one run: All arms ran with a single model, once per scenario. The pilot says nothing about other models.
• Size: 40 scenarios reliably detect only medium effects. A small advantage of B over Spec Kit is thus neither demonstrated nor ruled out.
• Only the goal definition: What is measured is how well the document hits the intent, not whether the later implementation becomes better.
• Deviation in Spec Kit: Arm A named file paths even though there were no files in the experiment. It performed no action in doing so. This was recorded, not corrected.

Prompts, corpus, all 120 transcripts, the ratings and the evaluation script are archived with checksums.

Level C: Impact measurement in everyday use

The last question is the most important and the hardest: in real projects, is less output reworked because the goal was misunderstood? For this, Provimedia records two quantities for real tasks in Code Guardian before and after the introduction of the skill.

First: how often a task reported as finished comes back because it missed the goal. Second: how many change requests to the goal arise during implementation.

This measurement is the only one that shows the actual benefit, and it has the weakest control, because tasks never repeat exactly. It complements the study but does not replace it.

10. State of research and context: Goal-oriented requirements analysis has existed for over 30 years

After our own measurement, the question remains where the method stands in relation to existing research and tools.

The idea of thinking about software starting from human goals rather than from functions is not new. It is called Goal-Oriented Requirements Engineering (GORE). Whoever sells Agentic Goal Engineering as an invention overlooks this tradition. Whoever knows it can build on it.

Axel van Lamsweerde defines a goal as a purpose that the system under consideration is to achieve. Goals provide a precise criterion for when a requirements specification is sufficiently complete (van Lamsweerde 2001). The best-known methods in the field are:

• KAOS (Dardenne, van Lamsweerde and Fickas 1993) refines goals step by step down to requirements and models obstacles.
• i* (Yu 1997) maps the intentions and dependencies of stakeholders.
• Tropos (Bresciani et al. 2004) transfers these ideas to agent-oriented software development.

A systematic mapping of GORE research exists in two versions:

• 2019: The mapping of 246 highly cited GORE papers showed a sobering picture. There were many new ideas with few citations and a small number of papers that dominate the field (Horkoff et al. 2019).
• October 12, 2026: The update finds that 85 percent of citations have arisen since 2020. It expressly addresses the challenges and opportunities of GORE in the age of agentic AI, namely monitoring, capturing and steering agentic systems (Horkoff et al. 2026).

In parallel, research on code generation shows that follow-up questions measurably help:

• ClarifyGPT has a model ask targeted follow-up questions when requirements are unclear. The success rate (Pass@1) of GPT-4 rose from 70.96 to 80.80 percent on the MBPP-sanitized benchmark (Mu et al. 2023).
• HumanEvalComm deliberately alters task descriptions through contradictions, ambiguity and incompleteness. It tests whether models ask questions instead of simply generating code (Wu and Fard 2025).

Both studies, however, measure whether the code is correct afterwards, and work with small, self-contained tasks. Whether the follow-up questions capture a human's goal correctly, they do not measure.

The third point of comparison is Spec-Driven Development. With Spec Kit, GitHub describes a flow in which the human first describes what is to be built and why. Plan, tasks and implementation follow. The specification becomes the authoritative source of what is built (Delimarsky 2025).

A later command clarify looks for underspecified places in the specification and asks up to five targeted questions about them (GitHub n.d.).

Spec Kit is the closest relative of the approach described here and a comparison to be taken seriously. The difference lies in the order and in the subject. Spec Kit clarifies a feature specification, that is, functions that have already been chosen. Agentic Goal Engineering clarifies the desired state before it is decided which function is to produce it, and holds it fixed as a yardstick for verification throughout the implementation.

The assessment is thus sober: Agentic Goal Engineering does not invent goal-oriented requirements analysis. What is new is its implementation as an AI-assisted, dialogue-based and permanently verifiable steering process for autonomous coding agents.

What this means for you: If you use Spec Kit, put goal clarification before it and start the specification only with an approved Goal Contract.

11. Limits of the methodology

Finally, the question of where the method itself reaches its limits. Agentic Goal Engineering does not solve every problem, and it creates risks of its own. Five limits belong in an honest account.

• The first comparison does not favor the methodology. In the pilot with 120 dialogues no advantage over Spec Kit is demonstrated, and a model without a method hit the intent better. The methodology is well founded; its benefit is not.
• An interview takes time. For small, unambiguous tasks it is superfluous. The methodology must recognize when it is not needed, otherwise it becomes a ceremony.
• Prompt rules are not a hard limit. The fact that the skill does not program is stated in its instructions. A technically enforced read block on production code additionally needs permissions, hooks or a sandbox in Claude Code.
• The human remains the source. If the client does not know what they want, no methodology can ask it into existence. It can, however, make visible that this is the case, and propose an exploratory goal.
• The terms are young. Loop and Graph Engineering are not standardized, and "Goal Engineering" is already used in a different meaning. The delineation in this article is a proposal, not a standard.

12. Conclusion: First engineer the goal, then the solution

What remains after method, example and measurement? Agents have become good at meeting conditions. Loop Engineering lets them iterate until a condition holds. Graph Engineering distributes the work across many agents. /goal commands keep them running until a checker agrees. All of this becomes more effective the more precisely the condition is right, and more dangerous the less it is.

Agentic Goal Engineering makes the condition a subject of work in its own right. Three principles sum it up:

• It is not a planning method. It fixes the state that is to be reached. Solution search and planning begin afterwards.
• It is not a questionnaire. The AI is meant to understand the intent, recognize the decisive gaps and close them with as few, well-chosen questions as possible; in the pilot this is not yet delivered, and the best arm even asked the most.
• It is not a one-off prompt optimization. The approved contract remains the yardstick throughout the entire development. Agents may change their path, but not unilaterally decide that a different result counts as success.

The guiding principle reads: First engineer the goal. Then engineer the solution. Construct the goal first, then the solution.

Our first own comparison calls for modesty. A method that avoids false assumptions but leaves gaps is not yet a better method. We consider the principles right; that the skill implements them better than a model without a method, it still has to show.

Provimedia is currently developing the skill /goalengine as a first building block for Code Guardian, initially as a pure goal definition without execution. If you use agents in your own projects and need support, you will find our offering at AI development and agents.

Frequently asked questions

For reference, the questions readers ask most often.

What is Agentic Goal Engineering?

Agentic Goal Engineering is a preparatory step for coding agents: an AI questions the client until it is clear how success can be recognized. The result is a written, approved contract with verifiable criteria and no technology requirements. It is meant to prevent agents from optimizing a loosely worded goal, and later serves as the yardstick for verification.

How does Goal Engineering differ from Loop Engineering?

A loop only checks against the condition it receives. An agent makes a dashboard fast with a cache, Lighthouse shows 100 points, all tests are green, and the figures are an hour old regardless. The loop ran flawlessly; the goal was a different one. Goal Engineering checks up front whether the condition matches the human's intent.

How does Goal Engineering differ from Graph Engineering?

Graph Engineering organizes which agent does which work in which order and how results are handed over. Goal Engineering does not decide on agents, sequences or working copies. It supplies the graph with the yardstick to which every task refers via its AC ID.

Isn't the /goal command in Claude Code enough?

The /goal command lets Claude keep working until a checking model considers the set condition met. It checks whether the condition holds, not whether it is right. According to the documentation, the checker also runs no commands and reads no files. Goal Engineering supplies the verified condition and the yardstick for an independent evidence check.

Isn't this the same as Spec-Driven Development?

No. Goal Engineering is the step before it, and the two can be combined: first clarify the goal, then write the specification. The specification describes functions, the Goal Contract the state that these functions are meant to produce. Goal Engineering supplies beforehand the approved goal state together with acceptance criteria and gives specification, plan and tasks a verifiable yardstick.

How many follow-up questions does the AI ask?

At most one to three per round and only as many as it takes until all decision-relevant ambiguities are resolved. If the goal is clear from the start, the questions are dropped entirely. That is how it is intended, but in the pilot the skill still asked 5.0 questions on average for clear goals (section 9), and the model without a method asked 6.1 times on average and hit best. Every possible question is rated beforehand by how strongly its answer changes the goal and how expensive a wrong assumption would be.

Who approves the Goal Contract, and what does the approval mean?

Only the authorized human may approve, and only a specific, displayed version. A mere "looks fine" before the contract is displayed does not count. The approval authorizes the goal definition, not the implementation, not expenditure and not a deployment. Later changes create a new version, which must be approved again.

Is it proven that the methodology delivers better results?

No. In the first comparison on October 28, 2026 with 40 scenarios, 120 dialogues, a simulated client and two model evaluators, the Goal Engine hit 78 % of the decisive points, Spec Kit 73 % and the same model without a method 89 %. The advantage over Spec Kit is not statistically demonstrated. The Goal Engine almost never assumed anything wrong, but left out more points.

Sources

• Anthropic (2025): Claude 3.7 Sonnet System Card, section 6 "Excessive Focus on Passing Tests".
• Anthropic (n.d.): Claude Code documentation: /goal. Retrieved on Oct 28, 2026.
• Arike, R.; Donoway, E.; Bartsch, H.; Hobbhahn, M. (2025): Technical Report: Evaluating Goal Drift in Language Model Agents. arXiv:2505.02709.
• Belcic, I.; Stryker, C. (2026): What is loop engineering? IBM Think, Jul 17, 2026.
• Bouchard, L.-F. (2026): Graph Engineering vs Loop Engineering: What Actually Changed, Jul 22, 2026.
• Bresciani, P.; Perini, A.; Giorgini, P.; Giunchiglia, F.; Mylopoulos, J. (2004): Tropos: An Agent-Oriented Software Development Methodology. Autonomous Agents and Multi-Agent Systems 8, pp. 203–236. doi:10.1023/B:AGNT.0000018806.20944.ef
• Claburn, T. (2026): Report on Loop Engineering. The Register, Jun 24, 2026.
• Dardenne, A.; van Lamsweerde, A.; Fickas, S. (1993): Goal-directed requirements acquisition. Science of Computer Programming 20(1–2), pp. 3–50. doi:10.1016/0167-6423(93)90021-G
• Delimarsky, D. (2025): Spec-driven development with AI: Get started with a new open source toolkit. GitHub Blog, Sep 2, 2025.
• Feng et al. (2026): Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence. arXiv:2608.21156.
• GitHub (n.d.): Spec Kit, command template clarify. Retrieved on Oct 28, 2026.
• Goodhart, C. A. E. (1975): Problems of Monetary Management: The U.K. Experience. Papers in Monetary Economics, Vol. I, Reserve Bank of Australia.
• Greyling, C. (n.d.): goal-engineering. GitHub repository. Retrieved on Oct 28, 2026.
• Horkoff, J. et al. (2019): Goal-oriented requirements engineering: an extended systematic mapping study. Requirements Engineering 24(2), pp. 133–160. doi:10.1007/s00766-017-0280-z
• Horkoff, J. et al. (2026): A systematic mapping of goal-oriented requirements engineering: reflections, impact, and the way forward. Requirements Engineering 31, Art. 20. doi:10.1007/s00766-026-00476-7
• ISO/IEC/IEEE 29148:2018: Systems and software engineering – Life cycle processes – Requirements engineering, section 5.2.5.
• Krakovna, V. et al. (2020): Specification gaming: the flip side of AI ingenuity. Google DeepMind, Apr 21, 2020.
• Lulla, Nersesyan, Mohsenimofidi, Treude, Baltes (2026): Loop Engineering: Building Blocks, Adoption, and Impact. arXiv:2608.21884.
• Mu, F. et al. (2023): ClarifyGPT: Empowering LLM-based Code Generation with Intention Clarification. arXiv:2310.10996.
• NASA (n.d.): Independent Verification and Validation: Overview. Retrieved on Oct 28, 2026.
• North, D. (2006): Introducing BDD. Better Software, March 2006.
• OpenAI (n.d.): Using goals in Codex. OpenAI Cookbook. Retrieved on Oct 28, 2026.
• Panickssery, A.; Bowman, S. R.; Feng, S. (2024): LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076.
• Shen, L. et al. (2026): Learning to Steer LLM Agents and Multi-Agent Systems. arXiv:2610.22316.
• Strathern, M. (1997): "Improving ratings": audit in the British University system. European Review 5(3), pp. 305–321.
• van Lamsweerde, A. (2001): Goal-Oriented Requirements Engineering: A Guided Tour. Proceedings RE'01, pp. 249–262. doi:10.1109/ISRE.2001.948567
• von Arx, S.; Chan, L.; Barnes, B. (2025): Recent Frontier Models Are Reward Hacking. METR, Jun 5, 2025.
• Wang, J.; Qian, H.; Hu, Y.; Zhang, J.; Liu, Z. (2026): AgentSWE: Can Coding Agents Build the Agent You Actually Want? arXiv:2610.13361.
• Willison, S. (2026): Agentic Engineering Patterns, Feb 23, 2026.
• Wu, J. J.; Fard, F. H. (2025): HumanEvalComm: Benchmarking the Communication Competence of Code Generation for LLMs and LLM Agent. ACM TOSEM. doi:10.1145/3715109
• xAI (n.d.): Grok Build: Modes and Commands. Retrieved on Oct 28, 2026.
• Yu, E. S. K. (1997): Towards modelling and reasoning support for early-phase requirements engineering. Proceedings ISRE '97, pp. 226–235. doi:10.1109/ISRE.1997.566873
• Zheng, L. et al. (2023): Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks. arXiv:2306.05685.

Note: This article describes a methodology under development, its verification plan and the results of a first pilot with a simulated client. It contains no performance promise for individual tools. All statements about third-party products reflect their public documentation as of Oct 28, 2026.