ambassador-patternlisted

# Ambassador Pattern ## Purpose and boundary An ambassador mediates the application's outbound calls through a local peer process. The app can delegate topology and transport policy, but still owns business intent and observes latency, errors and deadlines. This skill covers that delegation, not ingress gateways or the Ambassador-branded product. Pod mechanics belong to `sidecar-pattern`. Policy can change independently of application code **if** the selected proxy supports the required configuration updates. Hot reload, proxy replacement and a pod rollout have different restart consequences; name the actual update mechanism before promising no restart. ## Workflow 1. **Establish the evidence.** Obtain the outbound call path, protocols on both hops, proxy/mesh and client versions, effective routes and retry settings, deadline semantics, upstream operation contracts, replica count and relevant latency/load limits. For a diagnosis, request correlated app/proxy/upstream traces, attempt counts and queue metrics. Configuration shows intent; runtime counters and fault tests show behavior. If evidence is missing, name the gap and proceed only with conditional options, not deployable settings or a claimed root cause. For Java client or deadline changes, apply the compatibility checks in [Failure and policy composition](references/failure-and-policy-composition.md#java-client-compatibility). 2. **Choose what moves.** Inventory discovery, shard maps, retrie