Where the system meets people
The four planes describe how the system is built. This part describes where it is encountered: by the operators who direct it, by the staff who work inside the system of record, by the market it reaches and on the web, which is the largest surface on which operators and market meet.
Section 12 · Part three
The agent surfaces
Section 2 argued that conversation is becoming the primary surface for directing software. This section describes what that means in practice for the people who meet the system. It begins with the operator surface, the conversation through which a GTM operation is directed, because that is where the architecture is felt most, then shows that it is one instance of a general pattern: one engine, surfaced wherever people need to meet it, each surface carrying the trust its audience requires.
Operators get one conversation that reaches every capability, with screens kept for seeing, approving and overriding. The same engine then surfaces wherever staff and the public meet it, each surface carrying the trust its audience requires. Surfaces multiply as the motion grows; the engine does not.
12.1One conversation, every capability
The operator surface is a single conversational interface to the whole system. It is where the weekly pipeline review happens, where outreach copy is approved, where a new integration is requested and where last quarter’s objections are analyzed. The operator does not choose a tool and then a function within it. The operator states what is needed, and the Cognition Plane routes the request to the capability, tool and data that can satisfy it.
Two properties make this more than a chat window over a stack. The first is that the interface is declarative: the operator describes the outcome, not the steps. “Find every account that went quiet after a pricing conversation and draft a re-engagement note for each” is a complete instruction. The second is that the interface is shared. Operators, staff working inside the system of record and the public concierge’s visitors all meet the same engine through their own surfaces, with the same context libraries and guardrails, so what any of them says and what the system does are never out of step.
12.2Three jobs the screen keeps
The graphical interface stays for the work conversation does badly. Seeing: a signed preview of a page before it is published, a dashboard of the metric set, a rendered proposal. Approving: the human-in-the-loop inbox where outbound copy, premium proposals, suppression disputes, partner payouts and new paid campaigns wait for a decision. Overriding: the operator console from which a person can pause a workflow, take over a conversation or roll a change back. None of these is a place to operate a tool. Each is a place to look, decide or intervene, and the conversation is where the work resumes.
12.3One engine, many surfaces
The conversational surface an operator works through is one instance of a general pattern. The same engine, with the same context libraries, the same memory and the same guardrails, can be surfaced wherever people need to meet it: inside the system of record for the staff who work there, at an operator console for the people directing the work and on the public website for visitors. Each surface is defined by its audience and carries the trust regime its audience requires: approval gates for staff and operators, guardrails and human escalation for the public. Surfaces multiply as the motion grows; the engine does not. The pattern is the conversational analogue of trust routing in Section 14: calibrated trust, applied at the boundary where a person meets the system.
Agent surfaces and sub-agents are different axes and should not be confused. A surface is where a person meets the engine. A sub-agent is an internal specialist beneath the supervisory layer of Section 8, with its own instructions and bounded tools, and no person addresses it directly. The operator-facing surface is where the supervisory layer’s orchestration of those specialists becomes visible and directable: the operator states the outcome, the supervisory layer routes the work across the specialist groups and the surface is where the operator sees what was done and approves what waits.
12.4Three audiences, three trust regimes
Three audiences account for nearly all of the people who meet a GTM system, and each needs a different surface.
The staff who work inside the system of record need the engine where they already are. A surface embedded in the system of record lets them describe an operation in plain language, see it demonstrated on the screen in front of them or have it performed, with a human-in-the-loop gate on every write. Where the system’s own interfaces reach further than its APIs, browser automation bridges the gap, so the surface is not limited to what an integration happens to expose. The trust regime is the one a trusted employee already has: act freely on reads, confirm on writes.
The operators who direct the motion need the surface described in §12.1 and §12.2: one conversation that reaches every capability, routes the decisions that stay with people and carries KPI alerts as they happen. This is the surface through which the supervisory layer’s orchestration of the specialist groups is directed and overseen. The trust regime is approval: outbound copy, premium proposals, suppression disputes, partner payouts and new paid campaigns wait here for a decision.
The public needs a surface on the website that answers, qualifies and guides, around the clock, and that knows what it must not do. Its input surface is the open internet, so its trust regime is the strictest: guardrails on what it can say and do, no writes beyond the record of the conversation itself and escalation to a human the moment a conversation needs one. Section 13 lists this surface among the channel surfaces where someone who has already arrived is served; Section 14 describes the web platform it lives on.
Because the three share one engine, what one surface learns is available to the others under the same guardrails. A visitor’s question on the public surface can become context the operator surface raises; a suppression decision made on any surface holds on all of them. Further surfaces, resident in an inbox, a social feed or an event, follow the same rule: a new audience gets a new surface with its own trust regime, and the engine stays one.
Current implementation
Operators work through the agent engine’s conversational interface. Approvals arrive as structured requests in the same conversation and are also mirrored to a review queue. Signed preview links for web changes come from the governed change platform described in Section 14. A single Agent Zero instance powers three surfaces. The GTM Agent is the operator surface of §12.1 and §12.2; it is primarily responsible for managing and orchestrating the sub-agent groups of Section 8 on the operator’s behalf, routes the decisions that stay with people and carries KPI alerts as they happen. The CRM Agent is the staff surface, embedded in the CRM interface, and delivers Describe / Demonstrate / Do with human-in-the-loop gates on writes and browser automation bridging what the underlying APIs do not reach. The WEB Agent is the public surface, the AI concierge resident on the website and exposed through a chat widget, engaging visitors under guardrails with escalation to a human. All three share one engine, one Context Engine, one memory and one guardrail layer; further surfaces, resident in email, social or events, can be added on the same instance.
Give operators one conversation that reaches every capability, and keep screens for seeing, approving and overriding. When the interface is declarative and shared, the learning curve collapses to one surface and the work moves to the system. Then surface the same engine wherever people meet it, with the trust regime each audience requires: surfaces multiply as the motion grows, the engine does not.
Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §12. revworx.ai/architecture/12