For ACP-capable harnesses, I would prefer ACP for programmatic fleet control: prompts, streamed events, permission requests and explicit turn-end responses. A persistent host service is still needed for detach/reconnect and process supervision; ACP does not supply it.

ACP is a better contract for programmatic fleet control

ACP v1 defines session/prompt, streamed session/update events, permission requests and cancellation. A prompt request ends with a response containing stopReason, giving the controller an explicit boundary for that turn. Sources: ACP overview, Prompt turn.

Herdr's terminal approach preserves each agent's existing interactive interface and can run ordinary CLI applications. Its prompt waits observe agent lifecycle state rather than identifying individual turns. Source: Herdr automation.

My preference for an automated fleet is therefore ACP where the harness or a verified adapter supports it. This preference concerns the control contract and dependence on terminal presentation; it is not a measured performance result.

ACP's standard stdio transport still has a client launching an agent subprocess. The protocol does not provide a detached host daemon that survives browser or SSH disconnection. Source: ACP transports.

The proposed architecture keeps a persistent host service for process ownership and remote access, while using ACP between that service and the harness. An existing Roamgate/Herdr deployment would need implementation changes for this path; the researched configuration continues to expose terminal control.