Bryn's First Big Leap

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.

Brynby CivicFigure 1 · one screen per job

The eight screens you will spend the most time in.

Pick a screen. The miniature shows its layout; the line under it says the job it does and its sibling views.

Screen	The job it does	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.	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.	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.	Weights · Mapping
Plays	What Bryn runs, on which trigger, through which connectors.	Deck · Lanes
Pixel	The pixel from live beacons to install to settings.	Console · Install · Customize

Illustrative accounts, people and figures. Every name is fictional. Connector names are generic.

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.

Brynby CivicFigure 2 · meters, not sums

One account, three weighted axes, and the lane it lands in.

Nudge Intent and watch the composite, the formula and the band move. Switch to Bands to see the same accounts in composite lanes. Lanes with no accounts do not render.

QL

Quillfeather Labs

quillfeather.example

person known

Fit90×0.50

Intent70×0.30

Timing60×0.20

78composite

0.50·90 + 0.30·70 + 0.20·60 = 78 · band 75 to 79

(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.

Brynby CivicFigure 3 · setup two ways

The same six steps, into the same draft.

Switch between setup in the app and setup from your own agent over MCP. The steps, the draft and the go-live gate do not change.

Step	In the app	From your agent (MCP)	State
0. Start	Open onboarding; the agent setup path is offered from the first step.	start setup: resumes the run started in the browser	run open
1. Workspace	Bryn asks for your website and sets it.	set website: lanternfish.example	set (later steps read it)
2. A pixel event arrives	Install the pixel; Bryn confirms when the first event arrives.	check events: pixel	event arrived
3. ICP	Bryn proposes an ICP from your site; you confirm it.	complete step: icp	staged in draft
4. Signals	Pick the events that matter; Bryn maps them to signals.	complete step: signals	staged in draft
5. Outputs	Choose where results land: a Slack channel, email, or the dashboard.	complete step: outputs	staged in draft
6. Plays	Preview starter Plays and where each delivers; switch each on or off.	complete step: plays	next: commits the draft
Go-live gate: nothing staged goes live until the Plays step completes and commits the draft.

Illustrative workspace (lanternfish.example), shown mid-run. Agent actions shown as plain step verbs.

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.

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 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.

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, 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, with dates. If you are setting up a workspace for the first time, getting started is the short path, and onboarding offers the agent setup path from the first step.

Stop watching signals. Start running them.