Agent activity & receipts

Read a send attempt

Activity can open a specific outbound send attempt here. The record shows provider acceptance or the reason sending was not confirmed, its recorded time, and the provider message identifier when one exists. Provider acceptance is not proof that the recipient received or read a message. The existing account receipt chain remains available below.

Each send also records the message identifier the mail carried, the run that wrote the draft and the recipient, so a reply that arrives weeks later can be traced back to where it came from. That identifier is the one the recipient's mail client quotes back, so the link survives the round trip.

A reply is read for what it says as well as for whether a person sent it: interested, not interested, pointed at somebody else, ask again later, or unclear. That reading is deterministic and runs no AI, because it decides whether you are asked about a reply and never what is sent, so being wrong costs a moment's reading. Unclear is the default and the honest answer for the many replies that could go either way.

A reply that reads as interested offers to open an opportunity for that account on its Campaigns ledger row, carrying the draft, the run and the send behind it. You confirm it; nothing is written until you do. The opportunity opens with no amount and no close date, so it does not count itself as qualified on the admin funnel until you fill those in. Confirming the same reply twice updates the same record and overwrites nothing you entered, including an amount or a close date you added yourself.

A reply that points at somebody else asks you who to write to next. The address is never taken from the reply itself: the next person comes from your own contacts or from you. Anyone the message was forwarded to can write a sentence in it, so a reply is treated as a signal about what to ask you, never as an instruction about who to contact.

Overview

When an agent updates a CRM, drafts outreach, or enriches a record on your behalf, it leaves a receipt. A receipt binds four things: the action, the data used, the why (the playbook citations it was grounded in), and the outcome. /receipts shows that chain, newest first.

Scoped to your account. Payloads are redacted before display: secret-like keys are masked and nested records are reduced to their shape, so no raw customer data is exposed in this view.

What it shows

• Each touch. Timestamp, the provider + action (e.g. salesforce · opp.update_stage), an applied / failed / held for review / outcome unknown badge, and the origin (a brain recommendation, a manual action, or a cron).
• The vendor's receipt. A CRM write to HubSpot, Attio, Pipedrive or Salesforce shows the record id the CRM answered with, the status it sent (for example updated 200 or created 201), and the revision or modified time when the CRM sends one. Salesforce answers an update with no body, so its revision appears once the hourly check has read the record.
• Outcome unknown. A CRM write whose answer was lost is never sent again. Once it is a few minutes old, an hourly check reads the record back. When every value the write intended is there, the touch changes to applied with status confirmed by read-back. When a value differs, it stays unknown, because someone may have edited the record since. A created note or task carries nothing to search for, so it stays unknown until you check the CRM.
• Data used. The (redacted) fields the action acted on.
• Why. The brain citations the action referenced.
• Per-account filter. Enter an account domain (e.g. acme.com) to see just that account's history of agent touches over time. The filter and the account deck fields use the same field and button sizes as the rest of the workspace.

Waiting on a resolution

Sometimes a message reaches the provider and the answer never comes back. The send is not repeated, because a second send is worse than an unanswered question, and until now there was nothing you could do about it either. A panel at the top of the page lists any action in that state, with who it was to, when it was attempted and what to do next. It stays hidden when there are none. With one action waiting, its card's own notice says what state it is in; the general explanation shows above a list of two or more.

Each card carries the action's receipt: who it was to, the Internal request (the draft id the send was claimed under), the External reference (the provider's own id for the message, which reads Not yet confirmed until a lookup finds one), a Timeline of what is recorded (the claim taken before the send, any earlier review, and a lookup that found it), and a Credit row, which says Not recorded for a send because a send holds no credit reservation of its own. Under the cards, The same recovery rules apply sets out what is kept before any retry and what counts as proof for paid research, content publication and CRM writeback. The table shows whenever the page is helping you recover something: a held action, a research receipt opened from a paused launch, or a delivery attempt that was not confirmed. It stays out of plain action history.

Look up provider outcome asks. Every message this platform sends carries a reference of its own, recorded before the send, and Gmail can be searched for exactly that reference. The search uses the Gmail connection under Settings, Connections, so without one the check says Gmail is not connected. An Outlook send is checked in Outlook, by the same kind of reference. There, a hit settles it as sent, but a miss does not yet prove the message never went: until that search has been run against a live Microsoft mailbox, a miss asks you to look in Sent Items and record what you find. A hit does not settle anything by itself: the card changes to The provider accepted this action, fills in the external reference and offers Settle original receipt. Pressing it settles the original send with that provider reference, and nothing goes out again. Until you do, the action stays held, which still blocks a second send. A clean miss is the one case that proves the message never arrived, and it releases the approved message so you can send it. The card then offers Retry approved action, which sends that same approved draft to the same recipient through the normal send, with its usual checks: a support hold or a switched-off send layer still stops it and says why. Recording that you checked and it was never sent offers the same button. Anything else, an outage, a revoked connection, a rate limit, leaves the action where it was and says so: not being able to ask is a different answer from it not having happened, and only one of them permits a second send. Every held send also links Back to reviewed draft, which opens that draft on Home.

Record what I found is for a provider that cannot be asked, or an answer it could not give. When the provider has no lookup at all the form is open on the card from the start. Choose the observed outcome, add the external evidence reference if it was accepted, and write a resolution note saying what you checked. The note is required: a resolution with no evidence is an opinion, and this record has to survive being questioned later. Your name and the time go on it, and a resolution that finds nothing is recorded as still unknown rather than thrown away. Time passing settles nothing, so nothing here expires on its own.

A research request receipt

When a first launch pauses with a paid research request whose outcome is unknown, the research screen names the request and links here with Review request receipt. The receipt shows what was asked and through which provider, the internal request key, the provider's reference if one was recorded, the outcome, when it was recorded and settled, and the credit: how many were reserved and, once the provider answers, how many were charged. An unresolved request holds a second purchase for the same contact until it is settled, and time passing does not settle it. A request that is not in your account says so, and a receipt that could not be read says it is a load failure rather than a missing request.

Settle this request is how an unresolved request ends. Check the provider's usage or billing page for it, choose what it shows, add an optional Evidence note saying what you saw (up to 500 characters of plain text) and press Settle research request. Charged keeps the credit spent. The provider's answer was never recorded here, so the request is not reused as a result, and a later request for the same contact is allowed. Not charged and Refunded settle it at zero and put the reserved credit back in your enrichment budget. Settling never buys anything, the credit goes back once however many times the button is pressed, and a request that is already settled stays as it was. The settlement and the returned credit are written together: if the credit cannot go back, the request stays unresolved and says so, rather than being settled with the credit still spent. The provider's original error stays on the receipt after the settlement, followed by your note, and the audit log records the state, detail and credit the request held before you settled it. A request still recorded as in progress cannot be settled yet, and the control says so. The first launch's own five-lookup limit still counts the request.

POV deck (PDF)

The same page builds and opens a five-slide "why we're a fit" deck for one account, with data-driven charts, ready to File → Print → Save as PDF.

Enter the account id and the card tells you whether that account already has a deck. Generate deck builds a fresh one from the account's own data and opens it; Open deck opens the last one you built without spending another AI call. Generating runs an AI pass and is capped at five decks every ten minutes.

If it cannot build one, the card says which reason applies rather than failing silently: no account with that id, no active plan, the rate limit, or the deployment having no AI key. Until 2026-08-22 the card could only open a deck and nothing in the product could generate one, so it answered "No deck yet, generate one first" for everybody.

When a load fails

Held for review. A CRM change is held, not written, when the field changed in the CRM after we proposed the change. Its receipt shows the value it was proposed against, the value in the CRM now and ours, and a Review this conflict link to the decision on the Connections page. Nothing was written for a held receipt.

If the receipt history cannot be read, the page says so. It does not fall back to the empty state: "no agent touches recorded yet" is a claim about your account, and a failed request is not evidence for it. Refresh to retry.

Where the data comes from

Receipts are a thin layer over the writeback log every agent action already records; the page reads GET /api/me/receipts. Nothing new is tracked; the receipt just makes the existing action trail queryable and readable.