Feature request: Support custom external ACP agents (BYOH)

### Before filing

- [x] I searched [open and closed issues](https://github.com/block/berd/issues?q=is%3Aissue) for duplicates.
- [x] I am using a recent [release](https://github.com/block/berd/releases) and this doesn't already exist.
- [x] This is one request, not several bundled together.

### Closest existing issue

none found

### Is this new, or an improvement?

New capability — Berd can't do this at all today

### The problem, in your terms

I use multiple AI agent systems and wanted to use Berd as the workspace from which I can choose the appropriate agent for a project.

One of those agents is Hermes Agent. Hermes already implements ACP natively over stdio (hermes acp), including initialization, sessions, prompts, cancellation and tool calls.

I expected an ACP-compatible agent to be connectable to Berd without Berd needing to know about that particular agent in advance.

After investigating the current Berd implementation, however, agent availability appears to depend on Berd’s curated agent catalog, ID mappings and readiness/doctor infrastructure. As a result, an otherwise ACP-compatible agent cannot simply be added by the user.

The difficulty therefore isn’t making Hermes speak Berd’s protocol — it already speaks ACP. The difficulty is that I can’t tell Berd to launch an additional ACP-compatible executable.

### What you do today

There is no practical user-level workaround.

I could modify my local Berd source to add Hermes to the curated provider catalog, agent ID mapping and readiness logic, then maintain those changes across Berd updates.

I don’t consider maintaining a private modification of Berd a reasonable workaround just to connect an agent that already implements the protocol Berd uses.

### What you'd like to see

A supported way to register an arbitrary ACP-compatible agent without modifying Berd’s source.

Conceptually, something as simple as: agents:
- id: hermes
name: Hermes
command: hermes
args: ["acp"]
transport: stdio
This could be exposed through configuration, the UI, or another extension mechanism appropriate to Berd.

Berd could verify readiness by checking the executable and performing the normal ACP initialization handshake.

Once registered, the external agent should appear alongside Berd’s built-in agents in the normal agent selector.

### Why this belongs in Berd itself

Because the missing capability is at the boundary between Berd and the agent runtime.

A skill or automation running inside an existing Berd agent cannot register another ACP runtime with Berd’s agent selector or change how Berd launches and manages agent processes.

ACP already provides the interoperability boundary. What is missing is a Berd-level extension point that lets users provide the command implementing that boundary.

I am not asking for Hermes-specific integration. Hermes is simply the concrete ACP agent that exposed the limitation. A generic mechanism would work for Hermes and other current or future ACP-compatible agents without requiring each one to become a hardcoded Berd integration.

### Non-goals

No Hermes-specific functionality.
* No request for Berd to install or maintain Hermes.
* No request for Berd to manage the external agent’s API keys or model-provider credentials.
* No new agent protocol.
* No requirement for every custom agent to receive the same first-class onboarding or diagnostics as Berd’s curated agents.
* No request to replace or change the existing built-in agent integrations.

The request is only for a supported way to register and launch an external ACP-compatible agent.

### Alternatives you considered

Modify Berd locally: technically possible, but requires maintaining local source changes across updates.

Write a skill or automation: doesn’t solve the problem because those run after an agent/runtime has already been selected; they cannot add a runtime to Berd.

Use Goose as an intermediary: adds an unnecessary agent layer when the external agent already implements ACP directly.

Use Hermes separately: this works, but defeats the purpose of using Berd as a common workspace for multiple agent harnesses.

For these reasons, a small generic ACP registration mechanism seems cleaner than adding individual integrations for every compatible agent.

### Mockups, prior art, or other context

example: Berd
│
├── Goose
│
├── Codex
│
└── Custom ACP
command: hermes
args: ["acp"]
│
└── Hermes Agent

Hermes is already an ACP server over stdio, so this use case should not require a protocol bridge.

Start by reading Berd’s curated agent catalog, agent ID mappings, and readiness/doctor flow to understand how built-in agents are registered and launched. Define a generic configuration or extension path, then verify that an arbitrary ACP-compatible command can complete initialization, appear in the normal agent selector, and launch without changing built-in integrations.

Written by the indexing model from the issue text.