# Onboarding, Run by an Agent

*Published 2026-09-29* | Author: civic-team

> **tl;dr** Bryn's setup can now be run by an agent: Bryn in the app, or your own agent (Claude, Cursor, VS Code) over the Bryn MCP server. Clicking through the wizard is not the interesting part. The interesting part is what the setup refuses to let an agent do: go live on a half-staged draft, tick a step that did not happen, fetch a tracking script nobody agreed to, or turn Plays on without an owner or admin. Agent-run onboarding is only worth trusting if the onboarding itself carries the rules. Bryn's does, and here is one run to show it.

## 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](https://docs.civic.com/bryn/getting-started) 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](https://docs.civic.com/bryn/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.

ONE ONBOARDING RUN, STEP BY STEP (interactive: nine moments across the six setup steps of one illustrative run at yourcompany.com, driven by the customer's own agent over MCP; left, the conversation and the agent's action as a plain step verb with a one-line result; right, the six-step rail with the current step lit, a DRAFT indicator that turns LIVE only at the last moment, and a "What went live" card at the end; illustrative run)
1. Before step 1: Resume the run. Agent: Picking up your Bryn setup where you left it in the browser. Action: 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. State: DRAFT.
2. Step 1: create workspace (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. Action: 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. State: DRAFT; website: live now (later steps read it).
3. Step 2: install the pixel (events), 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? The four answers the agent offers: 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. Action: get snippet. Result: Snippet returned, with the allowed origins. Pixel events received so far: none. State: DRAFT.
4. Step 2: install the pixel (events), refused. Agent: The snippet is in the page head in your repo. Marking the events step done. Action: 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. State: DRAFT; the events step is marked refused on the rail.
5. Step 2: install the pixel (events), passes. Agent: Checking for the first event. You: Deployed. I just opened the homepage. Actions: check events: pixel; complete step: events. Result: First pixel event arrived from www.yourcompany.com. events: done. Next step: icp. State: DRAFT.
6. Step 3: confirm your ideal customer (icp). Agent: Proposed ideal customer: software companies, two size bands, United States. Confirm, or change any of it? You: Confirmed. Action: complete step: icp. Result: icp: done, staged in the draft. Industries, sizes, and countries move the fit score today; anything else is recorded. State: DRAFT.
7. Step 4: map your signals (signals). Agent: From the events arriving, I would map pricing-page views and demo-form submits to signals. Stage that? You: Yes. Action: complete step: signals. Result: signals: done, staged in the draft. Next step: outputs. State: DRAFT.
8. Step 5: connect outputs (outputs). Agent: Where should results go: the dashboard only, or a Slack channel as well? You: Slack, #growth-signals. Action: complete step: outputs. Result: outputs: done, staged in the draft. Nothing delivers until go-live. State: DRAFT.
9. Step 6: review and turn on Plays (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. Action: 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. State: LIVE. What went live: ICP, signal mapping, scoring; 3 starter Plays on, 1 created paused; delivering to Slack #growth-signals; next matching event runs the Plays, on the record.
(illustrative run)
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.

STEP TO ACTION MAP (static figure): six onboarding steps, what the agent does for each, and the one rule each enforces. Before step 1, the agent starts setup, which resumes the newest unfinished run and flags values it did not stage. Workspace: set the website, live immediately because later steps read it; ask where else the pixel runs. Install the pixel: get the snippet, check events, complete the events step; ask before fetching, four answers, no is not a skip, passes only on a real pixel event. Confirm your ideal customer: stage the draft, complete the ICP step; will not complete until the ICP is staged. Map your signals: stage the draft, complete the signals step; will not complete until the mapping is staged. Connect outputs: complete the outputs step; staged in the draft, nothing delivers yet. Review and turn on Plays: go live; owner or admin only, commits the draft and goes live, reports what went live, switched-off Plays are created paused. Everything but the website stays in the run's draft until the plays step takes it live. Illustrative.
Figure 2. The step to action map: each onboarding step, what the agent does for it, and the rule it enforces (illustrative).

## 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](https://www.civic.com/field-notes/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](https://www.civic.com/field-notes/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](https://www.civic.com/field-notes/your-vendors-ship-mcp-servers-now), 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](https://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.**

Source: https://www.civic.com/field-notes/onboarding-run-by-an-agent