Hermes /goal: Give the agent a finish line

An agent can explain a bug, suggest a fix, and end its answer while the test is still failing. You wanted working code. It gave you a response. Those are different finish lines.

Hermes /goal is useful for that gap. A normal prompt can finish with an answer. A bounded goal defines the outcome the agent should keep working toward, the evidence you need, and where it must stop. The useful promise is continued effort on a defined task, not unlimited autonomy.

What keeps going

In Hermes, /goal <text> sets a standing objective for the current session and starts the first turn immediately. It is not a place to park an unapproved idea. Write and review the proposed instructions before submitting them.

After a turn, a judge model checks progress. It can return done, continue, blocked, or wait. Continue feeds another prompt into the same conversation. Blocked means the work needs intervention. Wait can park the loop while a background process or a timed wait resolves, rather than keep asking for progress that cannot happen yet.

The default outer goal budget is 20 evaluated turns. That bounds the continuation loop; it is not 20 tool calls or a dollar limit. A single turn can contain substantial work. More turns are not automatically better if the task or its evidence is wrong.[1]

Write the finish line

I would start with four questions: Outcome → Evidence → Constraint → Stop condition. What must be true? What would demonstrate it? What must stay untouched? When should the agent stop and ask me instead of guessing?

Hermes completion contracts give those questions a home. They describe an outcome, verification, constraints, boundaries, and a stop_when condition. My four-part shorthand combines constraints and boundaries: both matter when deciding what the work may change.

“Make the code better” leaves too much room. Better for whom? Faster, clearer, or compatible with an old caller? If you cannot name the evidence, the agent has to invent a standard. A longer run then gives it more time to pursue a result you never agreed on.[2]

One small repair

Here is a hypothetical example, not a report of a completed run. Imagine a disposable local project with Python, pytest, and its dependencies already installed. Its existing slug tests describe the intended behavior, and the slug-formatting function is failing them. Keep credentials and production access out of this test environment.

Outcome: repair the slug-formatting function in src/slug.py so it meets the behavior defined by the existing tests. This is one function repair, not permission to redesign URL handling across the project.

Evidence: run python -m pytest -q tests/test_slug.py and return the actual test result with the local diff. The command should succeed against the repaired file. Saying the tests ought to pass is not evidence that they ran.

Constraint: only modify src/slug.py. Do not modify tests, install dependencies, use the network, commit, push, or touch production. The diff should make that narrow scope easy to inspect.

Stop condition: stop and ask if the repair requires another file, a dependency, or an ambiguous product decision. If two slug formats could both be reasonable, do not choose one just to keep the loop moving.

That last part is important. An agent that stops because the requested repair needs a broader change has respected the assignment. It has not failed by refusing to turn a small fix into a larger project.

Register the check

A test command written in a contract is not an actual quality gate. It tells the agent and judge what evidence to seek. To register that check as a gate on the active goal, use /goal gate add python -m pytest -q tests/test_slug.py. The general command is /goal gate add <command>.

A registered quality gate must exit 0 before the goal can be marked done. That gives the completion decision a mechanical check instead of relying only on the judge reading a confident summary. Review the command and the test code before registering it: a gate executes a shell command, not a harmless label.

Passing that check still proves only what those tests cover. It does not establish that the tests are complete, that no unrelated file changed, or that the result should ship. In this example, changing a test to accept the bug would violate the assignment even if the command returned success.[3]

Keep the boundaries

Contracts guide prompts rather than permissions. Writing “do not touch production” does not remove a production credential or prevent a tool from reaching it. Use actual access controls and an isolated workspace to enforce the boundaries that matter. I would not give a one-file practice repair access to a live service.

The controls are straightforward: /goal status shows the goal and its progress; /goal pause stops automatic continuation without clearing it; /goal resume resumes the loop and resets the turn counter; /goal clear removes the goal. Treat pause as a continuation control, not a guarantee that an already running command has been cancelled.[4]

Persistence needs the same care. Saved goal state does not guarantee execution after the owning process dies. The orphan-goal recovery issue documents a goal remaining active in storage while no live process supplies continuation turns. Do not read a saved “active” label as proof that work is still happening. Check the running session and its actual results.[5]

You accept the result

The judge can be wrong. It can call unfinished work done or keep going after the useful work is complete. Human acceptance remains necessary. For the slug repair, read the diff, inspect the test result, and check that the change stayed inside src/slug.py. Decide whether the behavior is right before accepting it.[6]

I do not want an agent that treats every obstacle as permission to do more. I want one that can keep working inside an agreed boundary and return something I can judge. Define the finish line before starting the loop. Let the agent pursue it; keep the decision to accept the result with the person responsible for it.