# Bryn's First Big Leap

*Published 2026-09-28* | Author: brad-webb

> **tl;dr** Today the Bryn app is rebuilt around one rule: one screen per job. The audit log is an entity ledger, accounts and Plays are cards, and where one job has two useful views, a pill switches between them. A score always shows its weighted axes beside the composite. Setup can now be run as a conversation, by Bryn in the app or by your own agent over MCP, into a draft that goes nowhere until go-live. And the record got easier to read: the source behind every account field, and rules that re-evaluate the accounts you already have.

## What the console is for

The Bryn app has one job. It is where you see what Bryn watched, what it scored, what it decided, and what it did. It is also where you change the things that steer it: the ICP, the weights, the signal mapping, the Plays.

For a while that job was spread across lists: accounts, events, Plays by name. Everything was there. Not much of it could be read in the time you actually have, which is usually the minute between two other things.

Today the app is rebuilt around one rule: one screen per job. Setup can now be run by an agent, Bryn in the app or your own over MCP. And the record got easier to read. Here is what changed, and a little of why.

## One screen per job

The eight screens you will spend the most time in each do one thing, and each fills the screen with cards, lanes and ledgers instead of rows.

The audit log is now an entity ledger. Every account Bryn touched today sits in a rail on the left. The events are grouped into runs in the center. On the right is the score at that moment, with its fit evidence, the signals in the window, the Plays that matched, and what was delivered. Click a row and the score rail follows it. It is the difference between a log and an answer.

Accounts are cards. Each one carries the three meters with their weights, the composite, the sources Bryn resolved it from, its tags, and an open deal when there is one. A Grid · Bands pill lays the same accounts out in composite lanes, so the top band is one click away and nothing needs filtering.

Individuals sit under their account, a card per person, with the account's meters in the header. Connectors are an inventory (inputs, enrichment and outputs, each a card with a health line) and, one pill over, a pipeline that draws the flow from inputs through Bryn to the latest deliveries. The account score page is the whole story for one account: the meters and the written formula, a 7-day score history, every signal on record with its weight, the Plays that matched, and held runs with a Release button. Scoring is weights and mapping. Plays are a deck of cards (name, switch, a chip per trigger clause, the connectors it delivers through) or a set of lanes: active and fired, active and waiting, paused. Pixel is console, install and customize.

The pills are the part I would point at first. Where one job has two honest ways of looking at the same data, a pill switches between them. Same screen, same data, a different question. Nothing gets sent to a second page because it needed a second view.

ONE SCREEN PER JOB (interactive: a pillset of the eight screens; picking one shows a miniature of that screen built from the app's own components, and a line naming the job it does and its sibling views)
- Audit log: what Bryn did, account by account: accounts in a left rail, runs in the center, the score at that moment on the right. One view.
- Accounts: every scored account as a card: logo, meters with weights, composite, sources, tags, open deal. Sibling views: Grid · Bands.
- Individuals: the people Bryn saw, a card each, grouped under their account. One view.
- Connectors: what feeds Bryn, what enriches it, where it delivers. Sibling views: Inventory · Pipeline.
- Account score: the whole story for one account: meters, formula, 7-day history, signals, matched Plays, held runs. One view.
- Scoring: the blend of the three axes, and the rules that turn events into signals. Sibling views: Weights · Mapping.
- Plays: what Bryn runs, on which trigger, through which connectors. Sibling views: Deck · Lanes.
- Pixel: the pixel from live beacons to install to settings. Sibling views: Console · Install · Customize.
Illustrative accounts, people and figures. Every name is fictional. Connector names are generic.
Figure 1. The eight screens you will spend the most time in, each with its job and its sibling views (illustrative accounts and data).

## Meters, not sums

A score in Bryn is three weighted axes and a composite. Fit is how closely the account matches the customer you said you want. Intent is what it has been doing. Timing is how recently it did it. The composite is the blend, with the weights beside each axis and the formula written out underneath.

We do not show the composite alone. A bare 78 invites you to trust it or argue with it, and gives you nothing to do in either case. A 78 with its parts tells you why, and which rule to change if the why is wrong. That was already true on the account score page. Now it is true on every card.

Color means something. Teal is evidence: what Bryn saw. Purple is impact: Plays, runs, decisions, what Bryn did. Coral is the cost of waiting. Nothing is decorated, so when something is colored, it is telling you which of those it is.

And a screen shows what Bryn knows and nothing else. Absent data renders nothing. No empty states, no "nothing found", no disclaimers about what might be missing. A band with no accounts is simply not there. That reads like a styling choice. It is closer to a promise: anything on the screen arrived.

METERS, NOT SUMS (interactive: one account card, Quillfeather Labs (quillfeather.example), with Fit, Intent and Timing meters and their weights, the written formula and the composite; a Grid · Bands pill moves the card into its composite lane; a range input nudges Intent and the composite, formula and lane update)
- Fit 90 ×0.50. Intent 70 ×0.30. Timing 60 ×0.20.
- 0.50·90 + 0.30·70 + 0.20·60 = 78. Composite 78. Band 75 to 79.
- Bands view lanes: 90 and up, 80 to 89, 75 to 79, 70 to 74. A lane with no accounts does not render; below 70 the card is absent from Bands.
- Neighbours in Grid: Oxbow Metrics (oxbow.example) Fit 95, Intent 90, Timing 86, composite 92; Lanternfish Analytics (lanternfish.example) Fit 80, Intent 60, Timing 65, composite 71.
(illustrative account and weights, not a benchmark)
Figure 2. One account, its weighted axes, its composite, and the lane it lands in (illustrative account and weights, not a benchmark).

## Setup as a conversation

Setup used to be a wizard. It is still the same six steps: the workspace, a pixel event arriving, the ICP, the signals, the outputs, the Plays. What changed is who can walk them.

Bryn walks you through setup in the app now, from the first step. It completes steps with you, sets the workspace website, confirms that events are arriving, and shows the starter Plays it suggests, with where each one will deliver (a Slack channel, an email), before you switch any of them on.

Or your own agent does it. Claude Desktop, Cursor or VS Code, connected to the Bryn MCP server, can start a run, read it, and stage it. The steps are the same, and so is the draft. A run started in the browser continues in the agent instead of starting over. And nothing goes live until go-live: onboarding stages configuration in the run's draft, and the draft stays a draft until the last step commits it.

That last part is the one I would ask about with any tool that lets an agent set it up. An agent that can click through a wizard is easy to build. A setup that refuses to go live on half a draft is what lets you hand an agent the job. Tomorrow's note walks one run step by step, including what the setup will not let an agent skip.

SETUP TWO WAYS (interactive: an "In the app" / "From your agent" button pair; both show the same six steps into the same draft, with state chips and the go-live gate; the agent side shows plain step lines)
- 0. Start. In the app: open onboarding; the agent setup path is offered from the first step. From your agent: start setup, resumes the run started in the browser. State: run open.
- 1. Workspace. In the app: Bryn asks for your website and sets it. From your agent: set website: lanternfish.example. State: set, read by later steps.
- 2. A pixel event arrives. In the app: install the pixel; Bryn confirms when the first event arrives. From your agent: check events: pixel. State: event arrived.
- 3. ICP. In the app: Bryn proposes an ICP from your site; you confirm it. From your agent: complete step: icp. State: staged in draft.
- 4. Signals. In the app: pick the events that matter; Bryn maps them to signals. From your agent: complete step: signals. State: staged in draft.
- 5. Outputs. In the app: choose where results land: a Slack channel, email, or the dashboard. From your agent: complete step: outputs. State: staged in draft.
- 6. Plays. In the app: preview starter Plays and where each delivers; switch each on or off. From your agent: complete step: plays. State: next, commits the draft.
Go-live gate: live so far, the workspace website, because later steps read it. Everything else waits in the run's draft until the Plays step completes and commits it.
Illustrative workspace (lanternfish.example), shown mid-run.
Figure 3. The same six steps, run two ways, into the same draft (illustrative workspace).

## More MCP

The Bryn MCP server already answered questions. Which accounts hit pricing this week? What did Bryn run yesterday? Plain language in, the record out, no API code. We covered that in [the agent your agents call](https://www.civic.com/field-notes/the-agent-your-agents-call).

Now it can run setup too. Same server, same sign-in: Civic Auth over OAuth, so the first connection opens the Bryn login in your browser and there is no token to copy. The [MCP docs](https://docs.civic.com/bryn/mcp) have the config for each client.

If you already run your day from an agent, you should not have to leave it to set up the tool that runs your Plays. Now you do not.

## The record

The console exists to make the record readable. So the record got more specific.

Each account field shows the enrichment source that supplied it, with its full decision history. When a source stops providing a field, the field is removed, so a stale value does not sit there looking current.

Change a rule and existing accounts re-evaluate. The rule you wrote this morning applies to the accounts you already had, not only to the ones that arrive next.

Any audit entry opens the source event behind it: exactly what came in, and how it was mapped.

The team side caught up too. A Members page to invite teammates, resend or revoke invitations, and remove members. Invite links, with an accept page that only works for the address the invite was sent to. And a new admin role between owner and operator: workspace configuration, without billing or member management.

WHAT THE RECORD KEEPS (static: a ledger card in the Bryn app's light register, stamped "live today")
- Field source: each account field names the enrichment source that supplied it, with its full decision history. Reading: per field.
- Stale fields: removed when the source stops providing them. Reading: removed.
- Rules: a changed rule re-evaluates existing accounts, not only the ones that arrive next. Reading: retroactive.
- Source event: any audit entry opens the event behind it, and how it was mapped. Reading: every entry.
Example field (illustrative): Harrowgate Freight (harrowgate.example), industry: Software, source enrichment; decision history: 09-23 07:10 UTC set from enrichment; 09-24 16:02 UTC re-evaluated after an ICP rule change; 09-28 08:41 UTC kept on refresh, source still provides it.
Team: Members page; admin role, between owner and operator; invite links.
Illustrative account. Features per the Bryn changelog, Sep 2026.
Figure 4. What the record keeps now (illustrative account).

## Why

Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack. In Bryn, your authority lives in the Play and its approval. Bryn watches. You decide the Play, and whether it runs on its own or on Approve. Bryn runs it. That is the argument in [approve mode is not a speed bump](https://www.civic.com/field-notes/approve-mode-is-not-a-speed-bump), and it has not changed.

That gives the console a specific job. It is not where decisions get made one at a time. It is where you see what ran and why, quickly, and change the rule, quickly, when the why is wrong. Everything in this release points at one of those two speeds. The ledger and the meters are for seeing. Retroactive rules and the agent setup path are for changing.

For anyone starting fresh: from today, new trial workspaces get a guided email series through their first week: scoring, accounts, Plays, personalization and MCP, each arriving in the week you are learning it.

## Where to look

Everything above is in the [changelog](https://docs.civic.com/bryn/changelog), with dates. If you are setting up a workspace for the first time, [getting started](https://docs.civic.com/bryn/getting-started) is the short path, and onboarding offers the agent setup path from the first step.

**Stop watching signals. Start running them.**

Source: https://www.civic.com/field-notes/bryns-first-big-leap