Everywhere else on this site, we sell an outcome: pipeline that shows up in your Slack channel without you chasing it. That's the right pitch for someone deciding whether to sign up. It's the wrong pitch for an engineer, a technical co-founder, or an investor who wants to know how the underlying system is actually built: what it's wired to, what it exposes, and where the real engineering tradeoffs sit. This page is the front door to that material.
We're calling this corner of the site GTM Engineering, and we want to be precise about what we mean by it, because the phrase is already spoken for: Clay coined "GTM engineering" as its own category label, and this cluster isn't trying to take that word from them. What we're staking out is narrower, and, as far as we can tell, still open: the intersection of signal-based GTM (go-to-market work driven by what a buyer actually does on your site and in your product, not a list bought from somewhere else) and the day-to-day engineering practice of building and running a system like that. Nobody else in the category has claimed that specific intersection yet. This is where we write about it.
"GTM engineering" already means something specific to a lot of readers: Clay's own term for the discipline of wiring together data providers, enrichment, and automation to run go-to-market at scale. That's their category, they named it first, and this cluster doesn't contest it.
What we're pointing at is more specific than the general practice of GTM automation, and it's the one part of the map we haven't seen anyone else stake out: engineering practice applied specifically to signal-based GTM: systems where the trigger for action is first-party behavior (a returning visitor, a second teammate invited, an account gone quiet and back), not a purchased list, and where the engineering questions are things like: how do you sign an event so you can trust its source, how do you let an agent read a score without letting it invent one, how do you build an audit trail that survives a real audit.
That's a narrower, more technical seam than "GTM engineering" as a whole field, and it's the seam this cluster is built to occupy. Below is the architecture of that plan: the topics we intend to write, not the articles themselves yet.
"You do not need the API to use Bryn: the dashboard covers setup and day-to-day operation."
— docs.civic.com/bryn/api-overviewThat's true of this cluster too. It exists for readers who want to go deeper on purpose: an engineer evaluating the integration surface, a technical co-founder doing diligence, an investor gauging build quality, reached only by choosing to click through from Resources or Guides. It isn't part of the path a buyer is walked down to evaluate or purchase Bryn, and nothing on the buyer-facing pages assumes you've read any of it.
This is a roadmap for a content cluster, not a product roadmap: we're not going to dress up a wishlist as documentation. Everything below is a real, live surface today: a working MCP server, a documented API, and product mechanics you can already read about, including Plays, the rule you set once, in plain terms: when this kind of thing happens, do this, which most of these planned articles touch in some form.
Nine topics, organized by the territory they cover. None of these are published: each card is a stated intention, sourced to the real docs page it's grounded in, so you can go read the underlying material today even before the write-up exists.
Claude, Cursor, and VS Code can each point an MCP client at a live workspace. A walkthrough of the connection itself: what becomes queryable once it's wired in, and what still isn't.
Grounded in: docs.civic.com/bryn/mcp
The interesting design decisions in an agent-facing surface are the refusals, not the endpoints. Where Bryn's MCP server draws the line between what an agent can read and what still waits on a human.
Grounded in: docs.civic.com/bryn/mcp, /bryn/plays
Docs.civic.com currently lists 89 individual endpoint pages. This maps the whole surface, entities, signals, scoring, Plays, outputs, back to the handful of nouns it's actually built from, so it reads as one API, not 89 unrelated ones.
Grounded in: docs.civic.com/bryn/api-overview
Bryn's server-side event path is HMAC-signed rather than left to a bearer token alone. The tradeoffs behind that choice, and a walkthrough of implementing it from a backend, not a browser pixel.
Grounded in: docs.civic.com/bryn/signing
Base URLs, auth, and tenant resolution across the REST and MCP surfaces, written for the engineer setting up the integration rather than the buyer evaluating the product.
Grounded in: docs.civic.com/bryn/api-overview
Named signals, not raw events, are what scoring and Plays consume. The practitioner's version of the mapping layer: how to decide what deserves to become a signal, and what should stay noise.
Grounded in: docs.civic.com/bryn/signal-mapping
The same install reports visits back to Bryn and receives the payload a page uses to personalize for an identified visitor. How one script does both without becoming two things to maintain.
Grounded in: docs.civic.com/bryn/pixel
The score never ships to the client; the page reacts to who an account is and what it's done, not to a number sitting in the DOM. The architecture behind that constraint, and what it rules out.
Grounded in: docs.civic.com/bryn/frontend-recipes, /bryn/icp-and-scoring
Kill switches, holds, cooldowns, and a record of every run: the control-plane design decisions that make automation something a reviewer can stand behind, not a black box with a stop button.
Grounded in: docs.civic.com/bryn/plays