#3000 Let agent-runner drive more agent CLIs (Kilo Code and others)

Request: let agent-runner drive more agent CLIs, Kilo Code in particular

What I'm asking for

agent-runner works with Claude Code and OpenAI Codex. I'd like it to work with other coding agents as well, Kilo Code in particular, and ideally to give people a supported way to add an agent of their own without waiting for a release.

Why it matters

The agent I use day to day is Kilo. With agent-runner as it stands, the only way I can hand work to it is to shell out to a shell script that knows how to turn a prompt into each CLI's flags. That works, but it leaves the agent call outside the type system: swamp cannot validate that step, and what came back is not something I can query afterwards. With a Kilo provider, that step would be described the same way as every other step.

This is a separate request from (356), "Add first-class Kilo Code tool support", which is about Kilo as an enrolled tool — the one that covers repo init --tool kilo, the audit plugin and doctor audit. That one is about which tool writes the files; this one is about which agent gets run. Happy for you to treat Kilo support as one workstream.

What is in the way

The setting that picks the agent only accepts two values, so even a finished Kilo provider could not be selected. That closed list is the part that has to change first.

What would fix it

Either of these on its own would help:

• Let that setting accept any agent the extension knows about, rather than a fixed list of two. The extension already keeps a list of the providers it has, so the setting could be checked against that list and still give a helpful error for a name it doesn't know.

• Or add a supported way for someone to describe an agent themselves: where the binary lives, and how the prompt, the working directory, the permissions and the output location turn into command-line flags. If that description is checked rather than trusted, then using an agent you don't ship with does not require a pull request.

The first is the smaller change. The second is the more useful one over time.

One thing that needs a decision rather than a guess

For Claude and Codex, agent-runner downloads a specific version of the program itself and runs that. Kilo is not distributed that way — npm is the default installer, but Homebrew and other package managers publish pinned versions too, so pinning a version is entirely doable. What is different is who does the installing. Today agent-runner fetches the artifact itself; with Kilo it would be pinning through an installer the person already has, or finding a copy they installed themselves.

That leaves some real choices worth making deliberately rather than inheriting from the Claude and Codex paths: whether to install at all or require it to be present, how to verify the version that is installed, what to do when it is too old or missing, and whether the version people normally install is even meant to be pinned. I'd rather you decide what this should look like than have me guess and be wrong.

A note on scope

I have kept this general on purpose. The automation that prompted the request is mine and is not a reason on its own. The underlying gap is the real one: agent-runner can drive two CLIs, and there is no route to a third.

Attribution

No source code is attached here and I am not opening a pull request, per the contributing policy. Happy to be listed as a co-author on whatever you write.