Anatomy of a Play

People ask what a Play actually is. So here is one, taken apart. A Play is a named pattern with a trigger, a set of bounds, an action, and a log. An operator approves it once; Bryn runs each instance and logs every one.

What a Play is, and is not

A Play is not a campaign, a workflow builder, or a black box that "uses AI to optimize your funnel." It is smaller and more honest than that. A Play is one named pattern and the decision that follows it, written down plainly enough that you can read it, approve it, and audit it later.

We name them by their parts on purpose: pricing -> comparison -> repeat (7d) tells you the trigger and the window without a manual. If you cannot say what a Play does in a short line, it is not a Play yet.

The four parts

Every Play has the same anatomy: a trigger that fires it, the bounds it runs inside, the action it takes, and the log it leaves. Step through one:

One Play, stage by stage: pricing -> comparison -> repeat (7d)

09:14:02 watched acct 4471: pricing_view x3 in 6d

The trigger. Bryn sees the pattern you named: a third pricing-page visit inside seven days.

09:14:03 scored icp.growth: cleared 4/5 axes

Scored against your own definition of a good account, not a generic lead score.

09:14:04 ran send.intro from assigned owner

The approved action runs. You approved this Play once; you did not have to approve this instance.

09:14:05 logged run #4471

Every run is written to the audit log. In v0 that record is the learning; the ML comes later.

That is the loop we talk about, watch, score, run, learn, made concrete on a single pattern. The trigger is the watch. The scoring is against your own definition of a good account. The action is the move. The learn, in v0, is the record: every run written down so you can read what happened and tune the Play.

The bounds

The bounds are where your judgment lives, and they are set once, at approval, not at every instance. A Play runs in one of three modes. Run is the default: you approved it, so it acts on its own. Approve holds each instance for your yes when you want the final say. Kill suspends it. The switch is always in reach. That is what makes it safe to let a Play run: the decision went in up front, once.

The run, and the record

When a Play runs, it leaves a receipt. Not a dashboard tile, a plain-language line in the log: what it saw, how it scored, what it did, and when.

This is the part people underestimate. The record is not a compliance afterthought you dig up when something breaks. It is the work itself, written down, and it is what lets you trust a Play enough to leave it running. You can always answer why a given account got a given action on a given day, in one place, in plain words.

Write one in a line

Here is the do-it-Monday version. Take one recurring go-to-market moment you handle by hand and write it as a Play in a single line: when [signal], do [action], within [bounds]. If you can say it in one line, it is a Play, and it is ready to approve. If you cannot, it is still a wish, and that is useful to know too.

You can see the wider loop in what Bryn actually does. Stop watching signals. Start running them.

Bryn is the Signal-Based GTM agent for Growth teams. See it at civic.com/bryn.