Onboarding, Run by an Agent

About 30 minutes, mostly not clicking

Bryn's setup is six steps: create the workspace, install the pixel, confirm your ideal customer, map your signals, connect outputs, review and turn on Plays. The getting-started docs say most teams finish it in about 30 minutes.

Very little of that half hour is clicking. Most of it is waiting for a first pixel event from a page someone has to deploy, deciding which industries and sizes actually count as your customer, and working out which of the events you already send mean anything. A wizard does not make those decisions faster. It gives them an order.

So when a vendor says "the agent sets it up for you," the useful question is not whether an agent can click through. The useful question is what the setup does when the agent is early, wrong, or in a hurry.

Two ways in, one run

Since the September releases (the changelog has them in order), there are two ways through setup. Bryn can walk you through the whole flow in the app: completing steps, setting the workspace website, confirming events are arriving. Or your own agent can do it over the Bryn MCP server, starting a run, reading it, and staging it. Onboarding now offers the agent setup path from the very first screen.

Both paths drive the same six steps, stage into the same draft, and stop at the same gate. They also share the run itself. When an agent starts onboarding, it resumes the newest unfinished run instead of creating a new one, so a setup you began in the browser continues in your agent without starting over. If that run already carries values staged earlier, the agent is told so, and told to confirm with you anything it did not stage itself.

Monday's piece covered the relaunch as a whole. This one stays on that single move.

One run, step by step

Here is one illustrative run for a workspace at yourcompany.com, driven by the customer's own agent. The left side is the conversation. The right side is what the app shows at the same moment.

Step through an agent setting up a Bryn workspace over MCP. Left: the conversation and the agent's action. Right: what the app shows. Use the buttons, or Left and Right arrows, Home and End while focus is in the figure.

(illustrative run)

1. Before step 1: Resume the run

   agent Picking up your Bryn setup where you left it in the browser.

   → start setup

   Result: Resumed your unfinished run. Next step: workspace. One value was staged earlier (value proposition), not by this session: confirm it before I rely on it.

2. Step 1: create workspace (workspace): 1 Workspace

   agent Your main site is yourcompany.com. Does the pixel run anywhere else, such as an app subdomain or a separate marketing site?

   you Also app.yourcompany.com.

   → set website: yourcompany.com, app.yourcompany.com

   Result: workspace: done. Allowed pixel origins: yourcompany.com, www.yourcompany.com, app.yourcompany.com. Your own traffic is marked internal. This one is live now, because later steps read it.

3. Step 2: install the pixel (events): 2 Pixel: the ask

   agent Next is the pixel: one script tag in your page head that records visits to your pages. How do you want to add it?

   • Ready to install it (chosen)
   • Hand it to a developer (the run parks until they deploy)
   • Explain the step first
   • I do not want a tracking script (not a skip: the run stops here)

   you Ready to install it.

   → get snippet

   Result: Snippet returned, with the allowed origins. Pixel events received so far: none.

4. Step 2: install the pixel (events): 2 Pixel: refused

   agent The snippet is in the page head in your repo. Marking the events step done.

   → complete step: events

   Refused: No pixel event has arrived yet. An installed snippet is not enough. Fix: deploy it, load a page on an allowed origin, then check events again.

5. Step 2: install the pixel (events): 2 Pixel: passes

   agent Checking for the first event.

   you Deployed. I just opened the homepage.

   → check events: pixel

   → complete step: events

   Result: First pixel event arrived from www.yourcompany.com. events: done. Next step: icp.

6. Step 3: confirm your ideal customer (icp): 3 ICP

   agent Proposed ideal customer: software companies, two size bands, United States. Confirm, or change any of it?

   you Confirmed.

   → complete step: icp

   Result: icp: done, staged in the draft. Industries, sizes, and countries move the fit score today; anything else is recorded.

7. Step 4: map your signals (signals): 4 Signals

   agent From the events arriving, I would map pricing-page views and demo-form submits to signals. Stage that?

   you Yes.

   → complete step: signals

   Result: signals: done, staged in the draft. Next step: outputs.

8. Step 5: connect outputs (outputs): 5 Outputs

   agent Where should results go: the dashboard only, or a Slack channel as well?

   you Slack, #growth-signals.

   → complete step: outputs

   Result: outputs: done, staged in the draft. Nothing delivers until go-live.

9. Step 6: review and turn on Plays (plays): 6 Plays: go live

   agent Four starter Plays, each delivering to #growth-signals. You switched one off. Completing this step takes the workspace live and needs the owner or admin role; you are an admin. Go?

   you Go.

   → go live

   Live: plays: done. Workspace is live. Went live: ICP, signal mapping, scoring, three starter Plays on, one created paused. Delivering to Slack #growth-signals.

Figure 1. One illustrative onboarding run for yourcompany.com: the pixel question, one refusal, and go-live at the last step (illustrative, not a benchmark).

Two moments carry the piece. The first is the events step, where the agent stops and asks. The second is the same step a few minutes later, where the setup says no.

What the setup refuses

It will not go live early. Onboarding stages everything in the run's draft and writes nothing live until go-live. The agent is told, in the tool descriptions themselves, not to use the live configuration tools while onboarding is underway. An agent that finishes four of six steps and wanders off leaves a draft, not a half-configured workspace scoring accounts on a guess.

The website is the one exception, and it says why. Setting the workspace website takes effect immediately, because later steps read it. It registers the apex and www forms of your domain as allowed pixel origins and marks your own traffic internal, so your team browsing the pricing page does not fire Plays. Then the agent is told to ask one question: does the pixel run anywhere else, such as an app subdomain or a separate marketing site? An origin that is not on the list has its reports refused, and that failure does not look like an error. It looks like the events step never passing. One question at step one saves an afternoon later.

It asks before it fetches the tracking script. Before the agent pulls the snippet, it explains what the snippet is and what it records, then offers four answers: ready to install it; hand it to a developer, and the run parks until they deploy; explain the step first; or do not want a tracking script. The fourth answer is taken at its word, and it is not a skip. Nothing passes the events step without a real pixel event, so "no" stops the run there, and the conversation becomes whether to go on at all. An agent that fetched the snippet unasked would be presenting a decision as though it were already made. The setup is written so it does not.

Steps are satisfied, not ticked. Completing the events step needs a pixel event to have actually arrived. The snippet being installed is not enough, and an event from PostHog does not substitute. The ICP and signal-mapping steps will not complete until their configuration is actually staged. A step that is not ready is refused with the reason and the fix, which is what the transcript shows: the agent asks to complete the events step, and the setup refuses; then the snippet is deployed, the first event arrives, and the step passes.

Going live needs the right role. On a first-time workspace, completing the Plays step commits everything and takes it live, and that step needs the owner or admin role. An agent working for anyone else can stage every step and still cannot take the workspace live. Starter Plays you switched off are still created, paused, so turning one on later is a toggle, not a rebuild. If every starter Play is off, onboarding warns you instead of blocking.

One scoring note from the ICP step: today only industries, sizes, and countries move the fit score. Company types, regions, and stages are recorded but do not score yet.

What you get at the end

When the Plays step completes, the workspace is live, and the Plays you turned on run on the next matching event. The result reports what went live, so the agent can tell you in plain terms, including where each Play delivers (a Slack channel, an email). From then on, every run lands on the record.

That is the same shape as the rest of Bryn. Bryn is the agent your agents call, and the rules that matter sit on Bryn's side of the call, not in the calling agent's good intentions. Once the workspace is live, operator authority lives where it always has, in the Play and its approval, which is the argument of Approve Mode Is Not a Speed Bump. Onboarding is just the first place the pattern shows up. And now that your vendors ship MCP servers, it is the pattern to look for in theirs.

Ask the vendor first

Before you let any agent configure a tool for you, ask the vendor three questions.

1. Does anything go live before the last step?
2. Which steps check that the thing actually happened?
3. Who has to be present for go-live?

If they cannot answer, the agent is clicking, not onboarding.

For Bryn the answers are short. Nothing goes live before the Plays step except the website, and the setup says why. The events, ICP, and signal-mapping steps check. Go-live needs an owner or admin.

Connect your agent

To run setup from your own agent, connect the Bryn MCP server using the steps at docs.civic.com/bryn/mcp, then ask it to set up your workspace.

Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack.

Stop watching signals. Start running them.