Records and CRM

A CRM your agent can read, write, and explain

A CRM is only worth what it can prove. Every attribute records who wrote it, which run, and from which source, so an agent can update a record and you can still audit the change afterwards.

try
Start freeRead the docs

Most CRMs assume a human types and a manager reports. This one assumes an agent writes and a human audits. Companies, people, and deals carry typed attributes, relationships, a linked activity timeline, dedupe lineage, and provenance on every write, because a record an agent changed is trustworthy only when the change is legible.

The default model is opinionated on purpose. A person moves new, contacted, engaged, meeting, customer, with nurture and disqualified off-ramps. Deals run discovery through won or lost with stakeholder roles on each edge. Company lifecycle is derived from its people and deals until a human overrides it, and that override is recorded rather than guessed.

Example searches

Ask for it the way you'd say it

Each example is a request in plain words, with what it returns underneath.

  • The stale pipeline question

    which open deals have had no activity in three weeks and who owns each one

    The pipeline read groups by stage with counts and totals, and each deal links through to the timeline behind it.

  • Where did this value come from

    who set this company's headcount and which run wrote that number

    Field-level provenance names the source, the run, and the timestamp, down to a single attribute on a single record.

  • Clean up the duplicates

    find the companies we have stored twice and merge them without losing history

    Merges preserve lineage, so the surviving record still shows what the merged one contributed and when.

Plays

Three motions you can run this week

Each one is a chain of OXYGEN primitives — the same hosted objects your workspace already has, composed.

  • Promote work into truth

    A qualified list stops being a spreadsheet and becomes canonical companies and people with provenance.

    1. Tables
    2. Records
    3. Dashboards
    1. 1Finish the argument in a table, where rows are candidates and mistakes are cheap.
    2. 2Promote only the rows that survived, and let dedupe resolve them against existing records.
    oxygen tables promote

  • Backfill what the record is missing

    Thin records get filled from providers on a schedule, without anyone re-uploading a list.

    1. Records
    2. Observability
    1. 1Enable enrichment on the attributes that actually matter and leave the rest empty.
    2. 2Backfill existing records, then read the per-field cost and source afterwards.
    oxygen crm enrichment backfill

  • Let intent reorder the pipeline

    Accounts with a hiring or funding event surface above accounts that have simply been quiet.

    1. Signals
    2. Records
    3. Dashboards
    1. 1Record signals against companies so the timeline shows more than your own touches.
    2. 2Read the pipeline with recent events in view and work the top of it first.
    oxygen crm pipeline

Capabilities

What you get

  • Provenance on every write

    Each attribute records its source, run, and timestamp, whether a human, a promotion, or a provider wrote it. An agent editing records is safe because the edit is legible.

  • A stage model that ships working

    Person funnel, deal pipeline, and a derived company lifecycle come configured for early-stage B2B. Option sets stay customizable; the default is what most teams would build anyway.

  • Nothing silently disappears

    A merge keeps lineage: the duplicate fills the survivor's blanks, its links move over, and the merge is recorded. Deleting a row is separate and permanent.

  • One contract, three surfaces

    Assert, search, and update share a single API, so the web CRM, the terminal, and an MCP client do the same things with the same guards and the same audit trail.

Boundaries

What Records does not own

Records holds canon. It is not the workbench: sourcing, waterfalls, AI columns, and any list still being argued about belong to Tables, where a row is a candidate until promoted. Conversations are Messages, and the durable company knowledge behind your ICP is the Knowledge Graph.

Data sources

Data sources and CRM connections

  • People Data Labs

    Firmographic and person records for filling gaps on a company or contact that arrived thin.

  • Blitz API

    Profile and company reads that resolve a person to a real identity before the record is asserted.

  • Attio

    Syncs one way: OXYGEN writes records into Attio, and changes made there do not flow back.

  • HubSpot

    Syncs both ways with a connected HubSpot portal, through your own connection and its API quota.

  • PredictLeads

    Hiring and technology events attached to the company, so the timeline carries more than your own touches.

Use managed credits where available, or connect a supported provider key on an eligible paid plan. Your provider bills its calls; OXYGEN adds a per-call platform fee. Signed-in CRM connections such as HubSpot have no per-call fee. Connected sending accounts reserve monthly credits. See pricing and supported integrations.

Limits

Where this stops

  • The stage model is opinionated and customizable, not free-form. Changing the stage vocabulary is a migration with cell remaps rather than an inline rename.
  • Two gaps worth knowing: a stage edited in the web grid or the record panel writes no timeline activity today, so a move you need on the record should go through assert, and custom objects are scoped to the CRM domain rather than a general object graph.

FAQ

Questions people ask first

Is this a real CRM or a table with a nicer name?
A real one, and the boundary is enforced. Records hold canonical identity, relationships, activities, and the sync ledger; tables hold work in progress. A plain table only becomes a CRM object through an explicit operation.
Can I keep the CRM I already run?
Yes, if it is HubSpot, Attio, or Pipedrive. HubSpot syncs both ways, Attio one way from OXYGEN, and Pipedrive imports into Records. Writing out takes an approval, per sync run or once for a scheduled sync with credit and row caps. An Oxygent, OXYGEN's in-app AI agent, gives it for you when its chat is on Auto-approve.
What stops an agent corrupting my data?
Provenance first: every write names its actor and run, and merges keep lineage. Deleting a row is permanent. An Agent, a workspace AI worker you configure, asks before it deletes one. Your chat with an Oxygent starts on Auto-approve, so switch it to Ask for approval to confirm each delete.
How is a record different from a table row?
A row is a candidate you are still testing; a record is what the business believes. Promotion is the moment one becomes the other, and it is deliberate so a bad enrichment run cannot quietly rewrite canon.
Does the CRM itself cost credits?
No. Records, objects, relationships, activities, and pipeline views are unmetered on every plan, free included. Enrichment and AI steps draw credits, and so do a CRM sync's or import's steps and own-key calls, under its credit cap.
How are duplicates handled?
Identity keys catch most of them on write, and a duplicates view surfaces the rest for review. Merging is a first-class action that preserves lineage, so the surviving record can still explain where a value came from.

Run a crm your agent can read, write, and explain on your own workspace

Sign up, get a working workspace with a one-time credit grant, and run the first play from the web app, the CLI, or your AI assistant over MCP.

Start freeSee pricing