Skip to main content
BRYNby Civic
Log inGet Started

Bryn watches. You decide the Play. Bryn runs it.

A buyer moves and the Play you approved runs within the minute, on the record. You decide once what's worth acting on; Bryn handles every match after that. The five steps below are the whole product.

Start free →

Nothing signals alone

Three surfaces, one scope: your product, your site, your CRM. Bryn watches them together, including the anonymous visitors most tools miss. What it sees becomes a signal: a named read on what a buyer just did. Sixty minutes on one timeline, every hit scored as it lands.

The signal gets a name

A signal on its own is a visit from nobody. Bryn resolves it into a name: the company behind the domain and, when it can, the person and their role. The company is the common case; the person is the bonus. Everything downstream works at the account level first.

Enriched

one visitor
  • visitbook-a-demo, anonymous, now
  • accountNorthwind Robotics ⬩ northwind.example
  • personAda Northwind ⬩ Head of Growth
  • resolvedanonymous visit → named account

The score shows its work

Bryn scores the intent against your ICP, the accounts that actually become customers, not a generic "high intent" label. Fit is ICP shape: does this account look like the ones that close. Intent is signal density and velocity in the window. Timing is recency.

Each axis is a click-through to the contributing signals; the composite is the answer. Weights are yours to tune from Growth upward.

The Play fires, end to end

The Play you approved fires into your stack (Slack, your CRM, your outbound) within the same minute. One signal can route to several destinations; different Plays route differently. Bryn executes; you authored what to execute.

Destinations

one signal ⬩ several routes
  • Slack#growth-signals
  • CRMtask with the signal chain attached
  • Sequencepartner sequencers
  • Landingpage personalization
  • In-appexpansion prompt
  • MCPClaude desktop, Cursor
  • WarehouseSnowflake row

Bryn learns by recording

Every run is recorded in the audit log, the work record your team and your CFO can both read. Your data stays yours. Bryn records what it did, and every action traces to the Play that ran it.

Bryn sharpens from the decisions you make in the flow of work: the weights you tune, the Plays you edit, the outputs you dismiss. Today that's your hand on the weights; the recorded log is what makes automatic re-weighting possible later.

Learn record

weights edited
  • dismissedtrial:active → seat-invite ×2
  • refiled×3 minimum, 24h window
  • weightsIntent up 6 ⬩ Timing down 4
  • next matchlanded on first review

Bounded on purpose

Bryn's autonomy is bounded by approved Plays. The restraints are the feature.

No action outside the Play.

Bryn writes only to the systems your Play names, and never makes unbounded, open-ended API calls.

At the cap, Bryn pauses.

New identifications pause; existing Plays keep running on accounts already in scope. An in-product prompt offers the upgrade. No surprise bills.

One click, and Bryn waits.

Suspend all execution, or cut by region, segment, or Play. The audit log captures the suspend. Bryn waits. You decide when.

You hold the Play. Both ends of it

A Play is an action pattern you define and you approve: when this kind of signal appears on this kind of account, run this sequence into these destinations, with these guardrails.

Authority lives where you define and approve the Play, not in per-run sign-off. Run mode is the default; Approve mode is opt-in for sensitive Plays; the kill switch is always one click.

Run mode

default

Run mode. Approved Plays execute end to end, within the minute, on the record.

Watchingon
Runningon

Bryn answers questions where you already work

Bryn's record and its scope show up as tools in any MCP client, the protocol assistants like Claude desktop and Cursor already speak. Ask about a pattern:

pricing → comparison → repeat (7d)

Bryn answers from the same audit log the product shows you: which accounts matched it this week, the Play that fired on each, the composite score behind every decision, and the events that moved it.

Connect Bryn →

Every signal, score, decision, and run: on the record

Time-stamped, source-traced, replayable. The log is your work proof and the substrate for what Bryn learns next. Your CFO and DPO inherit the same trail. Retention windows, export, and erase-on-demand live in the trust center.

Pattern filed

14:02 UTC

demo-intent / Northwind Robotics

  • webpricing ×3, book-a-demo — 7d
  • intenttopic surge — 24h
  • identityresolved → northwind.example — now
  • scoreFit 82 ⬩ Intent 74 ⬩ Timing 68 — 76
  • decisionmatched Play demo-intent, Run mode — 14:02
  • run3 of 7 destinations fired — 14:02

routed to #growth-signals ⬩ CRM task ⬩ landing page

export: CSV / JSON ⬩ erase on demand ⬩ timestamps literal

Product mechanics, answered

What exactly is a Play?

A rule you set once: when this happens, on an account like this, do that, into the destinations you name, with the guardrails you set. You author it once; Bryn runs every matching instance inside those bounds. See the Play library.

Does Bryn act without my approval?

Bryn acts only inside Plays you approved. Approval lives at Play definition, not at per-instance execution: that's the point. For sensitive Plays, Approve mode holds each instance for one click. The kill switch suspends everything, and the audit log captures the suspend.

What happens when I hit my account cap?

Bryn pauses new identifications and keeps existing Plays running on accounts already in scope. An in-product prompt offers the upgrade; staying put resumes on cycle reset. No surprise bills. Details on pricing.

How does Bryn learn, honestly?

By recording. Today, every dismissal is captured and the sharpening comes from your edits to scoring weights and Play definitions. Automatic re-weighting from that substrate comes next. The corpus is being built now, on the record.

What does Bryn refuse to do?

Act outside Play-defined channels, write to systems a Play does not name, or make unbounded probabilistic API calls. Bounded on purpose; the restraints section above is the contract.

See the loop run on your stack

Signal, Enrich, Score, Play, Log: four steps run themselves, and the fifth writes it all down.

Start free →