What Scribe Does

The timeline on a lead’s detail page has two kinds of actors. One is you (or another agent, by name) — the human who logged something. The other is Scribe — the system, doing whatever the system does automatically.

Scribe isn’t an agent. It’s not an AI assistant. It doesn’t have judgment. It’s a name attached to the events the system writes on its own initiative — state transitions triggered by your logged actions, temperature recalculations driven by behavioral signals, timeout-driven moves, lead creation from contact form submissions.

This page is the longer version of why the system gets a name at all.

What Scribe is

Scribe is the actor on a timeline row when the row was written automatically by the system. Specifically, you’ll see Scribe attributed on:

Event type	What Scribe is doing
State transitions that fire as a side-effect of agent activity	You logged a call → Scribe wrote `NEW → CONTACTING`.
State transitions that fire from timeouts	21 days of no response → Scribe wrote `CONTACTING → ARCHIVED`.
Temperature signals from behavioral events	The lead viewed three properties → Scribe wrote a temperature row.
Lead creation from contact form submissions	A web form was submitted → Scribe wrote `Lead created`.
Flag set from automated signals	A hard bounce came in on an email → Scribe could set `do_not_email` (depending on configuration).

What Scribe never does:

Make a judgment call. If a decision requires human discretion (qualifying a lead, reactivating an archived one, picking a reason for a deal collapse), the actor is you.
Write a free-text reason. Scribe writes structured event rows — type, from-state, to-state, trigger, payload. Narrative belongs to humans.
Take an action that a real person couldn’t undo. Anything Scribe writes can be reversed by an agent action; the timeline preserves both directions.

Why give the system a name

Most CRMs attribute automatic actions to “system” or leave the actor field blank. We picked a name — Scribe — and put it everywhere a human would have signed for an action. Three reasons.

Trust through visibility

A timeline row with no actor is uncomfortable. You read it and don’t know whether something happened on its own or whether you somehow caused it. The first question becomes “did I do that?” — and the answer requires you to remember whether you clicked something.

A timeline row attributed to Scribe is unambiguous: that wasn’t me. That was the system. The mental cost of reading the timeline drops because you don’t have to second-guess the source of every row.

Distinguishability in audit

When the broker or a compliance person reads a lead’s history, the actor column is the first cut they make. “Show me everything an agent did” filters by named actor. “Show me everything the system did” filters by Scribe. Both views are useful, and the second view is impossible if the system has no consistent name.

This matters more than it sounds. Without a system-actor name, the implicit query for “show me agent actions” is not blank — which means every state-transition side-effect (which is technically agent-attributable, because the agent’s logged action triggered it) ends up in the agent’s column too. The agent’s audit timeline becomes the union of “things I deliberately did” and “things that automatically happened because I did the first set of things.” That’s not what you want.

Scribe separates the two cleanly. Your name shows up for what you deliberately did. Scribe’s name shows up for what fell out of it. Anyone reviewing the timeline can read either layer without confusion.

A handle for the mental model

Real estate agents come from systems with very different attribution models — BoomTown attributes some auto-events to the “Smart-Drip” engine, kvCORE attributes them to “Robot” actions, Top Producer often shows nothing at all. Asking an agent to internalize “the system did this, but it’s tracked here under no actor name” is asking for misreads.

“Scribe wrote that” is a sentence agents can say to each other when they’re reviewing a card together. It’s the right level of abstraction — concrete enough to refer to (“did you see what Scribe logged on the West End lead?”) but specific enough to mean exactly the right thing.

The icon on Scribe rows is a feather. The visual choice reinforces what Scribe does: it writes things down. It doesn’t think, judge, or act. It records.

What Scribe is NOT

Worth being explicit, because the temptation to treat the system actor as smarter than it is is real.

Scribe is not an AI agent. It doesn’t reason about leads, generate replies, or decide what’s important. It executes a state machine and a temperature scorer that have explicit, written rules.
Scribe is not the AI assistant on the public site. The semantic search and recommendation features for buyers have their own internals; those aren’t Scribe.
Scribe is not infallible. If a transition fires when it shouldn’t, that’s a bug to report — not the system being mysteriously wrong on purpose. Scribe rows are deterministic outputs of inputs the system saw.
Scribe is not an authority over you. If you disagree with a transition Scribe wrote — say, a timeout-driven CONTACTING → ARCHIVED on a lead you were actively working but hadn’t logged — the right move is to manually reactivate (recovering the lead) AND to log the activity that should have been there. Scribe acted on the data it had; you have the data it didn’t.

How Scribe interacts with you

A common pattern: you log a phone call. Two rows appear in the timeline almost simultaneously:

─ Just now ─────────────────────────────────────
  You — Phone call logged
  "Left voicemail."

─ Just now ─────────────────────────────────────
  Scribe — State change: NEW → CONTACTING
  triggered by: contact_attempted

Your row is the cause. Scribe’s row is the consequence. The lead’s column on the board updated because Scribe wrote the second row. The two rows are tightly coupled — you can’t really have one without the other for that specific transition — but they’re attributed differently because the actor model is principled.

That principle saves you confusion later. If you’re trying to figure out why a lead is in CONTACTING, you can trace it: Scribe wrote the transition, which means an event triggered it, which means an agent (you, or whoever) logged contact. The chain is readable.

When Scribe doesn’t appear at all

Some things happen on a lead that never write a timeline row:

Property views on the public site (those feed the temperature scorer but appear as aggregated signal rows, not individual views).
Search queries (same).
Automated emails from the marketing system (those live in the email system’s own logs).
Page renders of the lead detail page by an agent (we don’t log what you read, only what you do).

The timeline is the canonical record of lifecycle events — transitions, flags, agent activity, system-observed signals. It is not a log of every observable thing. If you need finer detail (which property the lead viewed, which search they ran), that’s the session-activity view, not the timeline.

The takeaway

Scribe is a name for a category of timeline rows that would otherwise be unattributed or attributed confusingly. The name does three things: it lets you read the timeline without second-guessing the source of each row, it lets reviewers separate agent actions from automatic side-effects, and it gives the team a shared handle for talking about what the system did.

It is not an entity with judgment. It is not an AI. It is a feather-shaped name on rows the system wrote because rules said so.

Read Scribe rows as facts about what the system observed. Read your own rows as the actions you took. The combination is the lead’s full story.

Read the timeline — how-to for interpreting individual row types, including who-did-what
Your first day — the timeline pattern in the demo, with both actors visible
State machine card — what kinds of transitions exist, including the ones Scribe fires automatically