Architecture & Resilience Overview

Documents the redundancy, failover, and graceful-degradation measures Agent360 LLC maintains for each category of sub-processor, scoping the third-party-outage exclusion in SLA 4(d).

Last updated: April 20, 2026 · Version: v2026.04.20-1

This page documents the redundancy, failover, and graceful-degradation measures that Agent360 LLC maintains for each category of Sub-processor underlying the Zoe AI voice-receptionist Services. The commitments here scope the third-party-outage exclusion in SLA §4(d): a Sub-processor outage qualifies as “Excluded Time” only after the redundancy / failover measures below have been exhausted. The page is reviewed at least annually and on every material architectural change.

1. Posture summary

• Telephony carriers: Posture — Active redundancy with automatic failover; Target RTO — < 60 seconds per call; Target RPO — 0 (no in-flight call lost beyond the failover window)
• LLM providers: Posture — Active redundancy with automatic re-route; Target RTO — < 5 seconds per turn; Target RPO — 0 (per-turn failover; conversation state preserved)
• Speech-to-text (STT): Posture — Active-passive failover; Target RTO — < 30 seconds; Target RPO — 0 (audio buffered and re-transcribed)
• Text-to-speech (TTS): Posture — Active-passive failover; Target RTO — < 5 seconds per utterance; Target RPO — 0
• Database (Supabase Postgres): Posture — Active-passive failover with point-in-time recovery; Target RTO — < 5 minutes; Target RPO — < 5 minutes
• Infrastructure (AWS regions): Posture — Multi-AZ in-region; documented mitigation for region-level failure; Target RTO — < 30 minutes (in-region); < 4 hours (cross-region); Target RPO — < 5 minutes (in-region); < 1 hour (cross-region)
• DNS: Posture — Multi-provider authoritative DNS with TTL ≤ 60s; Target RTO — < 60 seconds; Target RPO — 0
• Certificate authorities: Posture — Documented mitigation (pre-issued backup chain, automated renewal alerts); Target RTO — < 4 hours; Target RPO — 0
• Transactional email (Resend): Posture — Documented mitigation (queueing + retry; out-of-band SMS fallback for critical paths); Target RTO — < 30 minutes; Target RPO — 0 (queued)
• Billing (Stripe): Posture — Documented mitigation (retry; provisioning is not in the call-handling hot path); Target RTO — N/A (not in the call hot path); Target RPO — 0 (idempotent webhooks)

2. Telephony — active redundancy (Twilio ↔ SignalWire)

Outbound and inbound trunks are provisioned on Twilio and SignalWire in parallel. Active health-checks evaluate per-carrier signaling latency, post-dial-delay, ASR (answer-seizure ratio), and 5xx response rates on a 30-second window. When the active carrier crosses any threshold, the dial-plan layer routes the next call attempt through the standby carrier without operator intervention. In-flight calls cannot be migrated mid-call (no carrier supports SIP transfer for an active media leg), so a hard-down carrier event affects only the in-flight calls on that carrier; subsequent calls failover within ~60 seconds of detection.

3. LLM providers — active per-turn re-route (OpenAI ↔ Anthropic)

Each conversational turn is routed to the configured primary LLM provider. On any 4xx (rate limit, content-policy false positive) or 5xx (provider outage) response, or on a per-turn deadline miss (currently 4 seconds for the first token, 8 seconds for first audio frame), the orchestration layer retries the same turn against the standby provider. Conversation state is persisted in our database, so re-route is idempotent and the caller does not lose context. Provider routing is configurable per Customer.

4. Speech — active-passive failover (Deepgram primary, ElevenLabs primary)

STT and TTS each have a primary and a secondary provider configured. Audio is buffered for the last 10 seconds; on STT primary failure the buffer is replayed against the secondary. TTS has a smaller buffer (per-utterance) and re-synthesizes against the secondary on primary failure within ~5 seconds.

5. Database — Supabase Postgres + PITR

Primary database is Supabase Postgres with daily encrypted backups, write-ahead-log archival, and point-in-time recovery to any moment within the last 7 days. Cross-region read replicas are configured for the largest tenants and for the global tenant-resolution path.

6. Infrastructure — AWS

Compute and queueing run multi-AZ in us-west-2 (primary) with a documented runbook for cross-region failover to us-east-1. Static assets are served via a global CDN.

7. DNS — multi-provider

Authoritative DNS for getagent360.com and tenant subdomains is hosted on at least two independent providers with synchronized zone data and a TTL of 60 seconds, so a single-provider outage is mitigated by resolver fallback within one TTL.

8. Certificate authorities

TLS certificates are issued via two independent CAs with automated renewal at least 21 days before expiry. We maintain a pre-issued backup certificate chain that can be rotated within four hours.

9. Transactional email — queue + retry + SMS fallback

Transactional email is sent via Resend. On Resend unavailability, messages are queued and retried for up to four hours. For account-recovery and security-critical paths, an out-of-band SMS fallback is invoked via Twilio (or SignalWire) when the queue depth or age exceeds 15 minutes.

10. Billing — not in the call hot path

Stripe is used for billing and AI-credit top-ups only; it is not in the call-handling hot path, so a Stripe outage does not affect call answer rates. Webhooks are idempotent (processed deliveries are deduplicated by Stripe event id) and re-played from Stripe’s side after recovery.

11. Review and change log

This page is reviewed at least annually and on every material architectural change. Material changes (e.g., adding a new Sub-processor category, removing redundancy from a category) trigger an in-product notification to Customers and an update to the published Subprocessors page at /compliance/subprocessors.