FB-Brain is FutureBuild's identity and agent coordination platform. It serves as the authoritative source for user authentication across all FutureBuild products — BuildOS trusts FB-Brain to tell it who a user is and what role they hold.

• Authentication: When a user logs in to BuildOS, FB-Brain verifies their identity and issues a signed token (JWT). BuildOS checks this token on every request — no passwords ever touch BuildOS servers directly.
• Role propagation: The token contains the user's role (owner, admin, superintendent, field_worker) and organization ID. BuildOS reads these to enforce permissions.
• Agent-to-Agent (A2A) webhooks: FB-Brain can send signed webhook events to BuildOS — for example, triggering a BuildOS job when something happens in another FutureBuild product. These webhooks use a separate signature mechanism (not the regular JWT) so they cannot be spoofed.

Anthropic Claude is the large language model (AI) that powers BuildOS's reasoning capabilities. It's used in two distinct contexts within the platform — each using a different model optimized for its task.

If the Claude API is unreachable when the Daily Focus Agent fires, the briefing job is retried with exponential backoff. If all retries fail, the job is logged as failed — Mike does not receive a briefing that day, but no data is corrupted. For the Tribunal, an API failure causes the vote to register as ABSTAIN, which triggers human escalation rather than auto-approval. Fail-closed by design.

Tomorrow.io is a weather intelligence platform that provides hyperlocal, hourly weather forecasts. BuildOS uses it for site-specific forecasts that feed into the SWIM weather model and the Daily Focus Agent's weather alerts.

• Hourly precipitation probability and amount (for rain and snow thresholds)
• Temperature (for frost and heat thresholds)
• Wind speed (for crane and framing safety thresholds)
• 72-hour forecast window — enough to alert Mike about weather arriving tomorrow or the day after

Weather data is cached for 6 hours per site location — BuildOS does not query Tomorrow.io on every API call. A circuit breaker limits total calls to 450 per day before throttling begins. If Tomorrow.io is unavailable, BuildOS falls back to the last cached forecast rather than removing weather adjustments from the schedule — conservative by design.

Twilio is the industry-standard SMS platform. BuildOS uses it exclusively for the Sub Liaison Agent's outbound SMS messages to subcontractors, and for receiving and routing inbound SMS responses.

• Outbound: BuildOS → Twilio → Sub's cell phone. Message content is generated by the Sub Liaison Agent and includes the task name, date, and project location.
• Inbound: Sub replies → Twilio → BuildOS webhook endpoint → Sub Liaison Agent parses the response (confirmation, delay, progress update).
• Idempotency: Each SMS is sent with a unique key. If the network retries a send, Twilio deduplicates it — the sub never receives the same message twice from a single send attempt.

The SMS send is retried via the job queue with exponential backoff. If all retries fail, the communication is logged as FAILED in the communication log and a feed card is created for Mike: "[Sub] SMS delivery failed — manual follow-up required." No silent failures.

Firebase Cloud Messaging (FCM) is Google's push notification service used by iOS and Android apps. BuildOS uses it to deliver real-time alerts to Mike and Carlos on their mobile devices — even when the app is closed.

• Task marked complete by a field worker
• Morning briefing ready (Daily Focus Agent)
• Critical procurement deadline reached
• Sub delay reported via SMS
• Weather alert for an active site

Failed push notifications are retried up to 6 times using exponential backoff (30 seconds → 1 hour between attempts). Permanently failed notifications are logged in a dead-letter queue for manual review. The mobile app also polls for updates when it opens, so no notification is a permanent miss.

PostgreSQL is the open-source relational database that serves as BuildOS's single source of truth. Every project, task, budget, invoice, feed card, and agent output is stored here. It is not an external integration in the traditional sense — it is the core of the data platform.

• River job queue: The background job queue (River) runs entirely inside PostgreSQL — no separate message broker (like Redis or RabbitMQ) is required. Jobs are enqueued in the same database transaction as the event that triggered them.
• Constraint enforcement: Equipment allocation conflict prevention uses a PostgreSQL extension (btree_gist) that enforces date range exclusivity at the database level — not just in application code.
• Transaction safety: The Permit Issuance Gate (creating a project from a permit) executes as a single PostgreSQL transaction — all steps succeed or all fail together.
• JSONB for flexible data: Estimate line items, feed card actions, and field progress metadata are stored as JSONB — structured enough to query, flexible enough to evolve.