How To Give Hermes A Project It Can Actually Finish
Hermes becomes most useful when a task cannot be completed in one response. A software fix may require inspecting several files, changing the implementation, running tests, correcting new failures and checking that nothing else has broken. A research assignment may involve collecting evidence, comparing sources, drafting a report and reviewing whether the original question has been answered properly.
In an ordinary AI conversation, the user often has to manage each step. The assistant produces part of the work, stops and waits. The user checks the result, identifies what is missing and asks it to continue.
Hermes changes that process through the /goal command. The command gives the agent a standing objective that remains active across several turns. Hermes can continue working, assess whether the objective has been met and take the next step without waiting for another prompt after every partial result.
That does not mean the agent should receive a vague instruction and be left alone. The quality of the work depends heavily on how the project is defined. A strong goal tells Hermes what must be true at the end, which part of the project it may change, how completion will be verified and when it should stop for human approval.
When to use the /goal command
The /goal command is designed for work that requires iteration.
It is well suited to debugging, repository maintenance, structured research, document review, file organisation, data cleaning and other projects where the first attempt is unlikely to be the final one.
A normal prompt may be enough when the task can be completed in one clear step. Rewriting a paragraph, explaining a concept or summarising one document does not usually need a persistent goal.
The command becomes more useful when you expect to give several follow-up instructions such as “continue”, “check the remaining files”, “fix the errors” or “run the test again”.
Instead of managing those steps manually, you define the result once and let Hermes work towards it.
A useful distinction is:
- Use a normal prompt when you need an answer.
- Use /goal when you need a completed project.
Describe the result, not the activity
A weak goal tells Hermes what to work on. A strong goal tells Hermes what completion looks like.
“Improve the website” is too broad. The agent does not know which area matters, what improvement means or when it should stop.
A better instruction would be: update the contact form so that valid submissions are stored correctly, invalid email addresses are rejected, the current design remains unchanged and all contact-form tests pass.
The second version gives Hermes a measurable outcome. It also reduces the risk that the agent changes unrelated parts of the website.
This distinction matters in almost every type of project.
“Research our competitors” leaves too many decisions open. A more useful goal would ask Hermes to compare five named competitors across pricing, target audience, product features and positioning, using current public information and identifying any missing data.
“Organise these files” is similarly vague. A stronger version would ask Hermes to sort the image archive by year and month, preserve the original files, place images without usable date information in a separate folder and confirm that the total number of files has not changed.
The goal should describe an end state that another person could verify.
Give the project clear boundaries
A persistent agent can work across several steps, which makes scope control more important.
Hermes should know which files, folders, systems or documents belong to the assignment. It should also know what it must leave untouched.
For a software project, the instruction might limit work to the billing service and its related tests. For a document review, it might specify one folder and prohibit external research. For a website update, it might protect the navigation, analytics settings and production configuration.
Boundaries help in three ways.
First, they prevent the agent from expanding a local task into a wider redesign. Second, they make the final review easier because the user knows where changes should have occurred. Third, they reduce the risk of unnecessary damage to working parts of the project.
A well-defined boundary does not need to be technical. It can be as simple as: work only with the documents in the Q3 research folder and do not use external sources.
The more sensitive the project, the more precise the boundary should be.
Protect what must not change
A project often includes requirements that are easy to damage while solving the main problem.
A software fix may need to preserve the public API, existing file formats or database structure. A content project may need to retain approved claims, legal wording or brand terminology. A file-management task may need to preserve original names and avoid overwriting duplicates.
These constraints should be stated before Hermes begins.
For example, an authentication update could require the agent to preserve the current login behaviour, password-reset process and token format. A report revision could instruct it not to change approved figures or remove regulatory disclaimers.
Without such instructions, the agent may solve the visible problem by changing something the organisation depends on elsewhere.
The goal should therefore include two elements: what must improve and what must remain stable.
Define how the result will be checked
Hermes needs a reliable way to decide whether the work is finished.
In software projects, verification may involve a passing test suite, a successful build, a benchmark result or a sample execution. In research, it may involve covering every required topic, checking each source and identifying unresolved contradictions. In file work, it may involve matching the number of files before and after the operation.
“Make sure everything works” is not a useful completion test.
A stronger instruction would say that the goal is complete only when the relevant tests pass and the build finishes successfully. For a report, the instruction could require every named company to be covered and every factual claim to have a traceable source. For file organisation, it could require confirmation that nothing was deleted or overwritten.
Verification should rely on evidence, not on the agent stating that it is confident.
The final result becomes much easier to review when the standard has been agreed before the work begins.
Tell Hermes when to stop and ask
Autonomy works best when the limits of autonomy are clear.
Some decisions should not be made by the agent without approval. These may include deleting data, changing a public interface, adding a paid service, modifying a production system or choosing between two materially different business options.
A stop condition tells Hermes when to pause and ask for guidance.
For example, the agent could be allowed to fix errors within the existing application architecture but required to stop if the solution needs a database migration. A research agent could continue collecting public evidence but pause when two official sources contradict each other. A file-management task could stop when two files would be written to the same location under the same name.
This allows the agent to work independently through routine steps while preserving human control over consequential decisions.
The goal is not to remove supervision entirely. It is to reserve supervision for the points where judgement is genuinely needed.
Use a completion contract for more complex projects
A simple goal may be enough for a small task. Larger projects benefit from a more structured description.
Hermes can work from a completion contract that sets out the intended outcome, the method of verification, the constraints, the boundaries and the stop conditions.
A product-search project, for example, could define the outcome as reliable results for exact product names, partial names and category terms. Verification could require a set of sample searches to return the expected products. Constraints could protect pricing, checkout and category data. The boundary could limit changes to the search service and related tests. A stop condition could require approval before introducing a new external provider.
This structure is useful because it prevents two common failures.
The first is premature completion, where the agent changes one visible part of the project and assumes the job is finished. The second is uncontrolled expansion, where it starts modifying adjacent systems that were never included in the assignment.
For important work, a completion contract is often worth the few extra minutes it takes to prepare.
Give the agent the evidence it needs
Hermes can only judge progress against the information included in the goal.
Terms such as “better”, “faster”, “cleaner” or “more professional” are too subjective unless they are explained.
“Improve performance” could mean faster response times, lower memory use, reduced infrastructure costs or better handling under heavy traffic. The agent needs to know which one matters.
A more useful instruction would ask Hermes to reduce the processing time of an import script from 12 minutes to below eight minutes on a named sample dataset, while preserving the current output format and keeping memory use below a specified limit.
The same approach works for content.
Instead of asking Hermes to “improve the report”, specify that it should reduce repetition, preserve all verified figures, organise the material around three defined questions and keep the final document within a particular length.
The clearer the standard, the less room there is for the agent to declare success based on its own interpretation.
Monitor the project without managing every turn
The /goal command reduces the need for repeated prompting, but the user can still check and control the work.
Use /goal status to see the active objective and how far the process has progressed. Use /goal show to review the current goal or completion contract. Use /goal pause when the work needs to stop temporarily, and /goal resume when you are ready for Hermes to continue. Use /goal clear when the objective is no longer relevant and should be removed.
Pausing is useful when the project remains valid but the approach needs review. Clearing is more appropriate when the assignment has changed substantially or should be abandoned.
These controls allow the user to supervise at the project level rather than the response level.
You do not need to direct every step. You do need to check whether the project is still moving towards the right outcome.
Redirect the work without starting again
A project may need adjustment after Hermes has begun.
Perhaps the original goal remains correct, but the agent is using an approach you do not want. You may need to prevent a database change, add a missing test or narrow the research sources.
The /steer command can give Hermes a new direction while preserving the active goal. You might tell it not to change the database schema and to find a solution within the application instead.
The /subgoal command can add another completion requirement. For example, you could require tests for empty and malformed input files before the main goal can be considered complete.
These commands are useful because they modify the project without replacing it. The original objective remains in place while the route or acceptance criteria become more precise.
That is preferable to repeatedly interrupting the agent with unrelated instructions that gradually make the project harder to follow.
Avoid wasting turns on long-running processes
Some tasks include builds, test suites, data imports or other processes that take several minutes.
An agent that repeatedly checks whether a background command has finished can consume unnecessary turns and create confusion.
Hermes provides /goal wait for this situation. The command tells the goal process to wait for a named background process to finish before continuing. The user can add a short reason, such as waiting for the integration tests or data import.
Use /goal unwait when the process has been stopped, replaced or no longer matters.
This control is particularly helpful when verification takes longer than the actual change. Hermes can wait for the result instead of repeatedly asking the system whether the process has completed.
Ask for a concise completion report
A multi-step project should end with a result that can be reviewed quickly.
The original goal can instruct Hermes to report what changed, which files were modified, which tests or checks were run, whether they passed and which limitations remain.
For research, the completion report could identify the sources used, areas of agreement, unresolved contradictions and assumptions that still require confirmation.
For file management, it could show how many files were processed, how many were moved successfully, which remained unsorted and whether any duplicates were found.
The report should not repeat the full history of the project. Its purpose is to make the outcome auditable.
When Hermes has worked through many turns, this final summary prevents the user from having to reconstruct the result from the entire conversation.
A practical way to write a Hermes goal
A useful goal can be prepared in seven steps.
1. State the end result
Describe what must be true when the project is complete.
Instead of asking Hermes to review an application, ask it to identify and fix the cause of a specific failure.
2. Identify the scope
Name the files, folders, services or documents included in the work.
3. Protect the constraints
State what must not change, such as a public interface, design, file format or approved wording.
4. Define verification
Specify the tests, checks, comparisons or artifacts that will prove completion.
5. Add a stop condition
Identify the decisions that require human approval.
6. Let Hermes work through the intermediate steps
Check progress with /goal status. Redirect with /steer, add requirements with /subgoal or pause the process when necessary.
7. Review the evidence
Read the final report, inspect the changes and confirm that the agreed verification has been completed.
This process is simple enough for everyday use and precise enough to prevent most avoidable errors.
Common mistakes
The most common mistake is giving Hermes a goal that is too broad. “Improve the application” offers almost unlimited scope and no reliable finishing point.
Another is combining several unrelated assignments into one goal. Fixing tests, redesigning a dashboard, updating dependencies and preparing launch documentation should usually be treated as separate projects. Smaller goals are easier to verify, review and reverse.
Subjective instructions also create problems. “Make it better” or “make it professional” should be replaced with observable requirements.
Omitting verification is another frequent weakness. The agent may complete the visible work while leaving hidden errors behind.
Broad access without boundaries is equally risky. A persistent agent should know exactly where it may work and when it must stop.
The final mistake is using /goal for work that needs only one answer. Persistent iteration requires more time and model usage. It should be reserved for assignments that benefit from repeated execution and checking.
Where the command is most valuable
Software development is the clearest use case because projects often include tests and measurable completion criteria. Hermes can inspect the code, make a change, run the tests, analyse the failures and continue until the agreed result has been reached.
Research can also work well when the sources, questions and required output are clearly defined. The agent can gather evidence, compare it, identify gaps and prepare a final report without waiting for approval after every stage.
Document review is another strong fit. Hermes can examine a folder of contracts, extract renewal dates and termination clauses, identify unreadable sections and produce a consolidated summary.
File organisation benefits from the same persistence. The agent can inspect metadata, sort files, detect conflicts, verify file counts and report anything that could not be processed safely.
The shared feature is not the subject matter. It is the presence of several steps, a clear final state and a reliable way to check the result.
The user still owns the project
The /goal command can manage persistence. It cannot decide whether the project itself is worthwhile.
Hermes may complete the wrong assignment efficiently if the objective is poorly chosen. It can optimise a report nobody reads, automate a process that should be removed or preserve a requirement that no longer serves the organisation.
Human judgement remains most important at the beginning and the end.
The user decides what outcome matters, which trade-offs are acceptable, what the agent may change and which evidence will count as completion. Hermes handles much of the intermediate work. The user then reviews the result and decides whether to accept, revise or reject it.
That division is more useful than the promise of full autonomy. Hermes provides persistence; the project owner retains responsibility.
Turning a conversation into a managed project
The main advantage of /goal is that a multi-step assignment no longer has to be controlled through a long chain of improvised follow-up prompts.
A well-written goal gives Hermes a durable objective, a definition of completion and enough room to correct partial results. Boundaries keep the work inside the intended area. Constraints protect systems and requirements that should remain stable. Verification prevents the process from ending with an unsupported claim. Stop conditions reserve consequential decisions for a person.
The command works best when the destination is already clear.
Define what must be true, how it will be checked and when Hermes should ask for help. The agent can then manage much of the route between the initial instruction and the verified result.
