The HTTPS-everywhere pivot: one transport for agents

agentd's early design bound tools and control surfaces to local transports: unix domain sockets on the host, VSOCK across the VM boundary. It worked, and it was wrong. Every deployment question — how does the agent reach a tool? how does an operator reach the agent? how do two agents reach each other? — had a different answer depending on where the processes sat.

The pivot decision was blunt: one transport, HTTPS, everywhere. Every tool is a remote MCP server over HTTPS. Every peer conversation is A2A over HTTPS. Every operator verb arrives over the same management listener. The things that used to be special cases — TLS identity, private CAs, bearer and OAuth 2.1 client-credentials auth — became the single, well-tested path.

Three consequences shaped the runtime that shipped in v1.x:

1. No local code execution survives. With no local transport there is no temptation to shell out. The runtime ships zero built-in tools, and the security posture ("the model can never execute on the box") becomes architectural rather than disciplinary.
2. Cloud-native composition falls out for free. An agentd in a Kubernetes Job reaches the same MCP servers as one on a laptop. Fleet control (agentctl) needs no sidecar — just the contract surfaces over HTTPS.
3. The run-graph replaces ad-hoc modes. Once every interaction is a request, the agent's life is a graph of runs with exit predicates — which is how the five modes (once, loop, reactive, schedule, workflow) are actually one mechanism with five policies.

The document is notable for its provenance, too: it was produced by a multi-agent review in which every claim was re-verified against code at file-and-line granularity before the pivot was accepted.