How to Use the Hermes /Goal Command to Streamline Your Projects

Most AI assistants are good at answering one prompt. They are less reliable when a task requires several rounds of investigation, execution, testing and correction.

Hermes Agent’s /goal command is designed for that gap. Instead of treating each response as the end of the interaction, it keeps one objective active across multiple turns. After every turn, a lightweight judge model checks whether the latest work satisfies the goal. If it does not, Hermes prompts itself to continue until the objective is reached, the user pauses or clears it, or the permitted turn budget is exhausted.

This makes /goal useful for work that would otherwise require repeated instructions such as “continue”, “test it again” or “finish the remaining items”. It can support coding, research, data processing, audits and other multi-stage tasks, provided the requested outcome can be defined and verified.

The command is less suitable for vague ambitions, sensitive decisions or projects that require frequent human judgement. Hermes can continue working towards an objective, but it still needs a precise description of what completion means.

What /goal actually changes

A normal Hermes prompt produces one agent turn. The model may call several tools during that turn, but once it returns a final response, it stops and waits for the user.

A goal remains active after that response.

When you enter:

/goal Fix every failing test in tests/hermes_cli/ and make sure scripts/run_tests.sh passes for that directory

Hermes begins working immediately. Once the first turn ends, the judge assesses whether the stated objective has been met. If the tests are still failing, Hermes automatically starts another turn. This continues until the tests pass, the goal reaches its turn limit or the process is interrupted.

The default budget is 20 turns, although it can be changed in the configuration. That limit matters because an agent caught in an unproductive loop could otherwise continue consuming tokens, tool time and external service credits.

The system therefore adds persistence, not unlimited autonomy.

Use it for work with a visible finish line

The strongest /goal tasks have three characteristics: they require several steps, Hermes has access to the tools needed to complete them and the result can be tested.

Software work is an obvious example:

/goal Upgrade the project to Python 3.13, update incompatible dependencies, run the full test suite and stop only when all tests pass.

The completion condition is concrete. Hermes can inspect the project, modify files, install or update dependencies and run tests. A passing test suite provides evidence that the main outcome has been achieved.

The same logic can be applied outside coding:

/goal Review every CSV file in the reports folder, identify missing values and duplicate records, produce a cleaned version of each file and create a summary report listing every change.

Or:

/goal Research the five largest European battery manufacturers, verify their latest production-capacity figures from primary sources and produce a comparison table with citations.

These tasks involve several operations but still define an observable output.

A poor goal would be:

/goal Improve my business.

Hermes has no reliable basis for deciding when the business has been improved. It may generate ideas, continue expanding them and eventually stop because the judge interprets a broad response as sufficient.

The problem is not the model’s intelligence. It is the absence of a completion standard.

Write a completion contract

Hermes supports structured completion contracts for goals that need more precision. The official documentation recommends defining five elements: the desired outcome, the method of verification, constraints, boundaries and the condition under which the agent should stop and request input.

You can ask Hermes to draft this structure with:

/goal draft <your objective>

A useful contract might look conceptually like this:

Outcome:
The website builds successfully and the broken checkout form works.

Verification:
Run the production build, execute the checkout tests and confirm that all pass.

Constraints:
Do not change the visual design or remove existing analytics.

Boundaries:
Only modify files in src/checkout, tests/checkout and package configuration.

Stop when:
A payment-provider credential, business decision or destructive database change is required.

This is substantially safer than asking the agent simply to “fix the checkout”.

The outcome tells Hermes what must be true. Verification tells it how to prove the result. Constraints protect parts of the system that should remain unchanged. Boundaries restrict where it should work. The stopping condition prevents the agent from improvising when it reaches a decision that should belong to a person.

The judge can only assess the criteria it has been given. A vague goal produces vague supervision.

Use the control commands

Once a goal is running, several commands help you inspect or control it.

/goal status

shows the active objective, its state and the number of turns used.

/goal show

prints the current completion contract.

/goal pause

stops automatic continuation without deleting the goal.

/goal resume

restarts the loop and resets its turn counter.

/goal clear

removes the goal completely.

Pausing is useful when the agent is moving in the wrong direction or when you want to inspect files before further changes are made. Clearing is more appropriate when the objective itself is no longer valid.

Hermes also supports /subgoal, which adds another criterion to an active goal. The judge will then consider both the original objective and the additional requirement before declaring the work complete.

For example:

/subgoal Add migration notes to the README and confirm that the previous configuration remains backwards-compatible.

This allows a requirement to be added without replacing the project’s main objective.

Steer rather than restart

Longer projects rarely proceed exactly as expected. Hermes includes a /steer command for adding guidance while the agent is working.

/steer Do not replace the authentication library. Investigate the existing configuration first.

The instruction is delivered after the agent’s next tool call without ending the current run or starting a new user turn. This makes it useful when you see Hermes adopting an undesirable approach but do not want to discard the work already completed.

A new ordinary user message can pre-empt the automatic goal loop. This gives the user a way to regain control, but it also means that unrelated conversation can interrupt a running project. For substantial work, keeping the goal in a dedicated session is usually cleaner.

Separate persistent goals from scheduled work

/goal is intended to finish one continuing objective. It is not the right feature for every form of automation.

A goal such as “repair the application and get all tests passing” has a completion point. A request such as “check the website every morning and report downtime” does not. That belongs in a scheduled task.

Hermes includes a cron scheduler for recurring automation, as well as background sessions and subagent delegation for work that should run separately or in parallel. Its broader architecture supports terminal access, messaging platforms, external tools and several model providers.

The distinction is practical:

• Use /goal for a multi-turn objective that should eventually end.
• Use scheduled automation for recurring work.
• Use a background session when you want to continue using the current conversation.
• Use subagents when separate workstreams can proceed in parallel.

Trying to make one goal handle all four patterns usually produces a less controllable workflow.

Do not confuse persistence with judgement

The judge model does not independently inspect reality in the way a human project owner would. It assesses the agent’s work against the goal and the available evidence.

If the agent reports that a task succeeded but did not perform a meaningful test, the judge may accept an incomplete result. This is why verification should name an executable check whenever possible.

Weak:

Verify that the application works correctly.

Stronger:

Run pytest, npm run build and the Playwright checkout tests. The goal is complete only if all commands exit successfully.

For research, verification may require a source standard:

Use company filings, regulators and official statistics. Do not treat press releases or secondary summaries as confirmation of financial figures.

For content production, it may require an output checklist:

Deliver six articles of 800–1,000 words, each with a distinct angle, verified sources, no duplicated sections and a final editorial consistency review.

The more subjective the output, the more important human review becomes. A model can confirm that six articles exist. It is less reliable at determining whether all six are genuinely insightful or appropriate for publication.

Restrict access before increasing autonomy

Hermes can interact with local files, terminals, external services and messaging platforms. The framework is designed to run on local machines, remote servers and several operating environments, and it can use different model providers and toolsets.

That flexibility makes /goal useful, but it increases the cost of a badly specified instruction.

An agent with write access to a repository can alter many files while trying to satisfy a broad objective. One with shell access may install packages or execute scripts. One connected to business systems could act on real information rather than a test environment.

Before setting a persistent goal:

• grant only the permissions needed for the task;
• use a branch, worktree, container or test environment where possible;
• create a snapshot or checkpoint before major changes;
• exclude credentials and production data unless they are genuinely required;
• define actions that require human approval;
• and review diffs, logs and test results before deployment.

Hermes provides filesystem checkpoint and snapshot commands, but recovery tools are not a substitute for limiting access in the first place.

The --yolo option, which skips dangerous-command approval, should not be treated as a routine convenience. It expands what the agent can do without intervention and therefore increases the consequences of an incorrect assumption.

A practical workflow

A reliable /goal project can be organised in five stages.

First, define one outcome. Avoid combining unrelated objectives such as fixing software, writing documentation and designing a new product strategy unless they are genuinely part of the same deliverable.

Second, specify proof. Name the tests, files, reports or checks that establish completion.

Third, establish boundaries. State which directories, systems, accounts or data sources Hermes may use.

Fourth, identify escalation points. Tell the agent to stop when it encounters missing credentials, ambiguous business requirements, destructive operations or decisions with legal, financial or security consequences.

Finally, review the evidence rather than accepting the completion message alone. Open the report, inspect the code changes, reproduce the test and check that the result satisfies the real purpose of the project.

A well-formed command might be:

/goal Upgrade the customer portal dependencies and resolve all resulting compatibility errors.

Outcome:
The portal builds and its existing functions remain operational.

Verification:
Run the unit tests, production build and Playwright smoke tests. All must pass.

Constraints:
Do not change the user interface, database schema or authentication provider.

Boundaries:
Work only in the customer-portal repository.

Stop when:
A production credential, schema migration or change to customer-facing behaviour is required.

This does not guarantee flawless execution. It gives Hermes a sufficiently precise target to work towards without requiring the user to prompt it after every intermediate step.

The value of /goal is not that it manages a project on behalf of an organisation. It removes one specific form of supervision: repeatedly asking an agent to continue.

Used with clear verification, narrow permissions and deliberate stopping conditions, it can turn Hermes from a one-response assistant into a persistent project worker. Used with an ambiguous objective and broad system access, it can simply repeat mistakes for longer.