Your first Hermes agent: a no-code readiness checklist

Choose one job you can already judge

Before any settings, write the whole checklist where you can see it. These five checks are the entire readiness review:

1. One job you can already grade by eye.
2. Named inputs and a single output destination.
3. An autonomy level—start at read or draft only.
4. A named owner who reviews results and catches exceptions.
5. A review date after the first three runs.

The rest of this note is one check per step, starting here—because every later decision depends on the job being clear. Pick a task that repeats and has a result you already know how to grade, then write it in one sentence with a day, a source, and a deliverable: “Every Friday, prepare a draft summary of open customer issues for the support lead.”

Why it matters: an agent inherits the clarity of its instructions. A fuzzy job produces fuzzy output that you then have to read closely every time, which is the opposite of saving time. How to judge it: before the first run, you can say in one sentence what a good result looks like. If you cannot, the job is not ready. Failure case: “help with support” gives the agent no finish line and no standard, so you end up inspecting everything and trusting nothing. The trade-off: a narrow first job can feel almost too small—but a small job that earns trust beats an ambitious one you have to babysit.

Name the inputs and the one output

List exactly where the agent may look and the single place its result should appear. Name the sources—“these three folders,” “this approved notes file”—rather than “use anything available,” and pick one output destination inside the dashboard.

Why it matters: a small, named source set is something you can actually verify; an open-ended one is not. How to judge it: you can point to each input and the output location before launch, and every line in the result can be traced back to a named source. Failure case: handing the agent the whole inbox or the open web means it can surface something from a place you never intended, or pull a private thread into a draft meant to go out. The trade-off: naming sources means the agent will sometimes miss a thing that sat outside the set—that is the price of an output you can trust at a glance instead of re-checking from scratch.

Set the autonomy level: read or draft first

Start the agent in read-only or draft-only mode. Require your approval before it does anything that leaves the dashboard—sending, publishing, paying, deleting, or changing an outside record. More access can be added later, after several runs you have actually reviewed.

Why it matters: reversible work is cheap to fix, while an action that reaches a customer or moves money leaves your control the instant it runs. How to judge it: ask one question of each action—“if this run is wrong, can I undo it in under a minute with no outside consequence?” If the answer is no, it belongs behind an approval. Failure case: granting send access on day one lets a malformed reminder reach a customer under your name before you have seen a single output. The trade-off: read-and-draft means you keep pressing the final button for a while; you buy that time back with the certainty that nothing goes out unseen.

Assign one human owner

Name the person responsible for the outcome—not merely whoever clicked launch. The owner reviews the early results, receives the exceptions the agent flags, and can pause the workflow. In a one-person business the owner is usually you; the point is that the name is written down and the responsibility is not floating.

Why it matters: an agent with no owner has no one reading its exceptions, so a problem only surfaces when a customer complains. How to judge it: one name is on the workflow, that person can pause it, and they know they are accountable for the result rather than the setup. Failure case: “the team owns it” means no one reviews, and a drifting output can run for weeks before anyone notices. The trade-off: ownership is real work for one person, but concentrating it is exactly what keeps review fast and accountable instead of diffuse and slow.

Set the launch gate and review date

Confirm the four checks above, launch in read or draft mode, and put a review date on the calendar for after the first three runs. Treat those runs as data, not proof.

Why it matters: a scheduled review is the moment you actually decide to expand, adjust, or stop—without it, a first agent tends to run untouched and unexamined. How to judge it: read all three runs against your one-sentence definition of a good result; if you would grade every one a pass, you can consider granting one narrow step more autonomy. Failure case: launch and forget, and the agent runs for a month while trust neither grows nor gets tested. The trade-off: waiting three runs before expanding feels slow when the thing is already working, but that delay is what turns a lucky first run into a track record you can rely on. No server, storage, terminal, or configuration work is required from you at any point—those checks are the whole job.