Activity
Everything your team did, in order: every pass, every draft, every account researched, every post written, every CRM write proposed, and every action you took, as one record on your clock. The health, trend and goal reports sit behind one door underneath.
Approve an Outlook draft
Choose Outlook drafts as your outreach destination on Today. In Activity, review the recipient, subject, message and connected mailbox, then choose Approve and place in Outlook. The draft remains unsent. Send it from Outlook when ready. If the response is uncertain, use Check Outlook receipt after reconciliation. The saved approval stays locked and the app will not create another copy. Skip and Snooze change the Activity list only; they do not remove an Outlook copy.
When your mailbox is paused
If too much mail from your Gmail or Outlook bounced this week, Send and Approve and place in Outlook on a queued draft from that mailbox are disabled, and hovering them gives the reason. Check the recipient, then choose I checked this address beside the button to clear that one draft. Every other draft stays held until you resume the mailbox in Connections.
Find the work behind your day
Activity combines runs, findings, research, hosted drafts, Studio content, queued outreach, proposed writes, Drive results, outbound send attempts, and your day actions. Search by title, account or role, then choose dates, role, kind and status. Older work loads another page from the same snapshot. The count is for the displayed page. A missing source is named and paging stops until you retry. Open an output and use Back to your activity to retain your filters. Sent means a provider accepted the message; it does not prove recipient delivery.
Overview
The work runs on a schedule, on our servers; this is where you see the result. Activity at /rollup is the record of the day, and the place a founder ends it. Today at Home is where it starts, and its Close the day band is one sentence counted from this same record.
Scoped to your account. A run by your roles never appears on anyone else's Activity.
The ledger
Recent activity is a table of work, role, outcome and next step, newest first. Each title includes its local date and time, with evidence details available in the row. Today is the default date range. Open Search and filter activity to find older work or narrow the role, kind and status. Ready to review, Completed and Needs attention count only records on this filtered page. If any source is unavailable, the summaries say Unavailable instead of showing a misleading zero. Drafts and questions remain available in the review disclosure below the table.
- Ran. A scheduled pass, with what it counted (contacts researched, emails drafted) or "found nothing" when it did. Opens the run.
- Failed. A pass that did not complete, with the error category. Opens the run, which offers a re-run.
- Found. A finding a role raised about your own records. Sample-book findings never appear here. Opens the role's console on the run.
- Drafted. An email or report a role wrote for your review. Opens the console's Drafts tab. Nothing is sent without your click.
- Researched. A note a role added to its library, or a proposed change to your business record with the evidence behind it.
- Wrote. A post the Studio drafted or published.
- Proposed. A write to a connected tool (a Gmail draft, a CRM next step or activity), held for your approval, or applied after it.
- Delivered. A report written into your Google Drive, when Drive delivery is on.
- You. What you did with an item Home offered you: did it, skipped it, snoozed or dismissed it. Opens Receipts.
Filters. Open Filter by role or work type beneath the search toolbar for role and kind chips. They combine, and they live in the URL (/rollup?product=salescron&kind=drafted), so a filtered view is linkable. The account filter under Reports scopes the run history the same way it always did.
Every source is read on its own. If one cannot be read, the ledger says which, and the rest still render; it never shows an empty day it cannot vouch for.
Reports
Everything below lives on its own tab of the Activity hub, /rollup/reports, reached from the strip above the ledger or from the Reports link under it. It sat behind a door on the ledger page for a first cut; the tab keeps the record to one screen. An older link into a report card (a goal, a role's health) lands on the tab. The cards are unchanged.
What it shows
- What changed (last 30 days). Real output, not just run counts, the totals each role reported (emails drafted, meetings prepped, hours saved, and any other numbers a skill emits), plus runs and "actions" this week versus last week and this month versus last with the percentage change. "This month" is the trailing 30 days compared to the 30 days before them, rolling windows of equal length, so opening the page on the 2nd never compares two days against a full month. Outcome totals come straight from the
countsa skill sends toemit_telemetry, no extra wiring. - Is everything running? Every role you own and whether it is actually working: "Healthy", "Not started yet" (held but never run, the clearest signal to act on), or "Last run failed". A header tally flags how many are erroring or unused. It shows before anything has run, so a new account sees its roles listed straight away.
- By role. A card per role with total runs, the last run time, any errors, and a runs-per-day trend sparkline (see below). Each name links to that role's drill-down (see below).
- Recent runs. The latest runs across every role you own, with role, skill, outcome, the counts line the skill produced, and when. Failed runs carry a categorized error badge (see below), and every row links to its run drill-down page.
- Brain state. One row per scope (signal-weights, icp-registry, decision-log, funnel-brain, content calendar, and so on) with its latest sync time, key and snapshot counts, and a change highlight, e.g. "+5 keys, 2 changed since last sync 3d ago". Each row links to that scope's full snapshot timeline (see below).
- How your work connects. A dependency and data-flow diagram over what you own, with missing-dependency and stale-upstream warnings (see below).
- Drafts ready to send. Outreach drafted for you on your schedule, waiting on your review (see below).
- Your hosted drafts moved to Home, where they are the Waiting on you block and carry how long each has waited.
- Delivered to your Drive. When Drive delivery is turned on for your account, each hosted run also writes its report into your Google Drive "Accounts" folder, a native Google Doc plus a raw
.mdcopy, so you can open it where you already work. The card lists recent deliveries with Open Doc / .md links (see below). Off by default; the card stays hidden until the first delivery lands. - Questions to ask. Worked deals with a real gap in what you know, and the specific question to close it (see below).
Delivered to your Drive
The runtime can put its reports where you actually read them: your Google Drive. When Drive delivery is enabled for your account, the daily run writes each report into your Drive "Accounts" folder as a native Google Doc (so it opens formatted and you can comment on it) plus a raw .md copy (the exact model output). The Delivered to your Drive card links each one, you never dig for a file.
This is a deployment option, off by default. It only runs when your operator enables owned connectors, your account opts in, and you've connected Google with Drive access. Writing a file into your own Drive folder is delivery, not an outbound send, nothing leaves your account. A delivery that fails is flagged on the card and never affects the run itself.
Drafts ready to send
On each scheduled pass, a run reads your account signals and drafts outreach for the contacts worth a touch that day. Those drafts land in the Drafts ready to send card, highest-quality first. Nothing is ever sent for you, every send is an explicit click.
What a draft looks like. Five blocks, one blank line between each. One or two sentences on the person and the company, from a post or comment of theirs on file and from what web research found, each fact cited. Two sentences naming a pain that research supports. One sentence on how your company meets it, by name, from your business brief. One sentence asking for time on their calendar. Then your signature, exactly as you wrote it under Settings, Profile. About 130 words before the signature; a draft over the cap is dropped, not trimmed.
The opening line. The first sentence after any greeting is held to three rules. It may not start with "I saw", "I noticed", "Congrats on" or "Hope you're well"; the same words later in a sentence are fine. It runs to 120 characters at most. And it may not match the opener of another draft from the same run once the two contacts' names and companies are swapped out. The first draft keeps its opener. A draft that breaks one of these rules is written again once, and dropped if the second try breaks one too.
Where the research comes from. Signals a rep pasted or a data vendor pushed for the contact, and a web-research pass on the person and the company, kept on the contact's record for two weeks so the same person is not researched every morning. There is no LinkedIn connector; a post or comment reaches a draft only through a pasted signal, a vendor, or the public web, and the draft never invents one.
Contacts held for their address. You send from your own mailbox, so a bounce or a spam complaint counts against your domain. Two kinds of address get no draft. A shared role inbox (info@, sales@, support@, hello@, noreply@ and similar) reaches a team or a ticket queue, not the person you researched. A catch-all domain accepts mail to any address, so the address proves nothing; we only know this when the provider that found the address said so (Hunter reports it on every lookup, Apollo only sometimes), and we never test a mail server ourselves. Held contacts are listed under the card, each with the reason. Draft to this address anyway approves that one address on that contact, and the next pass drafts to it. If the contact's address changes later, the new one is checked again. A hosted draft placed in Gmail with one of these addresses is held the same way.
Straight into your Gmail Drafts. Turn on Put new drafts in my Gmail Drafts on the card and each draft that clears the quality bar is also placed in your Gmail Drafts folder, addressed to the contact, with the subject line filled in. You read and send from Gmail. The card shows "In your Gmail Drafts" on those rows; sending from the card removes the Gmail copy so nothing goes twice, and Skip removes it too. Needs Gmail connected and managed connectors on. Off by default.
- Send. Emails the draft as written, via your connected Gmail.
- Use my edits. Edit the draft in place, then toggle this before sending to send your version instead of the original. Your edited text is kept on the record.
- Skip. Drops the draft, no send, no re-surface.
- Snooze 24h. Re-surfaces the same draft tomorrow.
Say what was off, once. After you send your edited version or skip a draft, the card asks one question: Wrong fact, Wrong tone, Wrong angle or Never say this, with room for a short note. It is optional and it comes after the send, so it never holds one up; No thanks closes the card. A note becomes a line on a review card under What your roles noticed on your business brief: a fact to get right, a voice rule, a decision for the log, or a phrase to ban. Nothing changes until someone accepts that card. Once accepted, every drafting agent reads the rule from its next run, the nine roles included, and a queued draft that uses a banned phrase is dropped before it reaches this card. An answer with no note is counted but does not become a rule. For Never say this, the note is the phrase itself, matched as whole words; a single common word, or a phrase already in more than a third of your recent drafts, is refused with the reason under the note. If your approved rules cannot be read when drafts are built, no drafts are queued for you that run rather than drafts that might break a rule.
A draft with no email address on the contact shows "no email" and can't be sent until you add one. Leads sourced from someone engaging with your content appear on Content Studio under Warm leads instead, so the same person never shows up in both places.
Questions to ask
On a scheduled pass, a run looks at your worked deals, the ones past qualification, with a live close date and real MEDDPICC evidence, and finds the specific thing you still don't know about each: no economic buyer named, no decision process mapped, no compelling metric quantified. For each gap it drafts the actual question to ask that buyer next, in a discovery style that opens a conversation instead of inviting a one-word answer.
- Ask this first. Each deal leads with the single highest-leverage question, the one you can't leave the next conversation without asking. Questions are ranked by leverage (gain times impact, minus how hard they are to ask), shown as a small "lev" tag.
- Why this is a real test. Under each question, a short certificate shows the assumption it tests, the falsifiable hypothesis about the answer, and what you would do differently based on it. That is the difference between a checklist and a real discovery question.
- Asked it. Marks the question handled and retires the card. The record is kept, not deleted.
- Dismiss. Drops it if it's not useful.
Only worked deals ever appear here, a deal you opened yesterday won't generate "ask who the economic buyer is", because an unstarted deal is supposed to have gaps. So an empty card means "nothing worth asking right now", never noise. Questions surface only once your pipeline actually holds opportunities with MEDDPICC detail; until then the card stays quiet.
Brain-state timeline
Brain sync is append-only, so every scope keeps a history of snapshots. The Brain State card links each scope to /rollup/brain/[scope], where you can see how that brain evolved:
- Sync timeline. An inline chart (no external libraries) with one dot per sync, oldest to newest. A filled dot changed the brain; a hollow dot re-synced with no key changes; a grey dot is the first sync. Hover a dot for its date, key count, and change count.
- Snapshots & changes. A feed of every sync, newest first, and exactly what changed versus the one before it, keys added, changed, or removed, plus a count of unchanged keys. The card highlights on Activity are the diff of the two most recent snapshots.
- Key names and counts only. The timeline shows top-level key names and counts, never raw values. "Changed" is detected by comparing a stable hash of each value between snapshots, so the page can tell you a key's value moved without ever exposing what it holds.
- Honest empty states. A scope with a single snapshot shows "no prior sync to compare"; a scope that was never synced (or belongs to another account) is not found. The same data is available as JSON at
/api/me/brain-timeline?scope=<scope>. - Your reflection. Below the timeline, this page also shows what your daily reflection has learned from your own activity: the insights, open gaps, and recommended next actions it is tracking for you. Unlike the snapshot timeline (key names and counts only), this is the reflection content itself, private to your account and shown only to you. Empty until you have logged enough account and prospect activity for a reflection to run.
- Gaps close as well as open. A gap the daily reflection raises again is the same gap, so it refreshes rather than appearing twice. One it stops finding in your activity, across two consecutive days, resolves and drops out of your open count and out of what your AI answers are grounded in. Resolved gaps stay on the page, so you can see what you cleared rather than watching it silently disappear. The same rule applies to recommended actions.
Live activity
Skills that declare their start (the start_run MCP tool) show up while they work, not just after:
- Running now. A strip at the top of the page with each in-flight run, skill, role, a spinner, and the elapsed time ticking live. It refreshes about every 30 seconds while the tab is open (nothing polls in the background), and when a run finishes the spinner flips to its outcome badge with a link to the drill-down. On a phone a long skill name wraps inside its row, and the status and time move to the next line when they do not fit.
- Stale runs. A run that declared a start but has been silent for 30 minutes, no heartbeat, no final report, is flagged stale instead of pretending to run forever. Stale usually means the skill crashed or the session was abandoned; re-run it.
- Timeline. The same recent runs grouped per day as a compact started → completed view (collapsible; today open by default). Runs still in flight show an open arrow.
Role versions that do not declare starts never appear as running, their runs land directly in Recent runs when they finish, exactly as before.
Performance trends
Each role card carries a runs-per-day sparkline for the active window, with a 7d / 30d / 90d toggle above the grid. Under the sparkline: that role's median run duration and its error rate over the window. Bars for days with at least one failed run are tinted red; hover any bar for that day's exact counts.
- Deterministic math, no AI. Runs are bucketed per UTC day; duration is the standard median over finished runs; error rate is errors divided by finished runs. Every number is reproducible from your run history.
- Honest error rates. Runs still running, or gone stale, have no outcome yet, so they count as activity but are excluded from the error-rate denominator and the duration median. A day where nothing finished shows a placeholder, not a fake 0%.
- Honest history. A role with fewer than two active days in the window shows "Not enough history yet" instead of a made-up flat line.
The trend data (per role, and per skill within each role) comes from GET /api/me/rollup-trends?window=7d|30d|90d, scoped to your account.
How your work connects
The roles are built to feed each other: your business record carries your company, offer and voice, each role reads it, and each produces brain scopes the next one consumes. The How your work connects card draws that as a small diagram (inline SVG, no external libraries) over what you actually own:
- Nodes are what you own. The one everything else reads from sits on top (marked with a star); the rest hang off it. Each node's ring is green when healthy, amber when never started, red when its last run failed, and the glyph shows its run count. Hover a node for its status.
- Solid lines are requirements. The solid edges show which of the things you own depend on another.
- Dashed lines are real data-flow. A dashed arrow from A to B means A synced a brain scope that B reads, derived by intersecting each one's declared scope interests (what it writes against what it reads) with the scopes actually observed in your brain sync. No observed sync, no arrow. Hover an arrow for the scope flowing across it.
Below the diagram, coordination warnings flag things to fix, each linking straight to the fix:
- Missing dependency. You licensed a role engine but not the Company OS Core it depends on, links to pricing.
- Ran before Core set up. An engine has runs but the Core dossier was never synced, so it never read your company context. Run Core's setup first.
- Idle. Something you own that has not run in the last 7 days (or never has), a churn signal, links to Connect.
- Stale upstream. Something active is reading brain data from a producer that has not re-synced in over two weeks, so it is working from stale inputs. Re-run the producer.
Honest empty state: owning one thing means there is nothing to coordinate, so the card says so and links to the catalog. Warnings are deterministic rules over your own run and sync history, no AI, every one reproducible.
Goals & targets
The Goals card turns Activity from a receipt into a pace check. Set a target against any outcome your roles actually report and see how far along you are this week or month:
- Any metric your roles emit. The metric dropdown is built from the outcome keys your telemetry has actually carried (like
contacts_researched,meetings_prepped,emails_drafted), never a hardcoded list. If a role has never reported a number, there is nothing to set a goal on yet, and the card says so. - Deterministic progress. Progress is the plain sum of that metric's counts across your runs inside the window, a run missing the key counts as 0, and multiple roles reporting the same key all add up. Every number is reproducible from your run history; no AI in the math.
- Week or month, calendar-aligned. "Per month" is the current calendar month (UTC); "per week" is the current week starting Monday. A progress bar fills toward the target with the current total and percentage.
- Personal or team goals. A personal goal tracks your own telemetry. If you own a team, you can set a team goal that sums every member's telemetry, only the team owner can create, edit, or delete team goals.
- Edit & delete. Adjust a target or remove a goal any time from the card. Honest empty state: with no goals set, the card reads "Set a goal to track pace."
The same data is available as JSON at GET /api/me/goals.
Pace & behind-pace alerts
Each goal shows a pace badge, Ahead, On pace, or Behind, computed deterministically by comparing how far through the window you are with how far toward target you are (within a plus-or-minus 15% band of the straight-line expectation). The progress bar tints red when you fall behind. Nothing here is a guess; every status is reproducible from your run history.
- Behind-pace email. A daily cron checks every active goal and, when one is behind pace, emails the owner once per window (never more than once a month for a monthly goal, or once a week for a weekly one). The email carries the exact progress, how far the window has elapsed, and the single suggested next action.
- Optional Slack nudge. If you have configured a personal Slack incoming webhook (Settings, API), the same behind-pace nudge is also posted there. It is best-effort, a Slack hiccup never blocks the email.
- Quiet by design. On-pace and ahead goals are never alerted. If email is not configured on the deployment, the cron simply logs instead of sending, and the once-per-window ledger still prevents duplicates.
What moved to Home
Activity is the record of what ran. Deciding what to do about it belongs on Home, where everything competing for your attention is ranked against everything else rather than in its own card.
Two cards moved there. Suggested next actions, a fixed rule table over your telemetry, is now part of the ranked line, so a nudge from your run history sits in the same order as a deal about to slip instead of in a separate list you might not scroll to. Your hosted drafts is now the Waiting on you block, which shows how long each has waited, because an approval that quietly piles up is the failure that card could not surface.
Nothing was lost and nothing new is hidden. This page keeps the full run history, the health and coordination views, your goals, and the drill-downs below.
Run drill-down
Every row in Recent Runs links to /rollup/run/[id], one run, in full:
- At a glance. Outcome, duration, when it ran, and the run id.
- What went wrong. When a run failed, a categorized error badge,
auth,entitlement,rate limit,provider,skill logic, orunknown, with the detail line the skill sent and a one-line hint on what to do about that category. Runs from versions that predate the taxonomy show as "uncategorized". - Full run payload. Everything the skill reported to
emit_telemetry, rendered as a key/value table (stored whole, 64KB cap at ingest). Runs recorded before payload capture shipped fall back to their counts line, honestly labeled. - Brain syncs from the run. When the role passes the shared run id (
run_ref) on itssync_braincalls, the drill-down shows exactly the snapshots that run produced, labeled as an exact match. Older runs without it fall back to a time-window match, honestly labeled: treat that as "what landed around this run", not a guaranteed causal link. - Re-run. A one-click re-run of the same skill, carrying the previous run's outcome, counts, and error context.
Per-role drill-down
Every role you own has its own page at /rollup/[pluginId], reachable by clicking its name anywhere it appears on Activity: the Is everything running? card, the By role card, or its node in How your work connects. It pulls that role's slice into one place:
- Health at a glance. Status (Healthy / Not started yet / Last run failed), total runs, error count, and last-run time.
- Trend. That role's runs-per-day sparkline for the active window (7d / 30d / 90d toggle), plus median duration and error rate, and a sparkline per skill underneath, from the same
/api/me/rollup-trendsdata. No chart library; the same inline-SVG sparklines used across Activity. - Coordination. Just this role's edges from the map, what it requires, what requires it, the brain scopes it feeds to others, and the scopes it is fed by, with any warnings that name it. Each link opens that role's own drill-down.
- Brain scopes. The scopes this role has synced, each with its change highlight and a link to that scope's full timeline.
- Error log. This role's recent failed runs with their categorized error badge, each linking to the run drill-down, plus a one-click Retry that re-runs the failed skills.
- Run history. The most recent runs of just this role, in the same table used on the main Activity (the role column dropped, since it is redundant here).
Honest scoping: something you do not own, or a made-up id, reads as not found, indistinguishable from one that does not exist. Every section has an empty state (a role that has never run shows a connect prompt, not fake data).
Filter by account
When your skills tag their runs with an account (the optional account_ref label they pass to emit_telemetry, a domain or account name), Activity gains an Account filter above the runs:
- Scope to one account. Pick an account from the dropdown (each option shows its run count) to scope the Recent runs table, the By role summary, and the Timeline to just that account's runs. "All accounts" clears it. The filter lives in the URL (
/rollup?account=acme.com), so a scoped view is linkable. - A label, not a record.
account_refis a free-text label, a domain likeacme.comor a name, not a synced CRM record. It is the same account you already know; Activity just groups by it. - Honest empty state. Until a skill passes an account, the card reads "No account labels yet" and explains what unlocks the filter. Versions that do not send
account_refstill appear in every unscoped view exactly as before.
Whether a skill tags its runs is up to the skill. One that works a specific account should pass its domain; one with no single account omits it. See the API reference for the label convention.
Dossier completeness
A compact GTM Context Dossier card rides along near the top of Activity: a meter scoring how many of the six dossier sections are filled (company, products, founder, voice, ICP, competitors) and a consumed-by line showing which roles have actually read your context, Core once your session pulls config, and each role with when it last synced brain state against it. The card appears only when it's relevant (you own the Content Engine, a dossier exists, or something has consumed it) and links to /onboarding/dossier to sharpen it. Full detail: GTM Context Dossier.
How it fills up
- Connect your tools and finish the setup for the roles you hold.
- As the scheduled runs happen, they call
emit_telemetryandsync_brainagainst the runtime. - This page reads the resulting
plugin_runsandbrain_syncrecords, scoped to your account.
Until a run happens, Activity explains what the first run will show, includes a small realistic preview, and offers one setup action. It does not put an empty table in front of you.
Weekly digest email
Every Monday, we email you a recap of the same data, runs and "actions" this week versus last, what changed, and any role that is idle or erroring, so you stay in the loop without logging in. You only get it if your runs happened in the last week. Every email has a one-click unsubscribe; you can also opt out from account settings.
How you compare
When your deployment enables cross-tenant benchmarks, a "How you compare" card shows your activity per won opportunity against the anonymized median band across every team on the deployment, never any other team's raw data. It appears only when the deployment flag is on, at least five teams have data, and you have not opted out (Settings, Data). Read-only. Full detail: docs/privacy/cross-tenant-benchmarks.md.
Data & privacy
The work runs on our servers, so we process the data you connect to do it. That data is encrypted at rest, isolated to your tenant, never sold, and never used to train models, and you can export or delete it at any time. Two different things flow into Activity, and they carry different sensitivity:
- Run telemetry is metadata. Run counts, outcomes, durations, and brain-state key names and counts. This is what most of Activity shows.
- Generated drafts hold content. A drafted email or report contains real text. It stays in your account, draft-only, until you send it. Nothing is ever sent on your behalf.
A short "Your data" card sits at the top of Activity linking to the full explainer on the Trust & security page (which also carries the security one-pager and our honest SOC 2 roadmap statement).
Related
- Connect your tools, get your scheduled runs going so this fills up.
- API Keys & MCP, the advanced tools that also feed this rollup.
- Team rollup (
/team-admin/rollup), the same outcome metrics across a team, plus a rep-vs-team leaderboard (members ranked by actions, each compared to the team median) and the team's week-over-week.