Most outbound tools you have used are sending tools. They push email through mailboxes you already own, give you a dashboard of opens and replies, and stop there. NimbusOS takes a different shape. It bundles a contact data platform, a sending fleet with its own infrastructure pipeline, a deliverability brain that gates the sends, and an AI layer that classifies every reply and recommends the next action. This overview walks through the four pillars and how they talk to each other.
Read this page once before you build anything. The architecture decisions later will be obvious once you understand why NimbusOS records a campaign launch in five different tables.
The Four Pillars
Every feature in NimbusOS lives under one of four pillars. You will see these names in the navigation, the API prefixes, and the capability reference.
Data Pillar
The Data pillar is the contact data platform. It holds Contact, Company, GlobalContact, IdentityGraph, Segment, Tag, and every enrichment table. It is the canonical source of truth for who your prospects are, what your system knows about them, and which client or campaign owns them right now.
The Data pillar is where the CDP identity promise is fulfilled. GlobalContact stores a single record per unique email across the entire platform. Every time a contact appears in an ImportJob, the row is matched against GlobalContact first. That deduplication enforces a rule most outbound tools do not: the same human does not get hit twice by two agencies on the same NimbusOS instance.
Beyond deduplication, the Data pillar runs the scoring and segmentation engines. Every contact carries an icp_tier and a lead_score. Both are computed from ScoringRule objects that you configure per workspace. Scoring is not a one time event. It rerun on every enrichment, every engagement event, and every relevant AutomationRule firing.
Messaging Pillar
The Messaging pillar is the email engine, the sequence builder, the campaign layer, the workflow engine, and every downstream channel (LinkedIn automation, phone dialer, SMS). This is the send side of the system.
Campaign is the orchestrator. It holds send limits, the chosen sending pool, tracking settings, stop conditions, and the platform choice (native, ReachInbox, Instantly, Smartlead, Lemlist). EmailSequence and EmailStep define the message flow. SequenceTemplate persists the visual builder state so you can reopen a sequence six months later and see the exact graph you drew.
Sub sequences matter in NimbusOS more than they do in most tools. A sub sequence fires on a condition, like a specific reply phrase, a lead marked as meeting_booked, or a link click. The sub sequence itself is a full sequence with its own steps, delays, and stop conditions. This is how you build a sophisticated outbound playbook, like "if they reply with a pricing question, send the short ROI primer; if they reply with an objection, route to the sales engineer."
Deliverability Pillar
The Deliverability pillar is the silent operator. It runs underneath every campaign, and most users never look at it until an alert fires.
Four model families live here: EmailAccountHealth for per inbox reputation, DomainHealth and DomainHealthScore for per domain reputation, NimbusDeliverabilityScore (NDS) for a unified 0 to 100 score, and SpamIntelligenceSnapshot with SendOutcomeLog for platform-level reputation signals. The ISP monitoring layer ingests Gmail Postmaster, Microsoft SNDS, and Yahoo Feedback Loop data, aggregates it, and writes time series into the health tables.
The brain reads all of this on every cycle. Its job is to decide three things: is this inbox safe to send from right now, is this campaign safe to launch at this volume, and is this domain getting close to a blacklist entry that should trigger rotation. When any of those answers goes bad, the brain writes a BrainSignal row and pauses the affected campaign or inbox.
Intelligence Pillar
The Intelligence pillar is where the AI lives. Three subsystems run here.
The hyper personalization engine turns a LinkedIn profile URL or a company domain into a PersonalizationResearch record, an IntentSignal timeline, and a set of PersonalizedLine variants. The research step is Claude powered and ICP tier aware. A tier A prospect gets deep research; a tier D prospect gets shallow, because the economics would not justify the cost otherwise.
The reply intelligence layer runs every inbound message through a classifier. The output is an intent label, a sentiment score, a confidence number, and sometimes an auto routing rule fires. Out of office replies push the contact into a scheduled follow up on the return date. Positive replies drop into the rep inbox with a Slack notification. Bounces feed the bounce intelligence layer that decides retry timing.
The autopilot brain is the newest layer. It reads from BrainSignal, the deliverability tables, and the performance metrics, and recommends actions: pause this campaign, rotate this domain, raise this send cap, rebuild this segment. In supervised mode every action requires a human approval. In autonomous mode approved action types execute directly. The human still sees the log, and can reverse any action through AutopilotAction.
The Unifying Pattern
What makes NimbusOS different from stitching together four separate tools is that the four pillars share the same contact, campaign, and workspace records. A Campaign row is one object. When the Deliverability pillar wants to pause it, it flips a field on that same row. When the Messaging pillar wants to enroll a new contact, it reads the same row. When the Intelligence pillar wants to generate a personalized opener, it reads the Contact row that the campaign references.
This is the opposite of the stitched model where each tool has its own contact ID and you pay for a data warehouse to reconcile them nightly. In NimbusOS the reconciliation is always true, because there is only one version of the record.
Multi-Tenancy and the Workspace Model
Every record in NimbusOS is scoped to a Workspace. This is not a soft policy. Every API endpoint goes through the WorkspaceSecurityMiddleware, which reads the JWT, resolves the workspace, and injects it into the request. Every queryset uses the TenantScopedMixin which hard filters on workspace. If a developer forgets to scope a query, the middleware rejects the request.
For agencies, the workspace is augmented with a Client hierarchy. The master Client represents the agency. Sub clients represent each customer the agency runs outreach for. Contacts, campaigns, sequences, and even sending accounts can be scoped down to a sub client. This is how white label reporting works: when a sub client logs into their branded portal, they see only their own data, served from the same database, same Django app, same APIs.
White label is not an afterthought. WhiteLabelSettings per workspace controls the logo, favicon, primary color, and the custom domain on which the portal loads. SSL is automatic. PortalUser records track per sub client users with granular visibility: show analytics, hide campaigns, show reports, and so on.
The Data Flow of One Send
A common way to get a feel for the architecture is to follow one send from start to finish.
A sales ops user uploads a CSV to /contacts. An ImportJob record is created. The pipeline parses the file, deduplicates against GlobalContact, runs enrichment if configured, applies suppression, segments into an ICP tier, and scores. Each step writes an ImportJobRow per input row so you can see exactly what happened with any row.
The newly imported contact matches an active AutomationRule with trigger on_contact_import and condition icp_tier in ['A', 'B']. The rule's action enrolls the contact into Sequence X. An EmailStepEnrollment row is created with the first step scheduled in five minutes.
The hyper personalization engine picks up the new enrollment. It fires research_prospect asynchronously, which creates a PersonalizationResearch row with LinkedIn context, a WritingStyleProfile, and several PersonalizedLine variants.
Five minutes later the sequence engine picks the enrollment for the next batch. It resolves the chosen sending inbox by querying EmailAccountHealth for an eligible account in the campaign's pool. It renders the template, injecting the personalized first line if present. It calls ReachInbox to push the send.
The send lands. ReachInbox calls the NimbusOS webhook for email_sent. The webhook records a SendOutcomeLog row and increments the campaign's total_sent counter.
Eight hours later the prospect opens. A tracking pixel fires. Another SendOutcomeLog row. The campaign's opened counter increments.
Two days later the prospect replies. ReachInbox pushes the reply to the unified inbox sync. The reply intelligence layer classifies it as interested with 0.92 confidence. An EmailThread row is opened and marked hot_lead=true. A Slack notification fires to the owning rep.
The rep responds from the unified inbox. The thread continues. A meeting is booked. The Contact is marked meeting_booked which is a condition on a sub sequence that sends a pre call primer. The sequence engine then exits the main sequence.
Seven touch points, five tables updated, three AI decisions. All inside one platform and all queryable from one API.
What Lives Where (Quick Reference)
When you need to find something in the platform, this mapping helps.
| If you are looking for | Open this page |
| ----------------------------- | ---------------------- |
| Contacts, companies, segments | /contacts |
| Lead scoring rules | /lead-scoring |
| Email accounts and warmup | /email-accounts |
| Sequence builder | /sequences |
| Campaigns | /campaigns |
| Unified inbox | /unified-inbox |
| Reply intelligence | /reply-intelligence |
| Deliverability dashboard | /deliverability |
| A/B testing | /ab-testing |
| Automation rules | /automation |
| Autopilot control | /autopilot |
| Integrations | /integrations |
| Billing and usage | /billing |
What NimbusOS Does Not Do
Being explicit about scope matters. A few things that are visibly missing right now.
There is no in-platform calendar or meeting booker. Positive replies surface in the unified inbox and you respond with your calendar link. Integrating a TidyCal or Calendly link is on the roadmap, but the data plane for it is not built yet.
There is no visual HTML email editor. Templates are plaintext with variables. HTML emails are supported but you write the HTML. This is deliberate. Plain text cold email outperforms HTML on inbox placement for nearly every B2B use case, and we do not want to give users an easy path to an inbox killing template.
There is no automatic campaign launch from the GTM engine. The GTM engine generates GTMMessage records and NowList entries, but the path from there to a running ReachInbox campaign is still manually invoked. We are wiring that path; for now the GTM engine is a decision layer that hands messages to a human to queue.
Frequently Asked Questions
Do I need to understand every pillar to be productive?
No. Most users work in one or two pillars at a time. Sales ops live in Data and Messaging. SDR leads live in Messaging and Intelligence. Deliverability operators live in Deliverability. The architecture is consistent enough that the skills transfer when you move between pillars.
Can I disable a pillar I am not using?
Pillars are not toggleable. But you can ignore the intelligence features entirely and run NimbusOS as a pure send tool, or ignore the sending features and use it as a pure CDP that pushes to an external sender through the outreach tool integrations.
Where does the autopilot brain get authority to pause things?
Only from the campaigns and inboxes it has been granted control over. Autopilot respects per campaign and per inbox opt in. The first time you enable autopilot on a campaign, the system asks you to confirm the action types it is allowed to take. You can always revoke authority.
What to Read Next
The best next reads after this are Creating Your First Campaign for the end to end launch flow, Deliverability Overview to get the deliverability brain mental model, and Reply Intelligence for how the classification layer feeds the unified inbox.