Runtime adapters

Every coding tool an agent might run has its own way of being invoked and its own way of streaming what it did, and an adapter is the layer that hides those differences. Without adapters, supporting another tool would mean teaching the rest of the product a new command line and a new output format. With them, 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 what an adapter does, where Task Machine's instructions hand off to the local tool, and which runtime details decide whether an adapter is even eligible to run a piece of work.

An adapter turns one tool into a normalized run

An adapter is the per-tool component that knows how to detect a 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, the daemon picks the adapter for that job's runtime, 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 and its adapters never compose a prompt. They carry the finished instructions to the local tool and bring its work back. The adapter's job is to faithfully run the tool and normalize its output — not to add behavior of its own or to paper over how the tool actually ran, since that detail is what you need when a run goes wrong.

The adapter owns the protocol flags

Part of building the right command is choosing the flags that let Task Machine drive the tool unattended, and the adapter keeps those flags under its own control. An agent runs without a person at the keyboard, so each adapter launches its tool 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. The adapter 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 the adapter 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 the adapter 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 — the adapter 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 runtime 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 adapter runs

An adapter only runs work on a runtime that is actually available, and availability is a combination of facts about that runtime rather than a single flag. The runtime must be freshly reported by a live daemon, 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 runtime 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 runtime but the work only runs when that runtime is genuinely ready. The adapter is the machinery that runs an eligible tool well; the runtime machines chapter is where eligibility is decided.

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