Goal-Based Development Through Codex /goal

You can tell the AI, “Do this,” and the model will create the answer for the next turn. But if you say, “Take care of me until I finish this goal,” it’s a different story. The longer a goal lasts, the longer the wrong goal can run.

So the key to goal-based development is not the/goalinstruction itself. What matters is what kind of contract you express your goals in, what you see as completion, and where you ask people back.

In Part 1, we summarized the reasons why coding agents should be viewed as runtime. In this second part, we will cover Goal Contract among others.

Key takeaways

• Prompt is a request, and Goal is a goal with execution status.
• Plan Mode is closer to “how to do it,” and Goal Runtime is closer to “what to get done.”
• Long-time operation requiresObjective,Done Criteria,Stop Conditions,Out of Scope,artifact contract.
• The stopping condition is important because the longer a goal is maintained, the longer an incorrect goal can run.
• It is recommended thatgoal.mdbe treated as a first-class runtime state in the development harness.

Prompt, Task, and Goal are different

The most common unit when using AI coding tools is the prompt.

Copy1Please refactor this component.

If it develops a little further, it becomes a task.

Copy1Add validation to the profile modification form and even write a test.

But the goal is different.

Copy1The user profile editing function is reliably added to the product.

The three sentences may seem similar, but their scope is different.

Goals should have a state, not just a statement.

Copy1How far has it progressed so far?2What will be considered complete?3Where should I stop?4What will be the result?

So a goal is more of a task ticket than a prompt.

Signs shown by Codex /goal

[OpenAI Codex CLI 0.128.0 release] (https://github.com/openai/codex/releases/tag/rust-v0.128.0) includes persisted/goalworkflow, app-server API, model tool, runtime continuation, and TUI's create/pause/resume/clear controls.

This change demonstrates a shift away from single request processing to considering long-running goal execution and resumption. OpenAI's [Codex harness article] (https://openai.com/index/unlocking-the-codex-harness/) also describes Codex core as a runtime that manages agent loop and thread persistence.

When converted to a harness perspective, a goal becomes a state flow that goes through creation, execution, abort, resume, and verification.

1. 01Goal creation
2. 02Create Plan
3. 03Task decomposition
4. 04execution
5. 05interruption
6. 06Request for approval
7. 07resumption
8. 08verification
9. 09Organizing deliverables

Here, if the goal is simple text, it is difficult to resume. Conversely, if the goal is structured, the agent can recover what needs to be done even if it stops and restarts.

Copy1{2  "goalId": "profile-update-20260506",3  "objective": "Reliably add user profile editing function",4  "status": "in_progress",5  "doneCriteria": [6    "You can edit your name and introduction",7    "Passes unit test and e2e test",8    "Display failure cases to the user"9  ],10  "stopConditions": [11    "Request approval when DB schema change is required",12    "Only present a plan when authentication logic changes are required"13  ],14  "artifacts": [15    "changed-files",16    "test-result",17    "risk-summary"18  ]19}

Difference between Plan Mode and Goal Runtime

Plan Mode is useful. However, Plan Mode and Goal Runtime are not the same.

A plan is a map. Goal is a task ticket.

A map shows the way. A ticket tells you what needs to be done, where you are, who needs to approve it, and what deliverables are needed.

Basic structure of Goal Contract

It is safer to use the basic formgoal.md, which can be used immediately in practice, as a field contract rather than heading grammar.

Copy1Goal:2Objective:3Stable addition of user profile editing function.4 5Context:6Currently, the settings/profile page can only be viewed.7Users should be able to edit their name and introduction.8 9Done Criteria:10- You can edit the name and introduction.11- Does not break existing API contracts.12- Passes the unit test and e2e test.13- Failure cases are displayed as toast.14- At the end, summarize the changed files and verification commands.15 16Stop Conditions:17- If DB schema changes are necessary, request approval first.18- If authentication logic changes are required, only a pre-implementation plan is presented.19- If external API costs occur, stop and check.20 21Out of Scope:22- Entire design system change23- Authentication flow redesign24- Direct access to production data25 26artifact contract:27- List of changed files28- Core changes29- Verification command executed30- Failed verification and reasons31- Remaining risks

This document may seem long, but it is a very important boundary for agents. EspeciallyStop Conditionsis important. This is because the longer a goal is maintained, the longer incorrect judgments can be made.

How to Write a Done Criteria

Done Criteria is a sentence that defines done.

A bad example is this:

Copy1The profile function is implemented well.

A good example goes like this:

Copy1You can edit your name and introduction in settings/profile.2If saving fails, an error message is displayed to the user.3The pnpm test profile command passes.4Changed files and verification results are summarized at the end.

Done Criteria should be observable whenever possible.

If the completion criteria are clear, the agent's termination conditions will also be clear.

How to Write Stop Conditions

Stop Conditions are conditions under which the agent must stop. This is directly linked to security and operational stability.

Copy1Stop Conditions:2- If DB migration file creation is necessary, request approval first.3- If auth/session logic needs to be modified, only the plan before implementation is presented.4- Stop if access to env file is required5- Stops when an external paid API call is required6- Production distribution commands are prohibited from being executed.

[Copilot coding agent documentation] (https://docs.github.com/en/copilot/concepts/coding-agent/about-copilot-coding-agent) on GitHub describes the risks and mitigations when autonomous agents have code access and push permissions. For example, layers such as permission restrictions, branch restrictions, workflow approval, and human review are needed.

In other words, “writing DON’T to the prompt” isn’t enough. Stop Conditions are both instructions and must be connected to the permission layer.

How to reflect in development harness

In a development harness, it is better to treat goals as runtime state rather than simple files.

The lightweight MVP structure is as follows:

Copy1.agent-runtime/2goals/3profile-update/4goal.md5plan.md6run-ledger.md7artifacts/8changed-files.md9test-result.md10risk-summary.md

If you develop it a little further, you can use SQLite or JSON state together.

Copy1runtime-state.sqlite2- goals3- tasks4- attempts5- artifacts6- approvals7- memory_candidates

You don't need a complicated DB from the beginning. But at least the goal and run ledger must be separated.

Without this distinction, the agent's plans, actions, failures, and results are all mixed up in the conversation.

checklist

Before putting Goal in file or runtime state, you can check the items below first.

Copy1[ ] Is the Objective clear in one sentence?2[ ] Is the Done Criteria observable?3[ ] Do Stop Conditions include hazardous operations?4[ ] Is the Out of Scope clear?5[ ] Is the artifact to be left at the end defined?6[ ] Can the current state be restored upon resumption?7[ ] Are there separate tasks that require human approval?

Standards to be taken in this episode

A Goal is not a long prompt, but a ticket to action. Before entrusting a goal to an agent, you must first separate the Objective, Done Criteria, Stop Conditions, and artifact contract. Without these four, goal-based execution becomes less about automation and more like neglect.

Next time

In Part 3, we move on to a structure where multiple agents work together. The topic is A2A and MCP. MCP is the axis of tool access, and A2A is the axis of task delegation between agents.

Continue reading the series

• Part 1: Why are coding agents runtime?
• Part 2: Goal-based development through Codex/goal
• Part 3: Multi-agent development workflow from A2A and MCP perspective
• Part 4: AI Memory is not RAG
• Part 5: AI Coding Agent Document Set for Application to Development Harness

References

• Release 0.128.0 - openai/codex
• Unlocking the Codex harness: how we built the App Server
• About GitHub Copilot coding agent

Practical Application Example: Target Contract Creates a Stopping Condition

For example, the goal of “improving blog search quality” is too broad. If you change it to a Goal Contract, you will have completion criteria such as "Improve the removal of Korean particles in search term normalization, pass the existing ranking test, and add one new test." This also includes things you won't do. If you write that UI redesign, search engine replacement, and index structure change are outside of this goal, it will be difficult for the agent to expand its scope.

A case of failure is when a long task continues without a goal. The agent tries to fix all the problems found in the middle, and it is difficult for the user to know by what standard it was finished. A Stop Condition is not a declaration of abandonment, but rather a device to safely break off a task. Conditions that the agent cannot solve alone, such as budget, authority, test failure, and external account blocker, must be included in the goal.