A CRM for people who won't use a CRM

Whoever makes the CRM fill itself in — and then tells the rep exactly what to do next, already prepared — takes the category.

Not because the AI is smarter. Because the human effort required drops to near zero, and adoption is the only metric that has ever mattered in CRM.

Three things are true at once

CRM data entry has never been solved. Every generation shares one failure mode: the record is only as good as the rep's willingness to update it, and reps do not want to update it. Forecasting, reporting, coaching and handoffs all sit on a foundation the business knows is unreliable.

Capture is now cheap. Transcription costs fractions of a cent per minute. Email and calendar APIs are mature. Meeting-bot infrastructure is buyable. Recording every interaction a sales team has is an engineering problem now, not a cost problem.

Reasoning over that capture is now possible. With a properly built memory layer, a model can answer why is this deal at risk from evidence rather than from a rep's half-remembered notes.

Where ORBIT sits

ORBIT is an independent product on its own codebase. It shares nothing with anything else we run — not code, not infrastructure, not a database. It receives leads and engagement data from whatever the customer already uses at the top of the funnel, and turns everything after that first touch into a system that runs itself.

Every upstream tool is a provider — a peer entry in a registry, integrated the same way, privileged in no way. OXO is one of them, alongside Smartlead, Apollo, Outreach, a form, a CSV or a raw webhook.

The wedge: nobody has to rip out Salesforce

The hardest thing about selling a CRM is that the customer already has one, and replacing it is a six-month project nobody wants to own. So ORBIT ships in two modes: as the system of record, or as a capture-and-intelligence layer that writes back into whatever they already run.

Mode B is the commercial wedge — it asks the customer to change nothing, produces the capture data that makes our AI good, and turns the eventual migration into a switch flip because by then we hold the entire history. Mode A is what that migration lands on, and it has to exist and be good on the day the first customer asks, or the wedge is a dead end rather than a door.

What transfers from the rest of the company

ORBIT is a separate codebase with separate infrastructure. Nothing carries over as software. What carries over is narrower and worth stating precisely, because overstating it would set the wrong expectation with this room:

Engineers who have already made these mistakes once will move considerably faster than engineers who have not — but that is experience, not inventory, and the estimates in chapter 16 do not assume a head start.

What it costs

This document specifies the product in full: six modules at depth, both modes, native mobile and a complete web application, the provider framework, the memory layer, the AI backbone and a separated analytics plane.

Built properly, that is a team of roughly twenty-two people and about eleven months to a commercially complete v1, with the first sellable release at month four.

Chapter 16 sets out the team shape, the phasing and a sensitivity table showing what the date does at six, twelve, twenty and twenty-two engineers. The scope in this document does not change across those rows — only the calendar does. Which row we operate on is a staffing decision, and it belongs to this room rather than to the specification.

The ask, in one line

Approve the scope, approve the team shape, and pick a row on the sensitivity table. Chapter 17.

The original sin

A CRM is sold to a VP of Sales as a system of record. It is experienced by a rep as unpaid administrative labour with no personal payoff. The rep does the typing; the manager gets the dashboard. That mismatch is the root cause of every CRM problem, and no vendor has fixed it — they have only added more fields.

The user we are designing for

We should be blunt about this internally, because it is the most important constraint in the document.

The target user will not read documentation, will not configure anything, and will not remember where a feature lives. They open the app, and if it does not immediately tell them what to do, they close it and go back to their inbox.

What follows: if a task requires the user to know what they want to do, we have already failed. This is not a niche concern — it describes the median salesperson, and it describes every salesperson on a Tuesday afternoon between two calls. Building for this user is the only genuine differentiator available in a category where everyone has feature parity.

What that means in practice

Reading Reevo carefully

Reevo is the sharpest expression of the thesis we are pursuing and should be treated as the benchmark. They are an AI-native revenue operating system combining native CRM, prospecting, engagement and deal intelligence, keeping the whole sales workflow inside one system.

Their core insight, which we should steal outright. No single tool sees the whole deal — a CRM nobody updates, a call recorder, an outbound tool — so each sees a fragment, and AI bolted onto a fragment is guessing. Their answer is that every call, email and deal feeds one shared memory, so the system drafts follow-ups, updates records and flags risk on its own. They frame that accumulated context as the most valuable thing a sales team creates.

Their resources. $80M from Khosla Ventures and Kleiner Perkins, explicitly to rebuild the GTM system from the ground up rather than bolt lightweight AI onto an existing product. SOC 2 compliant, ISO 27001 certified, three custom-quoted tiers.

Honest assessment. Well funded, credible, and roughly 18 to 24 months ahead on product surface. We will not beat them by matching feature for feature on their timeline. We beat them on four axes they cannot easily take, two of which conflict with their own positioning.

Where we win

Where we are structurally weak — say it out loud

• Capital and calendar. A competitor with eighty million dollars can run more parallel workstreams than we can. The counter is sequencing — being complete on a narrower promise before widening it — not working faster on the same surface.
• Compliance. Enterprise buyers ask for SOC 2 on the first call, and the observation window alone is months of calendar time. This caps deal size early and points the initial ICP at mid-market.
• No distribution advantage. Every customer is a fresh sale. Warm introductions help; they are not a channel.
• No owned enrichment data. We buy it at market rates, which shows up in gross margin (chapter 19).
• Category education cuts both ways. Buyers know what an AI-native CRM is — and they know the leaders' names.

The six modules are the visible surface, and they are thin. Build the platform correctly and modules become weeks of work each. Build modules first and retrofit the platform, and we ship a worse Pipedrive.

The activity spine

One immutable, append-only, normalised event log per workspace. Every provider writes here first; memory, actions, timeline, workflows and reporting all read from it.

• Transport: Kafka, partitioned by workspace_id so ordering is guaranteed per tenant and one heavy workspace cannot starve the rest. Replay is the property that matters most — when extraction improves, we reprocess history rather than only benefiting on new data.
• System of record: Postgres, queryable and joined to the domain entities.
• Analytics mirror: ClickHouse, fed by a consumer on the same topics (chapter 10).
• Late arrival is normal. A delayed webhook, a backfill on connect, a provider replaying a day. The spine stores occurred_at and ingested_at separately, and every derived artifact is recomputable rather than incrementally-only.

The full lead lifecycle — first touch, every email and call, every meeting, conversion, client data, churn — is a query against the spine filtered by entity. Building it as a log rather than as a UI feature is what makes lifecycle, reporting, memory and audit all fall out of one structure.

Tenancy

Row-level, with a workspace_id on every table, enforced by Postgres row-level security. The alternative — a schema per tenant — is defensible right up until you notice that neither the vector index nor the analytics store has a schema equivalent, at which point the product has two different tenancy models and the seam between them is where cross-tenant leaks are born.

Guarded by a mandatory CI test that fails any query lacking a workspace predicate, with physical database separation offered as an enterprise tier for customers who require it contractually.

Two data-model decisions worth arguing about

One Person, no separate Lead object. The Lead-versus-Contact split is a historical artifact that forces a lossy convert operation and confuses users. We model a single person with a lifecycle_stage, and map at the sync boundary when a downstream CRM needs the distinction.

Custom fields, typed and described. Every CRM dies without them, but unlimited custom fields destroy the AI layer — a model cannot reason over four hundred arbitrary columns. Typed fields with mandatory descriptions, where the description is fed to the model so it knows what the field means. A field the AI cannot understand is a field it cannot fill in, and tenet one says it must.

Identity resolution

The unglamorous component that decides whether the product feels magical or broken. If an email address, a name on a Zoom call and a phone number in a dialer log are three different people in our system, the timeline fragments and every AI output is wrong.

Deterministic match first — email, E.164 phone, calendar attendee ID, provider external ID — then domain attribution with a maintained exclusion list of free and ISP domains, then probabilistic match on name and company, then model adjudication for the residual ambiguous set only.

• Merges are always reversible via a merge ledger. Never destroy the losing record.
• Confidence-gated. High confidence merges automatically; medium queues a one-tap confirmation in the daily queue; low leaves records separate, because separate is recoverable and a wrong merge is a data-integrity incident.
• Job changes are an opportunity, not an error. A champion moving companies is one of the highest-value signals in B2B sales. Detect it and generate an item, rather than silently creating a duplicate.

Permissions, and why the AI must obey them

Roles across owner, admin, manager, rep and read-only, with record visibility open, team-scoped or owner-scoped per workspace. The part that is easy to get wrong:

The permission filter runs on the retrieval index, not on the output. Filtering after generation means the model already saw data the user is not allowed to see, and will leak it in paraphrase.

Alongside that: jurisdiction-aware recording consent shipped with the recording feature rather than after it; per-workspace keys for recordings and transcripts, with bring-your-own-key at the enterprise tier; and an erasure path that propagates through raw payloads, activities, facts, entity cards, embeddings, the analytics plane and any synced downstream CRM. Designed on day one, because retrofitting deletion through a vector index and a columnar store is among the most expensive mistakes available to us.

The notification budget

For this user, notification strategy is the product — a user who mutes us is a churned user who has not cancelled yet. One scheduled digest a day plus at most three event-triggered pushes, enforced centrally so no module author can add just one more. Only three things earn an interrupt: a meeting starting soon with its brief attached, a prospect reply on an active deal, and a post-call summary that is one tap from sent. If a user consistently ignores a class, we stop sending it and fold it into the digest — measured and automatic, with no settings screen.

The sync fabric

Native bi-directional Salesforce and HubSpot, with the long tail via a unified-API vendor. Field mappings auto-generated on connect by inspecting the customer's schema, because our user will not configure a mapping screen. Field-level conflict policy with a conservative default: ORBIT writes activities, summaries and enrichment freely, and proposes but never silently overwrites a human-edited deal field. Overwriting a rep's close date on day one is how we get uninstalled.

Backfill on connect is what produces the first ten minutes of value: the customer connects their CRM and immediately sees a populated, intelligent timeline of a deal they already know — proof the system works, using their own data.

Every source of data — a funnel tool, a mailbox, a calendar, a meeting bot, a CRM, a raw webhook — is a provider. Providers are declared, not coded. This is the single highest-leverage piece of architecture in the product, because the count of providers we support is a direct commercial input and a direct engineering cost, and the framework is what decouples the two.

The central argument

Most systems treat webhooks and polling as alternatives: use webhooks if the provider offers them, fall back to polling if not. That is wrong, and it fails in production in a way that is very hard to debug later.

Webhooks give you latency. Polling gives you truth. A provider integration that has only one of them is either slow or quietly lossy — and quietly lossy is worse, because the memory layer will confidently report that nothing happened.

Webhooks are best-effort by construction. Deliveries are missed during our own deploys and outages. Providers drop them under load, cap retries, silently disable endpoints after consecutive failures, and occasionally ship bugs that stop emitting an event type entirely. None of those failures announce themselves. Polling with a cursor, by contrast, is self-healing: whatever was missed is picked up on the next sweep, because the cursor never advanced past it.

So the recommendation is a hybrid by default: webhooks for freshness where a provider supports them, plus a lower-frequency reconciliation poll that exists purely to catch what the webhooks lost. Because every write is idempotent, the overlap costs nothing but a few wasted comparisons.

A provider is a manifest, not a module

With two engineers, the cost of the tenth provider matters more than the cost of the first. So a provider is declared as data — capabilities, auth, endpoints, rate limits, pagination style — plus one small mapper function per resource type. The framework does everything else.

Target: a new provider is a manifest, a mapper and a fixture-based test — two days of work, not two weeks. Everything else in this chapter exists to make that number true.

The webhook path, specified

• One endpoint shape: /hooks/:provider/:connection_token. The token identifies the connection without a database lookup on an unauthenticated path.
• Verify before parse. HMAC comparison in constant time against a per-connection secret, using the raw request body — not a re-serialised object, which is a classic source of signature mismatches.
• Replay protection. Reject payloads whose signed timestamp is outside a few minutes, and cache seen event IDs briefly.
• Acknowledge fast, process later. Persist the raw payload, enqueue, return 200 — target under 100 ms. Processing inline means a slow model call causes the provider to time out, retry, and eventually disable our endpoint.
• Never trust order. Webhooks arrive out of sequence and duplicated. Ordering comes from occurred_at in the payload, and from a version or etag per entity where the provider supplies one. A stale update must lose to a newer one already applied.
• Per-connection queue partitioning so one noisy tenant cannot starve the rest.
• Secrets are rotatable with an overlap window where both old and new validate.
• Everything fails to a dead-letter queue with the raw payload attached, visible in an operator view. A silent drop is the one outcome the design does not permit.

The polling path, specified

• Cursor per connection per resource, persisted transactionally with the batch it describes.
• Advance only on complete success. Partial page sets do not move the cursor; a crash mid-run replays from the last good position.
• Overlap window. Always rewind a few minutes behind the stored cursor. Providers whose cursor derives from a client clock, or who commit records slightly after timestamping them, will otherwise drop records permanently into the gap. Idempotency makes the re-read harmless.
• Adaptive interval. Poll frequently when a connection is producing, back off when it is quiet — bounded between roughly one minute and one hour. Most connections are idle most of the time, and this is what keeps the polling bill and the rate-limit pressure low.
• Rate-limit awareness as a first-class concept. A token bucket per connection and per provider globally, because many providers quota per application rather than per customer. One large tenant must not exhaust the app-wide quota and stall every other workspace.
• Jitter every schedule. Without it, every connection fires on the hour boundary and we build our own thundering herd.
• Backfill is a separate mode: bounded, resumable, checkpointed, and on a lower-priority queue so historical import never delays live traffic.

Choosing the mode per provider

Delivery semantics, stated once

Both paths are at-least-once. Exactly-once delivery does not exist across a network boundary, and pretending otherwise produces bugs that surface months later as duplicated activities. Instead we make every write idempotent and get effectively-once behaviour:

• Every envelope carries dedupe_key = provider : connection : external_id, or a canonical payload hash when the provider gives no stable identifier.
• Writes are upserts on that key, with a monotonic version guard so a replayed older payload cannot overwrite newer state.
• Side effects that are not naturally idempotent — sending mail, creating a downstream CRM record — are keyed on the same value and checked before execution.

The connection state machine

Gap detection — the part most teams skip

Because the memory layer's credibility depends on completeness, absence of data has to be treated as a signal rather than as an absence of signal. Three mechanisms:

• Expected-cadence alarms. Each connection learns its own baseline. A mailbox that normally produces forty events a day and has produced none since morning is degraded, whatever the API says.
• Reconciliation counts. The sweep compares what the provider reports existing in a window against what we hold for that window. A persistent discrepancy is a bug in a mapper or a lost event type, and it surfaces as an operational alert rather than as a customer complaint six weeks later.
• Coverage as a user-visible number. Each account shows what we can and cannot see. When the answer to a question is genuinely unknown, the product says I have no visibility into their WhatsApp thread rather than implying nothing happened. Tenet seven applied to capture.

Mail and calendar: the one place to consider buying

Gmail and Microsoft Graph are each a substantial integration to do properly — push channel renewal, quota behaviour, threading semantics, delta tokens, historical backfill, and the long tail of tenant-specific admin configurations. Doing both well is a meaningful fraction of a year for a dedicated engineer, and it is undifferentiated work: no customer chooses us because our Graph integration is elegant.

The recommendation is to buy a unified mail and calendar vendor to reach coverage early, and build the Google path natively in parallel once the product is proven. Because both are manifest entries, the switch is a configuration change and nothing above the normaliser moves. That substitutability is precisely why the framework is built first — it converts a strategic build-versus-buy argument into a reversible operational one.

AI is not a layer in this system. It is the column every other layer calls through — and that only works if every task is declared, versioned and measurable rather than scattered as prompt strings across a codebase.

The AI task registry

Every AI operation in ORBIT — "summarise a call", "extract commitments", "classify a reply", "draft a follow-up", "score deal risk", "narrate a report" — is a registered task. A task is a first-class database record, not a constant in application code.

What the registry buys us

The ready-state model

The second half of the backbone is a state machine that every AI-produced artifact moves through — a drafted email, a proposed stage change, a suggested meeting slot, an extracted commitment, a generated report narrative. This is what tenet three means concretely.

Why this is architectural rather than cosmetic. Making ready an explicit persisted state, rather than an implicit consequence of a user tapping a button, gives us four things at once: a single audit trail of who cleared what; a uniform undo boundary; a place to attach the autonomy tier per task class; and a clean measurement point for the metric that matters most — the share of drafts approved without edit.

Model routing and cost control

• Route by job class, not by preference. The overwhelming majority of calls are extraction, classification and summarisation, and belong on a cheap tier. Frontier models are reserved for deal-risk reasoning, the Ask interface, and anything a customer reads as an opinion.
• Prompt caching on entity cards. Cards are stable between updates and sit in the prefix of nearly every prompt, so caching them cuts inference cost materially.
• Batch API for everything non-interactive — nightly action generation, re-extraction, backfills. Typically around half price.
• Per-workspace budgets with alerting, enforced by the registry, so a single heavy tenant cannot quietly consume the month's margin.
• Graceful degradation. Provider outage triggers the declared fallback; if all fail, the queue serves yesterday's precomputed items with a staleness marker. Never a blank screen.

Why naive retrieval fails

The obvious approach — embed every email and transcript, retrieve top-k on a query — produces a good demo and then fails in production, predictably:

• Recency and truth conflict. A price quoted in January and a different price quoted in June both retrieve well. Nothing tells the model that June supersedes January, so it averages two contradictory facts into a confident wrong answer.
• Transcripts are terrible retrieval units. A 45-minute call is eight thousand tokens of conversational noise. Chunk it and you retrieve fragments without context; embed it whole and it matches everything weakly.
• Aggregation questions fail entirely. "Which deals are at risk this quarter?" is not a retrieval problem. No amount of top-k returns the right answer.
• No sense of the account as a whole. "What is the state of Acme?" needs a synthesised view, not five loosely relevant chunks.

The answer is layered memory, where each layer answers a different class of question, and a router that decides which layers to consult.

Written forever

The memory layer is append-only. Nothing is ever overwritten or deleted in the course of normal operation — only superseded.

When a new fact contradicts an existing one, the old fact is marked superseded_by and stays in place. Retrieval defaults to current truth, but the history remains queryable. That single design choice gives us three things a mutable store cannot:

• "When did this change, and why?" becomes answerable — which is exactly the question a sales leader asks when a forecast moves.
• Contradiction becomes a feature. When a new fact conflicts with a high-confidence existing one, that conflict is worth surfacing: your champion said budget was approved; the CFO said it was not. No CRM produces that today, and it falls out of supersession for free.
• Every past answer stays explainable. If the system said something last month, we can reconstruct what it knew at the time.

The only exception is a lawful erasure request, which propagates through every layer including embeddings and the analytics store. That path is designed on day one, because retrofitting deletion through a vector index and a columnar database is one of the most expensive mistakes available to us.

Read always

The complement of forever-written is always-read. No AI task generates without first consulting memory. There is no code path where a draft is written from the immediate context alone — the entity card is in the prompt, the relevant facts are retrieved, and the citation chain is attached, every time. A task that skips memory is a task that will eventually contradict something the customer told us, which is the fastest way to lose their trust.

What a fact looks like

Retrieval

Where the embeddings live

Recommendation: pgvector, in the same Postgres as the system of record. Phase-one volume is low millions of vectors, well within range, while our filtering needs — entity, date, permission — are complex. That is precisely pgvector's sweet spot, and it means one tenancy model instead of two, with facts and their embeddings written atomically. Migrate behind an interface later if volume demands. Do not add a stateful service in month one to solve a year-three problem.

Memory hygiene

• Poisoning. A hallucinated extraction written into L2 persists and contaminates every future answer. Schema validation, confidence flooring, corroboration for high-impact facts, and a nightly consistency sweep.
• The correction path is our best asset. A user must be able to mark any surfaced fact wrong in one tap. That writes a high-confidence human-asserted fact that supersedes — and feeds the eval set for the registry task that produced it. Every annoyed user becomes a labeller.
• Sensitivity tagging. Personal, HR and legal content detected during extraction is excluded from general retrieval and from L4 aggregation.

This is the product. If a user opens ORBIT and sees a small, correct, ranked list of things to do, each already prepared, we win. Everything else is supporting infrastructure.

What an action is

A system-generated, ranked, expiring item with a precomputed payload, sitting in the drafted state and one gesture from ready. Four properties, checked at generation:

Precomputed, never live

A nightly batch regenerates the queue per workspace in local time before working hours, using the batch API at reduced cost. Event triggers — a reply arrives, a call ends — recompute affected items within about sixty seconds. Re-ranking as the day passes is cheap and deterministic, with no model call at all.

The feedback loop

If any action type drops below thirty percent acceptance, it is automatically demoted out of the default queue pending review. The queue polices itself; we do not wait for a customer to complain.

This is an architectural separation, not a module boundary. The application that serves the rep's queue and the system that answers "what is our win rate by segment this quarter" have opposite access patterns, opposite failure tolerances and opposite scaling curves. Coupling them means a manager running a heavy report degrades a rep's screen — and that is exactly the failure that gets a product uninstalled.

Store choice: ClickHouse

Both Postgres and ClickHouse could carry this. The recommendation is ClickHouse, for four reasons specific to us:

• The team has run it at scale before. The operational knowledge exists in the company even though the code does not, which materially de-risks introducing a second store.
• The access pattern is columnar. Reporting scans a few columns across millions of activity rows. That is the query shape ClickHouse is built for and the one Postgres degrades on.
• Materialised views are native and incremental, which makes the hourly refresh cheap rather than a full recompute.
• Isolation is physical. A separate cluster means an expensive report cannot consume connections or IO from the application database. With a read replica of Postgres you get isolation of reads but you still share the write path and the schema.

The trade-off, stated honestly: a second store means a second tenancy enforcement point, a second migration story, and eventual consistency between what the record says and what the report says. The hourly cadence and the visible as-of stamp are how we make that consistency gap explicit rather than confusing.

Why hourly, and not real-time

Real-time analytics is a tempting default and the wrong choice here. Three arguments:

The semantic layer sits inside this plane

Between the data and every consumer — dashboards, scheduled reports, and the plain-language Ask interface — sits a governed metric layer. Every metric is defined once, in code, versioned and tested: pipeline coverage, win rate, cycle time, stage conversion, quota attainment.

The naive alternative is text-to-SQL over the raw schema. That approach hallucinates joins, silently miscounts on one-to-many relationships, and produces different answers to the same question asked twice. Text-to-metric over a governed layer is a bounded, verifiable problem — the model selects metrics, dimensions and filters from a finite validated set, and never authors SQL. This one decision is the difference between a reporting module a CFO trusts and one they do not.

What runs on this plane

Module one

Lead management

Take a person from exists to qualified and in pipeline with the minimum possible rep decision-making, and never let a lead go cold through inattention.

Leads arrive from any connected provider and are treated identically once past the ingestion contract. Auto-enrichment on arrival from a bought enrichment provider plus web signals means the rep never sees an empty record — title, seniority, department, company size, funding, tech stack, all present before the rep looks.

Qualification with reasons. A score alone is useless. "Matches your ICP on size and industry; the title is one level below your typical buyer; they opened the pricing page twice this week" is actionable. The ICP model is learned from the workspace's own closed-won history, not configured in a form.

Intent-classified inbound. Replies classified as interested, objection, not now, wrong person, unsubscribe or out-of-office, each with the right next item pre-drafted and waiting in the queue. "Not now" auto-schedules a dated revisit rather than dying.

Decay detection. A lead past a learned inactivity threshold generates a re-engagement item with a drafted message — or an explicit one-tap disqualify, because a clean pipeline is worth more than a large one.

Module two

Pipeline management

Make the pipeline reflect reality without a rep maintaining it, and make risk visible before the deal is lost rather than at the quarterly review.

Self-updating records. Stage changes, close-date shifts and next steps are drafted from conversation content, each with a citation, and sit in the queue awaiting approval. High-confidence, low-risk updates may move to ready automatically with a visible undo once a workspace has earned that autonomy tier.

Relationship mapping builds an inferred org chart per account from thread participation, meeting attendance and reply patterns — surfacing the gap that matters: you have no relationship with the person who signs.

Evidence-based forecasting. Commit, best case and pipeline derived from signals, presented alongside the rep's own call with the delta explained. We do not replace the rep's judgment; we make the disagreement visible and reasoned, which is what a sales leader actually wants.

Module three

Meeting management

Walk into every meeting fully prepared without preparing; walk out with the record updated, commitments captured and the follow-up ready to send.

Extraction priorities, in order: commitments with dates and owners — the highest-value extraction in the entire system — then objections and competitor mentions, sentiment trajectory, talk-ratio for coaching, and deal-field proposals. The follow-up is drafted in the rep's own voice, learned from their sent mail.

Module four

Workflow management

Let a team encode how we sell here once, and have it run reliably — without anyone learning a workflow builder.

Visual builders are powerful and used by approximately nobody outside RevOps. But letting the model decide what to do at runtime is unacceptable for a system that emails customers and mutates records: non-deterministic, unauditable, untestable. The resolution is the key architectural line in this module.

The model authors and explains the workflow. Deterministic code executes it. The model runs at execution time only inside explicitly marked content-generation steps, and each of those is a registered task.

Optimise for the template gallery, not the authoring canvas. Ship twenty to thirty curated templates — stalled-deal nudge, post-demo follow-up, no-show recovery, champion-departure alert, renewal at T-90, unworked-lead SLA. Most customers will never author a workflow; they will activate three templates.

Module five

Reporting

Deliver numbers a sales leader will defend in a board meeting. Correctness and consistency matter more than flexibility — which is why reporting runs entirely on the analytics plane described in chapter 10, against governed metrics, on the hourly cadence, with a visible as-of stamp.

The library covers pipeline, forecast, activity, conversion funnel, rep leaderboard, source attribution and cohort retention, with scheduled delivery to email and Slack carrying an AI-written narrative alongside the numbers, and drill-through from any figure to the underlying records and ultimately to the source call or email.

On mobile, reporting is a manager surface and shows three headline numbers, the direction of travel, and what changed and why in one sentence with a link to the evidence. A briefing, not a shrunken dashboard. On the web it is the full instrument.

Module six

Analytics

Answer questions nobody thought to ask, and surface things nobody thought to look for.

What v1 deliberately excludes

Campaign management and outbound sequencing, which belong to the connected source tools. CPQ, quoting and e-signature. Support ticketing. ERP and finance integration. Partner and channel management. Field service. Commission management. Stated plainly so nobody assumes otherwise.

Mobile-first is a statement about sequence and priority, not about scope. It means the rep's daily loop is designed for a phone before anything else is designed at all — because that is the loop that decides whether the product is adopted. It does not mean the web is an afterthought. The web is where the depth lives, and a large part of the buying decision happens there.

The mobile principle

The rep's entire day in ORBIT should be completable in under three minutes, standing up, one-handed, without typing.

If that sentence is true, the product wins on adoption regardless of feature parity. Every mobile design review asks whether a change moves us toward it or away from it.

Mobile: four tabs, six gestures

Six gestures, consistent everywhere, no exceptions: swipe right to approve, swipe left to snooze, long press to dismiss, tap to expand with the evidence, hold the mic to speak, pull down to refresh. Consistency is what lets a disengaged user become fluent without ever learning anything.

Voice is the input method on mobile

Typing on a phone is the friction that kills mobile CRM, so typing is not the input method. Hold the mic and say: "just got off with Meridian, they want a security review before signing, Priya is bringing in their CISO next week." The system drafts a note on the deal, a new contact, a commitment, a stage change and an email to Priya — each individually approvable. One utterance, five record updates, zero keystrokes.

The web console is a real product

Three groups spend most of their time here, and none of them are served by a phone:

• Managers reviewing pipeline across a team, running forecast conversations, and reading the analytics plane at full resolution.
• RevOps and admins configuring pipelines, mapping fields on a CRM connect, authoring and dry-running workflows, managing roles and autonomy tiers.
• Reps doing focused work — reviewing a call with the transcript and playback alongside the record, working a list in bulk, writing something long.

The web also carries a commercial job. The buyer is usually the sales leader, and they evaluate on a laptop. A mobile-only demo can lose a deal to a competitor with a richer desktop surface even when our product is better for the people who use it daily. So the console must be credible and complete, not a settings page with a logo on it.

The call-recording constraint, stated honestly

Recommendation: in-app dialer as primary, built on Twilio Voice, with automatic post-call voice-memo prompting as the universal fallback. Meeting capture has no equivalent constraint and covers most high-value conversations anyway.

Technical approach

React Native with Expo for mobile: one codebase, over-the-air updates — critical when we are iterating on the queue weekly — and a hiring pool we can staff from. Native modules for telephony, push, background sync and secure storage. Offline-first, with the queue and entity cards cached locally and approvals queued optimistically. React and TypeScript on the web against the same API. Cold start to interactive Today under 1.5 seconds; approve-to-confirmed under 300 milliseconds perceived. Full screen-reader support and 44-point touch targets throughout.

Latency budgets, treated as service objectives

Sizing assumptions for year one

Five hundred workspaces, roughly ten thousand seats. About two hundred activities per seat per day gives two million events a day — trivial for ClickHouse, comfortable for Postgres with time-based partitioning. Twenty hours of calls per seat per month is two hundred thousand hours a year of transcription. Fifty to two hundred thousand vectors per workspace puts us in the low tens of millions overall, within pgvector's range.

What must happen when things fail

Five practices this system does not work without

1. Tenant-scoping tests in CI that fail any query without a workspace predicate — in both planes.
2. Registry-only AI calls. A prompt string in application code fails review.
3. Replayability. Any derived artifact reconstructible from raw.
4. Per-workspace feature flags on every AI behaviour, so a misbehaving task is disabled for one customer in seconds.
5. Cost attribution per workspace and per task emitted as a first-class metric from day one, not reconstructed from provider bills later.

The specific failure we must never have

If the system tells a rep "you promised them a 20 percent discount" and no such promise exists, and the rep acts on it with the customer, we have caused commercial damage to our customer.

The control: commitment extraction requires a verbatim transcript span, the span is stored, and the interface always exposes play the moment. A commitment without a playable source is never surfaced. A hard product invariant, not a guideline.

Layered hallucination controls

1. Retrieval-grounded generation only. Tenet five — no task generates without reading memory first.
2. Mandatory citation, enforced in code. A prompt saying "please cite your sources" is not a control.
3. Schema validation on every registered task. Malformed output is repaired, retried, then quarantined — never silently written into memory.
4. Confidence thresholds per task class. Below threshold, the system asks rather than asserts.
5. The ready-state. Nothing customer-facing leaves the system without passing through it.
6. Abstention is a valid, rewarded output. "I do not have enough information about this account" must be trained and evaluated for. A system that always answers is a system that sometimes lies.

Evaluation infrastructure, built in phase one

• A golden dataset per registered task — commitments, stage inference, sentiment, entity resolution, intent. Around two hundred human-labelled examples each, growing from production corrections.
• Every prompt version runs its suite before rollout. Regression on any metric blocks the change.
• Staged rollout per task, with automatic rollback on a metric drop.
• Production sampling. A fixed percentage of live outputs reviewed weekly by a human. Offline evals drift from reality within weeks.
• User corrections are the primary eval source, routed back to the specific task that produced the wrong output.

Even fully staffed, engineering time is the scarcest resource in the company. The test for every line below is not "could we build this" — we could build all of it — but "does building it make the product better in a way a customer would notice, or does it just make us the owners of more code."

Two principles behind the table

Own the capture path, rent the media plumbing. Coverage is tenet ten and it is where the product lives or dies, so the framework, the Google path and the CRM sync are ours. Bots, transcription and carrier minutes are interchangeable inputs, and owning them would buy nothing a customer can perceive.

Own anything the model reasons over. Memory, the registry, the semantic layer and the scoring models all shape what the system says to a customer. Renting any of those means renting our own quality ceiling.

How we stay able to leave

Buying creates dependency, and dependency is a real risk when a vendor changes pricing, degrades, or is acquired. Four rules keep the exits open:

• Every vendor sits behind our own interface. Mail and calendar are provider manifests. Transcription and inference are registry entries. Meeting bots are a capture adapter. Nothing above those boundaries names a vendor.
• We keep the raw artifacts ourselves. Payloads, recordings and transcripts land in our own object storage. If a vendor disappears tomorrow, the history is ours and the memory layer is rebuildable.
• No vendor holds the primary record. Their output is an input to the spine, never the source of truth.
• Each dependency has a named alternative written down before we sign, so the replacement conversation starts from a shortlist rather than from panic.

This chapter does not change the scope to fit a team. It prices the scope, and shows the calendar consequence of each staffing choice, so the trade is made deliberately in this room rather than implicitly by whoever is available.

The work, sized

Estimates are in engineer-months for a competent engineer familiar with the domain, including tests, instrumentation and the operational work to run the thing — not just first-pass implementation. They assume no code carries over from anywhere.

Roughly 235 engineer-months with drag included. That is the price of the product described in this document — not an opening bid, and not padded.

The team that delivers it

What the date does at different staffing levels

The scope is identical across every row. Only the calendar and the parallelism change. Small teams lose less to coordination but cannot run workstreams concurrently; large teams run more at once but pay a widening coordination tax, and past roughly twenty-five people on a codebase this coupled, added engineers stop buying much time.

Phasing at the recommended row

Phase zero · months 1–3 · Foundations and the framework

Deliberately shaped for a small team, because this is when hiring is still running. Tenancy, schema, RLS and the CI scoping test; the provider framework end to end; the activity spine; identity resolution; the first four providers; and the timeline view a design partner can react to.

Exit: five partners connected across at least three different funnel tools; capture coverage above ninety-five percent; backfill under ten minutes; no silent gaps over a two-week observation.

Phase one · months 4–6 · The thesis, live and sellable

The AI registry and ready-state; memory L0 to L3 with the citation gate; the action engine and the Today screen; meeting capture and the ninety-second post-call loop; mobile v1 on both platforms; Mode B two-way sync; the eval harness. This is the first sellable release.

Exit: daily action completion above fifty percent; call-end to ready follow-up under ninety seconds at p95; commitment extraction precision above ninety percent; first paying customer.

Phase two · months 7–9 · Depth and both modes

Lead and pipeline modules at full depth; Mode A as a system of record, with the CRUD surface, custom fields and pipeline configuration; the workflow module including natural-language authoring and the deterministic execution engine; the analytics plane and the reporting module; ten to fifteen providers.

Phase three · months 10–11 · Intelligence and enterprise

Predictive scoring and forecasting; organisational memory; autonomy tier three for low-risk classes; coaching surfaces; SSO, SCIM, audit, residency and SOC 2 observation underway.

Unit economics

Per active seat per month, at twenty hours of calls, four hundred emails and forty meetings:

Thinner than a platform that owns its enrichment data, and honestly so: we buy enrichment and meeting infrastructure rather than owning them. The price point sits higher to compensate, which is defensible for a product that removes a rep's administrative hour every day.

A schedule tells you when work happens. A build order tells you what breaks if it happens in the wrong sequence. The second is more durable, because it survives every change of date, and it is what lets several people work at once without discovering in month six that two of them built on top of a contract that was never agreed.

The one-sentence version

Contract before intake. Intake before meaning. Meaning before judgement. Judgement before surface. Everything else is parallel.

The critical path

One chain runs the length of the project, and every week lost on it is a week lost overall:

tenancy → activity envelope → provider framework → spine → identity resolution → extraction → facts → entity cards → retrieval → action engine → Today screen → the post-call loop.

Nothing else is on it. Modules, reporting, Mode A, the workflow engine, the analytics plane and the second surface all hang off this chain and can be staffed in parallel the moment their upstream interface is stable. When staffing is scarce, it goes here first; when a decision is blocking, this is the chain to unblock.

Four dependencies that look real and are not

These are the ones that cause teams to serialise work they could have run at the same time, and they are worth naming explicitly because the instinct is wrong in every case.

Ten orderings that must never be inverted

Each of these has a specific failure attached. They are cheap to honour and expensive to retrofit, which is the definition of an architectural decision.

Module-by-module build strategy

For each module: what it waits on, the order to build it in, and the thinnest slice that proves it works. The slice matters — it is what goes in front of a design partner before the module is finished.

Meetings — build first among the modules

Waits on: calendar provider, meeting-bot adapter, transcription task, identity resolution, extraction, entity cards, ready-state.
Order: calendar sync and meeting lifecycle → bot joins and recording lands in object storage → transcription with diarisation → speaker-to-contact mapping → summary → commitment extraction with source spans → drafted follow-up → the ninety-second notification loop → prep briefs.
First slice: one recorded meeting producing a summary and one correctly extracted commitment with a playable span.
Why first: it is the demo that sells the product, and it exercises every layer of the platform end to end. If meetings work, the platform works.

Leads

Waits on: provider framework, canonical entities, enrichment vendor, extraction.
Order: ingestion and dedupe → enrichment on arrival → lifecycle stages → reply intent classification → drafted first response → decay detection → assignment rules → learned ICP scoring last, because it needs closed-won history the workspace does not have on day one.
First slice: a lead arrives from a funnel provider, is enriched without human input, and produces one drafted response in the queue.

Pipeline

Waits on: canonical entities, CRM sync for Mode B, stage history, extraction.
Order: deal entity and immutable stage history → sync in from the customer's CRM → drafted field updates from conversation content → the cheap risk signals that need only the spine (no next step, silence, slipped dates, single-threading) → relationship mapping → forecasting last, because it depends on every signal above it being trustworthy.
First slice: a deal whose stage change was proposed from a call, with a citation, and approved in one tap.

Workflows

Waits on: spine events, ready-state, action engine, registry.
Order: execution engine first, authoring second. Trigger taxonomy → deterministic evaluator → idempotent steps with per-entity locks → dry run → execution trace → blast-radius limits and kill switch → template library → natural-language authoring and the compiler → the match-count preview.
First slice: one hard-coded template — stalled deal produces a drafted check-in — running reliably with a visible trace.
The trap: building the authoring experience before the engine. Authoring is the demo; the engine is the product, and an authoring UI over an unreliable engine produces automations customers cannot trust.

Reporting

Waits on: analytics plane, semantic layer.
Order: activity mirror → the hourly spool → metric definitions in code with tests → as-of stamping → the standard report library → scheduled delivery → drill-through to source records.
First slice: one metric — pipeline coverage — defined once, computed hourly, rendering identically in a report, a scheduled email and an Ask answer.

Analytics

Waits on: reporting, memory retrieval, feature tables.
Order: Ask over the semantic layer for aggregate questions → Ask over memory for entity questions → the router that chooses between them → proactive rule-based insight → feature engineering during the spool → predictive models → calibration, published in-product → organisational memory last, because it needs volume rather than code.
First slice: one question — which deals are at risk this quarter and why — answered from the semantic layer and memory together, with citations.

Where the parallel tracks are

Once the envelope contract is agreed and the provider framework has a stable interface, five tracks run concurrently and touch each other only through published contracts. This is the shape the team is staffed against in chapter 19.

What "done" means for a building block

A block is not finished when it works. At this level of coupling it is finished when the next block can be built on top of it without archaeology:

• Its interface is published in the contracts repo and versioned.
• It is instrumented — throughput, latency, error rate and, for AI blocks, cost and quality.
• It fails visibly — a dead-letter path, a health field, or a degraded state a human can see.
• It has a replay or rebuild path where it derives anything, so a bad version is recoverable rather than permanent.
• It has one page of written reasoning — what it does, what it deliberately does not, and which decision it encodes.

Repository strategy

Three options, and the choice matters more than it looks, because the thing being shared across every codebase is the activity envelope and the API contract — and contract drift between five repositories is a slow, expensive class of bug.

Recommendation: a hybrid. One server-side monorepo where coupling is genuinely high, one contracts repository that every other repository depends on and none of them may bypass, and separate repositories for the clients and for anything with its own release cadence.

The repositories

Three boundary decisions worth arguing about

Why provider manifests live inside orbit-platform rather than in their own repository. They are tightly coupled to the framework's execution semantics, and splitting them creates a version-matrix problem for no gain while we are the only authors. The important property is not repository separation but deployment separation: manifests and mappers load from a versioned artifact, so fixing a broken mapper does not require a full platform deploy. If third parties ever contribute providers, that is the moment to split.

Why prompts live in orbit-ai rather than in their own repository. A prompt without its output schema, its eval suite and its fallback chain is not a reviewable unit. Keeping them beside the registry runtime means a prompt change and its eval run in the same pull request. The active version is a registry row in the database; the repository is the source of truth and the review surface.

Why analytics is separate from platform. Different language, different release cadence, different failure tolerance, and a different owner. A metric definition change should not run the platform's test suite, and a platform deploy should not risk the reporting plane.

Datastores

Six stores, each with a stated job and — more usefully — a stated non-job, because the failure mode here is data quietly ending up in the wrong place.

Two store decisions people will ask about

Keyword search. Hybrid retrieval needs a lexical half, and vectors are weak on names, product terms and numbers. Start with Postgres full-text search rather than standing up OpenSearch — it is adequate at our early corpus size and it is one fewer stateful service. The trigger for moving is measurable: when lexical recall on entity names becomes the limiting factor in retrieval quality evaluations, not before.

The job queue. Kafka carries the spine; it should not carry application jobs. Retries, scheduling, priorities and visibility are different problems, and conflating them makes both harder to reason about. A Redis-backed queue for application work, Kafka for the event log, and a clear rule about which is which.

Data residency

Every store above is regionally deployable, and the tenancy model — one workspace_id partition key across Postgres, pgvector and ClickHouse — is what makes a regional split tractable rather than a rewrite. If the geography decision in chapter 19 lands on a market with residency requirements, the shape is a full stack per region with a shared control plane, and it is far cheaper to design for now than to retrofit.

What gets stood up first

In dependency order, matching chapter 17: Postgres and object storage on day one; Redis with the first worker; Kafka when the second consumer appears, because a single consumer does not justify a broker; ClickHouse when the analytics track starts, which is as soon as the envelope is agreed. Nothing is stood up speculatively — each store arrives with the first workload that genuinely needs it.

Top risks

What would make us stop or change course

• Design partners connect providers and read the timeline, but never approve items from the queue — the action engine thesis is wrong, and we have built an expensive activity log.
• Capture coverage plateaus below eighty-five percent for structural reasons — the memory layer cannot be trusted, and everything rests on it.
• No paying customer within two months of the phase-one exit — enough slack for ordinary slippage, not enough to hide a wrong thesis.
• Cost per seat stays above thirty-five dollars after the levers, at a price the market will not pay.

Ten decisions this room owns

A · Core data model

B · Competitive matrix

C · Metric tree

North star — daily action completion rate: the share of surfaced items approved or marked ready the same day. Target 60 percent.

It simultaneously proves the items are correct (users trust them), useful (worth doing) and easy (low enough friction to finish). It cannot be gamed by surfacing more items, because it is a rate.

D · Vocabulary

End of specification · v0.4 · Chapter 17 requires decisions before architecture is finalised