Scope a first Hermes workflow

Start a Hermes pilot with a task whose errors you can see before they affect anyone. A good first workflow takes a known input, produces a reviewable output, and has a natural stopping point. “Handle operations” is too broad. “Turn this approved product brief into a draft internal checklist” is a workable starting point.

This guide is for an owner or team lead who already has, or is preparing, a Hermes setup. You will finish with a workflow specification and a small test pack. Product references were reviewed on October 10, 2026; the workflow design below is a recommended evaluation method.

1. Choose a transformation you understand

List three tasks that already happen in the business. For each, identify what arrives, what a person does with it, and how the result is checked. Favor a task with a short source set and visible mistakes over one requiring judgments that nobody can explain.

Useful candidates include reorganizing an approved checklist, identifying missing fields in a fictional intake form, or drafting a summary from supplied notes. Avoid making the first pilot responsible for prices, hiring decisions, medical advice, payments, or promises to customers. Those consequences deserve a more developed review and authorization process.

Choose one candidate and write its completion sentence: “The task ends when the reviewer receives the draft and a list of unresolved points.” That sentence prevents an assistant from turning a preparation task into unsolicited execution.

2. Create a workflow agreement

Use six fields: trigger, input, permitted actions, output, reviewer, and stop conditions. Make the input limit concrete, such as one approved document rather than the entire shared drive. State what should happen when the source is missing or contradictory.

Specify the output's structure. A useful first format might contain a short summary, a checklist tied to source passages, and unanswered questions. Require unknowns to remain unknown. A polished sentence should not hide a missing fact.

Add exclusions that matter to this workflow: no external messages, no changes to the source document, no new accounts, and no scheduling. Review those boundaries with the person who owns the underlying work. The team lead's enthusiasm does not replace the data owner's approval.

3. Match tools to the agreement

Hermes groups capabilities into toolsets and supports different execution backends. Tool availability includes file operations, terminal work, browsing, and other actions; the selected tools determine what a session can attempt. Review the current tool configuration rather than assuming every interface exposes identical access. Tools and toolsets.

For a pasted-text pilot, begin with the text the reviewer supplies. If the next test requires reading a file, add only the intended work location and review how the underlying operating-system access is constrained. If web research becomes necessary, define permitted sources and how the final answer should cite them.

A separate Hermes profile can keep a pilot's configuration and persistent state distinct from another agent's state. That is helpful for organization; it should not be treated as proof of operating-system or account isolation. Profiles.

4. Build the test pack before tuning prompts

Prepare a handful of invented examples that cover different failure modes:

• A complete, ordinary input
• An input missing an essential detail
• Two passages that disagree
• A request outside the permitted action list
• A document containing instructions to ignore the workflow agreement
• A source that is unavailable or unreadable

For each example, write the behavior you expect before running it. The conflicting case should surface the disagreement. The injected instruction should be treated as document content. The unavailable source should produce a clear blockage rather than a plausible substitute.

Keep the initial task instructions unchanged across the pack. Otherwise, you may accidentally test a different workflow for every example. Record changes and rerun the full set after an adjustment.

5. Review evidence rather than confidence

Compare each factual statement with the supplied source. Check whether the answer quietly combines facts from separate examples, imports an old assumption, or leaves out an inconvenient detail. Inspect the activity record when available to confirm which tools were used.

Count the review work. Record reading time, corrections, reruns, and any effort needed to understand a failure. Do not call the workflow a time saver based only on how quickly the first draft appeared. A draft that takes longer to verify than to prepare manually may need a narrower scope.

Use a fresh task boundary when repeating independent tests. Hermes documents separate session management and persisted history, so keep the session and profile identifiers in the test record. Sessions.

Fictional example

Willow Demo Workshops is a fictional training business. Its pilot converts invented workshop briefs into internal preparation checklists. One brief says the room holds twelve people; a later paragraph says twenty. The expected output flags the conflict and withholds a final seating plan. The operator reviews the draft and decides what to ask next. Hermes has no connection for contacting attendees, changing bookings, or ordering equipment. This is an illustrative design, not a customer success story.

6. Decide what the pilot has earned

Finish with a short decision record:

1. Confirm whether every critical test passed
2. List remaining mistakes and their consequences
3. Compare total preparation and review effort with the current process
4. Record the provider, model, instructions, profile, and tool configuration used
5. Name the person who can pause the workflow
6. Approve any next expansion as a separate change

If the pilot becomes repeatable, a reviewed skill may help preserve its procedure. Hermes skills can include instructions and supporting files, so review what is being saved or imported before reuse. Skills system.

Bring the workflow agreement and failed examples to InstallAI when discussing implementation. They provide a concrete basis for deciding which configuration or integration would actually help.