Skip to content

Working through an agent

Many pages on this site show you commands. Most of the time you do not have to run them. If you have a coding agent connected to Hadron — Claude Code, Codex, Cursor, or another — you can describe what you want and let it do the typing.

That is not a shortcut around learning the tool. It is how the tool is meant to be used: Hadron's surfaces were built for agents to drive, and the CLI's own contract is written for one to read.

This page is about what that changes, and where it stops being true.

What actually changes

Not much about what gets done. A great deal about what you spend attention on.

Typing a command means holding two things at once: the intent (give this role a description) and the mechanics (which subcommand, which flag, which identifier spelling). Delegating removes the second. What is left is the part only you can do — deciding what should be true, and checking that it now is.

So the shape of a delegated task is two sentences rather than one:

"Cast a worker named Iris as backend-engineer in the platform team."

"Now show me the staff list including retired workers, so I can see the name took."

The second sentence is the work. Anyone can phrase a request; knowing what would prove it worked is the skill, and it is where a delegated task goes wrong when it goes wrong.

What to ask for

Three habits make the difference between an agent that helps and one that guesses.

Ask for the outcome, not the command. "Give the backend-engineer role a description" leaves the agent free to use whichever surface actually works. "Run hadron team role update --description …" pins it to a spelling that may have changed in the last release — and the agent will run it, and it will fail, and you will both be debugging a flag instead of doing the task.

Ask how it knows. Every how-to on this site that involves delegation carries a how to know it worked for each step, because the check is rarely the obvious one. A staff list hides retired workers unless you ask for them. A prompt template that never binds {{name}} produces workers whose prompt never names them. A chat post attributed to you rather than to the worker means the session binding silently did not happen.

Ask it to say when something refused. Typed refusals are Hadron's main way of telling you that you asked for something that cannot be true — WORKER_NAME_TAKEN, WORKER_HELD, TEAM_ROLE_EXISTS. An agent that works around a refusal quietly has thrown away the most useful thing that happened.

What you should still do yourself

Delegation is not a property of Hadron; it is a property of the task. Four kinds are worth keeping at your own keyboard, and a page describing one will say so.

Anything that installs or authenticates on your machine. Getting the CLI onto your laptop and signed in, minting an API key, configuring a provider. The credential is yours, the machine is yours, and a step that ends in a browser sign-in is not one to narrate to somebody else.

Anything irreversible, at the moment it becomes irreversible. Casting a worker mints a permanent name. Deleting a memory starts a clock. An agent can rehearse those — Hadron has dry runs precisely so the irreversible act can be inspected first — but the decision to proceed should be a person's, taken while looking at what is about to happen.

Anything that acts as somebody else. Impersonating a member for support is an audited act performed by you, and the audit trail says so. Handing it to an agent puts a layer between the record and the person accountable for it.

Anything on a host you are responsible for. Standing up a resident coordinator, wiring a systemd unit, placing tokens on a server. The failure modes there are operational rather than logical, and they want the person who will be paged.

The honest caveat about surfaces

An agent connected over MCP alone cannot do everything the CLI can. Creating agents, publishing imports, installing an App and adding members exist only on the CLI and the GraphQL API — so an agent with no shell can staff a team and drive sessions, and cannot build the team to staff.

That boundary is worth knowing before you delegate, because the failure is quiet: the agent has no tool, so it improvises or apologises rather than telling you it cannot. If a task needs setup, the agent needs a terminal.

CLI vs. MCP for a coding agent compares the two surfaces properly, including the axis that usually decides it — context-window tokens.

Worked examples on this site

Two pages are written in this shape rather than as command lists, and they are the best illustration of the difference: