Worker tool support

Every coding tool an agent might run has its own way of being invoked and its own way of streaming what it did. Task Machine keeps those differences inside the worker's tool support, so adding another tool does not mean changing the rest of the product. Each tool's specifics are contained in one place, and everything above sees the same shape of work and the same kind of transcript. This chapter explains how Task Machine hands instructions to the local tool, and which worker details decide whether that tool is even eligible to run a piece of work.

Each tool becomes a normalized run

Task Machine knows how to detect each supported local coding tool, build the right command to invoke it, run it, and translate what it produces. When an agent's job reaches a machine, Task Machine chooses the support path for that job's worker, launches the tool with the instructions the job carries, and streams the tool's output back as transcript events — a common vocabulary of steps started, text and reasoning, tool calls and their results, token usage, and a final outcome. Those events are what fill a task timeline or a chat regardless of which tool ran underneath, so the same surface reads consistently whether the work ran on one coding tool or another.

A point worth being precise about: the instructions an agent follows are assembled by Task Machine from the agent's profile, its memory, and the context of the trigger. The tama CLI never composes a prompt. It carries the finished instructions to the local tool and brings its work back. The tool support path faithfully runs the tool and normalizes its output — it does not add behavior of its own or paper over how the tool actually ran, since that detail is what you need when a run goes wrong.

Task Machine protects the tool flags it needs

Part of building the right command is choosing the flags that let Task Machine drive the tool unattended, and Task Machine keeps those flags under its own control. An agent runs without a person at the keyboard, so each supported tool launches in a non-interactive mode that does not stop to ask for permission mid-run — Claude Code, for instance, runs with its permission prompts bypassed, and the other tools each launch with the equivalent flag for their own approval model. Task Machine also fixes the flags that shape the machine-readable output it parses back into transcript events.

An agent's profile can still pass extra arguments through to its tool, but Task Machine treats the flags it depends on as protected: any extra argument that would override a protocol-critical flag — the output format, the permission mode, a resume or continue flag, anything that controls how the run is structured — is dropped before the tool is launched, and the run records a note that it was dropped. Harmless extra arguments pass through untouched. This keeps an agent's customizations from quietly breaking the contract Task Machine relies on to run the tool unattended and read its output, while still letting you tune the parts of a tool's behavior that are safe to tune.

A failed run is a failed job, with the evidence kept

When a tool's process fails — it exits with an error, the tool refuses the work, the run is cut off — Task Machine reports that as a failed job rather than swallowing it. The failure is attached to the job with what is needed to understand it: the outcome, the exit state, and the output captured up to that point. A failed job raises an item to the inbox of the person who set the work in motion, so a broken run becomes something you see and act on instead of silence.

Whether a failure is the end of the story depends on where the work came from. Inside a workflow, transient worker failures retry automatically with Task Machine's standard bound before the step fails. A standalone task surfaces the failure for you to judge and re-run. Either way the durable record holds the evidence, because an honest account of what the tool did is the difference between debugging a real problem and guessing at it.

Availability decides which tool runs

Task Machine only runs work on a worker that is actually available, and availability is a combination of facts about that worker rather than a single flag. The worker must be freshly reported by a live machine, so its machine is online and its tool is currently installed. Its executable must be present so there is something to invoke, and a workspace owner must have left it enabled for agents. A worker that is online but disabled for agents still appears in the workspace, yet no new agent work is sent to it — being reachable is not the same as being approved.

This is why an agent's profile names a default worker but the work only runs when that worker is genuinely ready. The worker machines chapter is where eligibility is decided.

From here, the last chapter in this part lists the coding tools Task Machine supports — see supported coding tools.