Correctly detect and recover from Microsoft Graph throttling (HTTP 429) so an agent backs off, retries safely, and stays under per-workload rate limits.

Documented steps

1. Treat any Microsoft Graph response with HTTP status 429 Too Many Requests as throttling — Graph both limits further requests from that client for a period and returns 429 for the failing request(s).
2. Read the Retry-After response header on the 429, e.g. `Retry-After: 10` (seconds). The error body looks like: {"error":{"code":"TooManyRequests","innerError":{"code":"429","status":"429"},"message":"Please retry again later."}}.
3. Wait the exact number of seconds given in Retry-After, then retry the single request. If it fails again with 429, keep honoring the (possibly new) Retry-After value — immediate retries still accrue against your usage limits and slow recovery.
4. If a response doesn't include a Retry-After header, use exponential backoff instead (Microsoft's Graph SDKs do exactly this: honor Retry-After when present, else exponential backoff).
5. Reduce throttling proactively: fewer operations per request, lower call frequency, and avoid continuous-polling/full-collection-scanning — use Graph change tracking (delta queries) and change notifications instead of repeatedly polling.
6. Know the documented limits: a global cap of 130,000 requests per 10 seconds per app across all tenants, plus separate, often much lower service-specific limits (e.g. Excel: 5,000 req/10s per app across all tenants and 1,500 req/10s per app per tenant; identity/access reports: 5 req/10s per app per tenant). The first limit reached triggers throttling.
7. For high-volume bulk data extraction, use Microsoft Graph Data Connect — it is documented as not subject to these throttling limits.
8. Docs: https://learn.microsoft.com/en-us/graph/throttling ; https://learn.microsoft.com/en-us/graph/throttling-limits