Executors and your model account

Every seat on the roster has something behind it that runs when the seat is given work. hm calls that an executor, and it can be three different things: a model-backed agent, a script, or a person.

Executors are not orchestrators

An executor runs inside a seat. It receives a task with acceptance criteria, does the work in its own directory, and reports back. It does not decide what work exists, it does not assign tasks, and it changes the state of the record only by calling hm.

That boundary is the reason a Works can change which agent runtime it uses without changing anything about how the company runs. The plan, the roster, the record and the gate all belong to hm; the thing that writes the code is a replaceable part.

It is also why a script and a person are legitimate executors. A step that should not be automated — a decision, an approval, a task with real-world consequences — sits in the same roster, gets the same brief, and lands through the same gate as everything else.

The model account stays yours

The agents run against your own model account. You hold the credentials, and you pay your provider directly for the work the agents do. hm buys no inference on your behalf and resells none to you — an arrangement usually shortened to bring your own key, or BYOK.

Two things follow, and both are worth being explicit about.

• The largest cost of running agents is not on an invoice from hm. It is on the bill you already get from your provider, at the rate you already negotiated.
• hm's job is to govern that spend, not to mark it up. You set a cap, every run is tracked against it, and work stops when the cap is reached.

What that means in practice

You can see what a piece of work cost, because the record and the spend are kept against the same tasks. You can change providers without asking anyone. And the answer to "what happens to my agents if hm goes away" is that the credentials, the record and the project are all already on your machine.