Architecture Overview
This page is for a CTO or engineering lead evaluating Bitment from the outside: what it's built on, how the pieces fit together, and what "AI-native" actually means in this product rather than as a marketing label.
Where to find it
There's nothing to click here; this describes how the product is built, not a feature inside it.
Key concepts
- Single binary: the entire backend, and the built frontend, ship and deploy as one compiled artifact.
- Proposal: the pattern every AI mutation follows: stage a specific, reviewable change, then a person approves it.
- Tool catalog: the set of actions the AI is allowed to take, each one identical to an action a person can take through the interface.
- Durable worker: a background process that picks up recorded work and completes it, surviving a restart or crash.
One binary, one database
The backend is written in Go and compiles to a single binary. In production, the built React frontend is embedded directly inside that binary, so there is one artifact to deploy, not a frontend and backend shipped and versioned separately. The binary serves the API, serves the compiled frontend, and connects to a single PostgreSQL database that holds every firm's data (with each firm's stack running its own dedicated instance, described in Security and data).
Data access goes through a typed, generated query layer over SQL: every query the backend runs is a written SQL statement with generated, type-safe Go code around it, rather than a hand-assembled query string or a general-purpose ORM abstracting the database away.
Real-time by WebSocket
Long-lived, bidirectional features, AI chat streaming, live agent runs, team messaging, and collaborative document editing, run over WebSocket connections rather than polling. Each connection is authenticated the same way an ordinary request is, before the connection is even accepted, and the server keeps the connection alive with a heartbeat so an idle connection through a load balancer or CDN doesn't get silently dropped without either side knowing.
Asynchronous work is durable, not fire-and-forget
Any operation that has to keep running after the request that started it returns, importing a batch of clients, syncing a bank feed, sending a scheduled email, records its own intent to the database in the same transaction as the user-visible action that started it. A separate, long-lived worker process then picks up that recorded intent and does the work, including recovering and retrying after a crash or restart. Nothing important is held only in memory in a background goroutine that a restart would silently lose.
The AI layer
Bitment's AI features (Chat, autonomous Agents, and a contextual Assistant) sit on one shared substrate underneath: a conversation, a catalog of tools the AI can call, and a review step for anything that changes data. They differ only in who's driving (a person in the moment, versus an autonomous agent) and how much license they're given, never in what the tools underneath are.
Three things are true across all of it:
- Every AI tool is the same action a person can take through the interface. The tool catalog isn't a separate, AI-only write path into the data; it's a permission-gated projection of the same underlying actions the product already exposes to a human, so a tool can never do something the interface itself couldn't do.
- The AI never writes directly. Any action that would change data is staged as a specific, reviewable proposal, and a person approves it before it takes effect. There is no path for the AI to approve its own proposal.
- The AI is provider-agnostic. Every model call goes through one internal interface, regardless of which AI provider is backing it, so a firm's choice of provider (see Bring your own AI provider) is a configuration choice, not a different code path. A unified model picker routes each request to whichever connected credential offers that model.
The AI is also grounded in how the product actually works: a hand-written product manual describing every feature is embedded in the product and available to the AI, so it can walk a user through a real feature instead of inventing an answer about a screen that doesn't exist.
Integrations talk to the real vendor APIs
Every third-party integration (Google Workspace, Microsoft 365, Slack, Signal, Telegram, Fireflies, Asana, Quo, CCH Axcess, QuickBooks Online, and the connected AI providers) is built against that vendor's real, documented API using their own SDK where one exists. There's no scraped or reverse-engineered integration layer standing in for a vendor's actual API.
Identifiers
Every record in the system, from a client to an invoice to a message, carries a unique, structured identifier that names the kind of record it is right in the string (a client record's identifier reads differently from a project's, for instance). That makes an identifier self-describing wherever it shows up, in a log, a URL, or a support conversation, without having to look up what table it came from.