tl;dr A feedback call that was supposed to be about our product turned into the other founder describing our architecture back to us, for his product, in his market, without being led there. His framing: software you sell now lives on three surfaces at once, the tool's UI, the agent inside the tool, and the agent outside it that the customer brings, reaching in over MCP. And once you let an agent do the work, the record is how you check on it and steer it. When two teams in unrelated markets arrive at the same shape independently, that is not positioning. That is architecture.
The call was supposed to be about our product. We were collecting feedback on Bryn, and for the first few minutes it went the way feedback calls go. Then the founder on the other side, a person who has spent about twenty years building marketing software, stopped answering our questions and started describing an architecture. His architecture, for his product, in his market.
It was ours. Not adjacent to ours, not rhyming with ours. The same three surfaces, the same reason they exist, and the same mechanism for staying in control once you let an agent act. Nobody led him there. That is what this note is about.
In his framing, software you sell no longer lives in one place. It lives on three surfaces at once.
Surface one is the tool's UI. The screens. The place a human logs in, looks around, configures things, and decides. Every product has this surface; for twenty years it was the only surface that existed.
Surface two is the agent inside the tool. The product stops waiting for clicks and starts doing the work itself: watching, drafting, executing, within whatever bounds the operator set. Same product, different operator.
Surface three is the agent outside the tool. This is the one most roadmaps miss: the agent the customer brings, reaching into your product over MCP. Your product stops being a destination and becomes a set of capabilities somebody else's agent can call.
He is building on all three. So are we.
One company describing this model is marketing. You should discount it accordingly, including when the company is us.
Two companies building it independently is something else. We operate in unrelated markets, sell to different buyers, and got here by different roads. Neither of us had seen the other's roadmap. And the shape that came out is the same, down to the ordering of the surfaces and the thing that holds them together.
Independent convergence is the strongest signal a thesis gets before the market votes. When separated teams keep landing on the same structure, the structure is probably not a preference. It is probably what the constraints demand.
The part that made us sit still was not the surfaces. It was that he reconstructed, unprompted, the exact problem our audit record exists to solve, and then the solution.
His chain went like this. Deterministic software is too limited: rules only handle what the rule writer foresaw. So you want the agent to do the work: that is the whole point of hiring one. But once the agent does the work, you lose visibility: the work now happens where you are not looking. So you need a record of what the agent did, because the record is how you "check on the agent" and steer it without standing over it.
THE AGENT VISIBILITY CHAIN (as a founder we spoke with recently assembled it, unprompted, for his own product) STEP 01. Deterministic software is too limited. Rules only handle what the rule writer foresaw. The interesting work is the rest. STEP 02. So you want the agent to do the work. That is the whole point of hiring one. Not answers, work. STEP 03. Once it does, you lose visibility. The work now happens where you are not looking. This is the step most miss. STEP 04. The record is how you check on it and steer. Inspect the run, correct the Play, keep the authority without standing over it. He named the problem the record solves before anyone explained it. Paraphrased field observation from a recent conversation. Not a benchmark, not a customer result.He named the problem the record solves before anyone on our side explained it. We have written before about how Bryn answers the three questions every operator eventually asks an agent; he arrived at the questions on his own, from his own product, in his own market.
One more observation from the call, and it matters for anyone shipping on these surfaces: most users are not ready for the agent surfaces on day one.
They start on surface one. They click around, they build trust, and then they cross over, first letting the agent inside the tool carry work, later wiring their own agent in from outside. The surfaces are sequential for most people and parallel only for the early crowd. Which means public copy has to work for people who are not there yet, without lying to the people who are.
Bryn is the governed execution layer that runs Plays through your stack, and it runs on exactly these three surfaces today.
Surface one is the control plane: the UI where the growth owner defines Plays, approves them, and reads runs. Surface two is Bryn acting inside the product on approved Plays, doing the work while the moment is still a moment; Wednesday's note took one apart frame by frame. Surface three is MCP access for the customer's own agent: the same signals, scores, and runs, reachable by whatever agent your team already operates.
And the record is the spine across all three. Every run writes its receipts as it works, and the same run is inspectable from the UI, from inside the product, and from the customer's own agent. Three surfaces, one set of proof.
THE THREE SURFACES (interactive: select a surface to see who operates it, what it is for, and what governs it) SURFACE 1, THE TOOL'S UI. Who operates it: the human. In Bryn's case, the growth owner in the control plane. What it is for: configuration, review, and decisions: define the Plays, approve them, read the runs. What governs it: permissions, and the operator's own eyes. This is the surface where authority lives. SURFACE 2, THE AGENT INSIDE THE TOOL. Who operates it: the product's own agent. In Bryn's case, Bryn itself, acting on approved Plays. What it is for: doing the work while the signal is warm: watching, drafting, executing, within the bounds the operator set. What governs it: the Play definition the operator approved, and the per-run record every action writes. SURFACE 3, THE AGENT OUTSIDE, OVER MCP. Who operates it: the customer's own agent, whatever the team already runs. What it is for: reaching in: the same signals, scores, and runs, callable as governed tools from outside the product. What governs it: the same permissions and the same record as everything else. No side door. The record is the spine across all three: the same run, inspectable from every surface.The do-it-Monday version. Take the tools you pay for and put each one on the map: which surface does it actually live on, who operates it there, and what checks the agent when it acts?
Two readings fall out fast. A tool that lives only on surface one is a dashboard, whatever its landing page says. And anything acting on surface two or three without a record is a liability, because you have granted the work and kept none of the visibility.
The three surfaces are where software is going. The record is how you go there without losing the steering wheel. We believed that before the call. We believe it more now that someone else built the same thing for different reasons.
Bryn starts at $49 a month with a 7-day trial. Pricing is public at civic.com/bryn/pricing.