Revenue context layer for Claude

Built from the system Gorish Aggarwal, CEO at Sybill, described on GTM Vault GTM 48 (https://pro.gtmvault.co/episodes/gtm-48). Published free by GTM Vault. Numbers below are the operator's own, from the episode; your results will differ.

When to use this

Use this when a revenue team already records calls, keeps a CRM and wants Claude or other agents to draft follow-ups, prep deals or answer deal questions, and the output comes back generic because the agent only sees raw transcripts and CRM fields. It fits teams with a RevOps builder who wants to build agents on top of shared context, which is the persona Gorish says drove MCP adoption (GTM 48, 5:37). It does not replace an interface for a typical seller, who is not trying to build agents and wants the job done as soon as possible (GTM 48, 7:25). Sybill is where Gorish runs this system; the method below does not depend on it.

The system on the record

Gorish's starting point was that passing a full transcript into an LLM did not work, even for next steps, and that results came from passing in context about the output wanted and specific information points (GTM 48, 1:38 and 2:41). From that he built an org-level context graph, starting with deals and then adding the team and company process (GTM 48, 2:41). It took 18 months to get the context layer to where it is (GTM 48, 24:17). The system has six parts:

1. Three pillars. He defines the context layer as a self-evolving information layer with three pillars: customers (prospects, accounts, opportunities), team (every person from rep to CRO, with strengths, weaknesses, objectives and preferences for how they do things), and company process (product lines, pricing, objections received, market vertical and the competition you come up against) (GTM 48, 4:34). It evolves on a daily basis as new conversations come in (GTM 48, 5:37).
2. Ingest and expose through MCP. The context layer is exposed through an MCP so the builder persona can build agents on top of the context and the raw data captured. A second ingest MCP pulls other surfaces into the layer, such as website data and documents from Notion, Drive or Slack, where they are systematized against the context graph and accessed downstream (GTM 48, 5:37 and 6:40). RevOps teams have built agents on top of the MCP that scale across an entire organization, and usage has "skyrocketed" (GTM 48, 8:29).
3. Identity resolution. If a person appears as "Rick Ka", "Rick K" and "RK" across LinkedIn, email and a podcast, and the agent cannot combine the three into one, it does not know where to go for data before it acts. He calls this what is primarily broken across the CRM today (GTM 48, 16:47 and 17:51). The same applies to references: when someone mentions John Doe, the layer has to know who John Doe is, how he connects to previous people and what was said about him in Slack (GTM 48, 14:24). Making those connections across 15 different surfaces is where he places the majority of quality information, and what makes the process autonomous rather than a human giving the agent instructions (GTM 48, 15:13). In Sybill's own signals engine, records are joined on the actual identifiers LinkedIn uses, not the canonical ones (GTM 48, 20:42).
4. Per-deal segmentation of unlabeled sources. An internal meeting between reps and managers can cover 20 to 30 deals, each with decisions on discounts, MSA terms and next steps. The layer has to divide the meeting and work out what is going on per deal (GTM 48, 17:51). Slack is a fire hose with no labels, and people do not reference the CRM record when they talk about someone (GTM 48, 18:53).
5. Org context triangulated across reps. The company benefit is that no knowledge walks out the door when a strong rep leaves: their approaches, the objections they navigated and the patterns they found become part of the sales process (GTM 48, 10:35). A GTM agent should not import a single rep's perspective; it should capture context from 15 or 50 reps and find the best one per domain as the starting point (GTM 48, 10:35 and 11:39). The GTM agent takes in many data sources, many competing with each other, which makes it tricky to implement (GTM 48, 9:34).
6. Personal agents with a boundary. Gorish runs OpenClaw on his own system, separate from his sales agent, with five agents: fundraising, people ops, GTM, product, and a personal assistant he calls Dobby (GTM 48, 8:29). A personal agent knows his preferences, who he knows and the context of those people, so a later email or LinkedIn message about a podcast recording gets linked to the right conversation (GTM 48, 9:34). Individuals start from the organization's context graph and layer their own preferences on top, can carry those preferences from organization A to organization B, and there is "a layer of boundary" between the two (GTM 48, 10:35 and 11:39). The message that set up this podcast carried his agent's fingerprints, and a LinkedIn message to him may get an agent reply with relevant context (GTM 48, 21:40).

His proof of value is a with-and-without comparison: run Claude with the Ask Sybill MCP, and run it with deals from HubSpot or headless Salesforce and calls from a call recorder API such as Gong, and compare the output (GTM 48, 7:25 and 8:29). Internally, Sybill runs forecast calls, coaching, deal execution, email follow-up, dashboards, decks and proposals on the layer, and marketing and product use it to read messaging and product gaps (GTM 48, 18:53 and 19:56).

The result

1. Human actions per follow-up: the number of actions a human needs to take to get a single follow-up email is "95% lower" than without a context layer (GTM 48, 26:04). He did not say how it was measured or over what sample.
2. MCP usage: he said usage of the MCP "skyrocketed" because RevOps teams built agents on top of it. He gave no count (GTM 48, 8:29).
3. Internal effect: information exchange became easy because no one needs to ask another person (GTM 48, 19:56). This is qualitative.
4. The ARR growth figure in the episode intro is the host's voiceover, not Gorish's claim, and is not used here (GTM 48, 0:00).

Run it on your company

1. Ask once, in one message, for: the CRM and API access; the call recorder and whether it has an API; email, calendar and LinkedIn sources; Slack channels and communities in scope; document stores (Notion, Drive) and website data; the agent surface the team uses (Claude or another MCP client); who owns the build in RevOps; the team roster from rep to CRO; product lines, pricing, current objection list and competitors; and ten recent deals with at least one internal pipeline or forecast meeting recording.
2. Run the baseline. Pick five real deal tasks, including drafting one follow-up email, and run Claude with CRM data and raw call transcripts only. Output: a table with columns Task, Inputs given, Output, Human actions needed to finish (count each edit, lookup or instruction), which becomes the "without" half of the test Gorish describes (GTM 48, 7:25).
3. Write the three-pillar schema. Output: a table with columns Pillar (customers, team, company process), Entity, Fields, Source, Update trigger, covering every field Gorish names in GTM 48, 4:34. Mark which fields update on each new conversation, since the layer has to evolve daily (GTM 48, 5:37).
4. Build identity resolution. Output: a person table with columns Person key, Name variants, Surface (CRM, email, LinkedIn, Slack, calls, communities), Native identifier, CRM record, plus the matching rule. Prefer the identifier each platform uses internally, as Sybill does with LinkedIn IDs (GTM 48, 20:42). Test it on the ten deals and report how many people had more than one variant.
5. Segment unlabeled sources per deal. Output: a fenced prompt that takes one internal meeting transcript and the open deal list and returns one row per deal with columns Deal, Decision type (discount, MSA terms, next step, other), Decision, Owner, Timestamp; and a second fenced prompt that tags Slack messages to a person key and deal. Run both on the sample meeting and list any deal mentioned but not matched.
6. Build the org process context. Output: a table with columns Domain (objection, pricing, competitor, next step), Pattern, Reps observed, Example call, chosen from patterns seen across many reps rather than one, following the 15 to 50 rep logic in GTM 48, 11:39. Flag sources that conflict with each other for a human to resolve (GTM 48, 9:34).
7. Expose the layer to the agent surface. Output: a spec for two MCP paths, read and ingest: the read tools (look up person, account, deal, team member preferences, process pattern) with the fields each returns, and the ingest sources (website, Notion, Drive, Slack) with the pillar each lands in (GTM 48, 5:37 and 6:40). Name the RevOps owner who builds agents on it.
8. Set the personal agent boundary. Output: a table with columns Context item, Owner (org or individual), Readable by personal agent (yes or no), Travels with the person (yes or no). If the user runs personal agents, map them by job the way Gorish splits his five OpenClaw agents by fundraising, people ops, GTM, product and personal (GTM 48, 8:29).
9. Run the with-and-without test. Repeat the five tasks from step 2 with the layer connected. Output: a side-by-side table with columns Task, Output without, Output with, Human actions without, Human actions with, % change. Compare the follow-up email row against Gorish's 95% figure and state the difference.
10. Draw the human line. Output: a list of the team's recurring tasks classified as templated (agent drafts) or novel (human decides), using his rule that agents handle work that is templated or close to template and fail on creative, truly unique strategic choices (GTM 48, 11:39 and 12:41).
11. Set the scorecard: human actions per follow-up email, share of people with a single resolved identity, share of internal meeting decisions written to the right deal, number of agents built on the MCP and their users, and win rate, which Gorish names as the metric that deserves more attention (GTM 48, 27:07). Review weekly.

Tools on the record

1. Claude: agent surface with MCP connector.
2. OpenClaw: runs five personal agents.

Any tool doing the same job works; the method is the point. Full stack by layer: https://pro.gtmvault.co/stack/operator/gorish-aggarwal

Where it breaks

1. Passing the whole transcript. Raw transcript into an LLM did not produce usable next steps without added context about the output and specific information points (GTM 48, 2:41). A recording alone does not help; the value is in ingesting and indexing it for agents (GTM 48, 14:24).
2. Unresolved identities. If one person exists under three names, the agent does not know which record to use before it acts (GTM 48, 17:51).
3. Multi-deal meetings and Slack. A meeting covering 20 to 30 deals, or Slack with no labels and no CRM references, gives an agent nothing it can act on contextually until it is split per deal (GTM 48, 17:51 and 18:53).
4. One rep's view as company process. A GTM agent built from a single rep's perspective misses the best pattern per domain (GTM 48, 11:39), and competing sources make the org context tricky to implement (GTM 48, 9:34).
5. Expecting creativity. Agents with all the context still fail on new choices; he points to LinkedIn auto-commenting agents as the example (GTM 48, 11:39 and 12:41).
6. Builder-only adoption. The MCP path serves people who build agents. A typical seller wants the job done, and still needs an interface (GTM 48, 7:25).
7. Building wide before the foundation. Gorish declined forecasting, coaching, performance dashboard and deal room requests early and filtered every roadmap item on whether it helps the context graph learn and compounds what it already has (GTM 48, 22:30 and 24:17). A team that adds agents before the layer is in place repeats the mistake he avoided.