Why Every Revenue Team Needs a Context Layer

Clearskies x The Signal

If you were forwarded this newsletter, join 10,106 weekly readers—some of the smartest GTM operators & founders—by subscribing here:

Thanks for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Hey y’all! 👋

Something interesting is happening inside revenue teams right now. They have access to the best AI that has ever existed: incredible models and harnesses (eg: the agent tooling on top like Claude and ChatGPT) that get better every month. And yet almost every team I talk to is stuck in the same place: they can’t get all that intelligence to do consequential work with their revenue data. The limiting factor isn’t the model anymore. It’s context. AI doesn’t come out of the box knowing your customers, your team, how you sell, or what winning looks like at your company. And no model release will fix that.

The teams that solve context are handing real revenue work to AI: deep research across every deal, analyses they can trust and repeat, workflows deployed to a whole team. And the work compounds, because the system remembers. Everyone else is getting confident answers built on fragments, and most don’t know it yet, because the answers sound right.

The most AI-forward companies have already figured this out. Teams like Cursor and Vercel treat context infrastructure as part of their GTM strategy, with dedicated engineers building and maintaining their context layers full-time. But most companies aren’t doing that. Most can’t—or, frankly, shouldn’t.

That gap is the problem Pouyan Salehi built Clearskies to close. It launches today, open to any GTM team.

I’ve known Pouyan for over a decade. I first met him in San Francisco when he was building PersistIQ, one of the early sales engagement platforms, from the same wave as Outreach and Salesloft (and eventually Gong). Then he and his co-founder, Cyrus Karbassiyoon, built Scratchpad, the tool that made updating Salesforce feel so buttery that reps actually did it, which is why it spread fast, and organically. Now they’re building Clearskies, which they describe as “The Context Layer for Revenue AI.”

Even six months ago, almost no GTM leader was talking about a “context layer” for their team. Now it comes up in half the conversations I have. My bet: over the next 6-12 months, context becomes one of the most-discussed problems in go-to-market. That’s why I was excited for today’s sponsored deep dive into the context layer Clearskies is building.

Here’s what we cover today:

• What a context layer actually is

• What a context layer unlocks, starting with the hard stuff: deep research and win-loss analysis

• Where connectors stop being enough (and where they’re still great)

• Build vs. buy in the AI era

• Governance, portability, and the no-seat model

• Where this goes from here

Alright, let’s get into it.

---

What a context layer actually is

When I caught up with Pouyan recently, he laid out four layers of context:

1. Customer context → the full story of each account: deals, contacts, activity, commitments, risk. Identities resolved across sources, timeline ordered, with what’s changed since you last looked.

2. Team context → who’s selling: roles, reporting structure, segments, territories, tenure, quota, expertise, how they’ve performed.

3. Process context → how you sell: stages, methodology, definitions, approval paths, exceptions, what good looks like.

4. Business context → products or service lines, segments, pricing and packaging, strategy, OKRs, priorities.

Reminder: this is that stuff that foundational models don’t know, out of the box.

Customer context is the hardest of the four to wrangle. The real record of a customer doesn’t live in Salesforce or HubSpot. Your CRM is the secondhand version: the rep’s summary, hazy and half-right. The primary source is the emails, calendar invites, Slack threads, tickets, and call transcripts scattered across a dozen tools (Clearskies’ integrations list keeps growing), and a lot of it lives only in people’s heads.

The obvious fix is to pull all of those sources into one place. But that’s just a database. Context is what you get when the pieces are actually connected: the Acme opportunity in Salesforce, the calls, the email threads, the support tickets, and the Slack channel resolved into one account. Touch points ordered into one timeline, with changes tracked across the account’s history. Your sales process understood, so “stalled at Stage 3” means something. That’s a context layer. The connected picture, across all tools, kept current, so any AI can reason across the full story instead of rebuilding it from scratch on each new query. Revenue infrastructure that hands any AI the full picture of your customer, your team, your process, and your business.

What a context layer unlocks

The unlock isn’t just better answers to quick questions. It’s consequential revenue work—analysis and workflows you’d never have trusted AI with, done reliably enough to hand to a whole team, compounding as the system learns your business.

Start with the thing that’s hardest to fake: deep research and analysis across all of your revenue data. This is the difference between “search my CRM” and “go through every enterprise deal we lost last year—every call, every email, every Slack thread, every support ticket, across every rep—and tell me the real reason.” Done properly, win-loss means pulling each relevant deal, inspecting what happened on it end to end, finding a real answer per deal, storing it, and then analyzing the whole set. For hundreds or thousands of deals, that’s not something you can fake with a sample of your data. Ask a model to do it cold and it’ll hand you a confident answer built on a handful of data points and never mention that’s what it did. In revenue, those errors turn into bad commits, missed forecasts, and churn.

That’s where a context layer becomes an obvious need. A real analysis isn’t just a prompt. It’s the prompt plus the context, plus the memory of what you’ve already learned, plus the technique to run it the same way each time. And when it works, the answer shows its work: how many records it read, which sources, the per-deal summaries you can browse, and where the gaps are.

Once that’s in place, the same infrastructure (basically, a revenue brain, or “System of Intelligence”) does consequential work for every role:

• CEO: voice of the customer, built from what buyers actually said (not a survey), and briefs across the whole funnel.

• CRO: rep performance with the why behind numbers you already have. The dashboard tells you who’s behind quota; the layer shows what’s driving it: thin discovery, single-threaded deals, stalled next steps. Process gaps and objection trends across the pipeline, with the evidence attached.

• RevOps: pipeline health with the why attached: what’s at risk, what materially changed this week, and the recurring conditions that show up before deals stall or die as no-decisions. Plus win-loss, run the way I described above, across the entire book.

• Marketing: competitive intelligence from your own calls (which competitors come up, in which deals, what objections they raise, how they impact the deals, and how your team responds) and market trends straight from the source.

Analysis is half of it. The other half is execution: pre-call briefs that pull from the full history, post-call workflows, CRM fields that update themselves, handoffs that don’t lose the thread. One layer, feeding both. (Clearskies’ use-cases page has more.)

And there’s another new use-case that context unlocks: custom applications. As more teams build their own revenue apps and agents, the context graph is the definitive source to power them. You don’t have connectors to the application you just built; you need a layer underneath it.

What struck me is how far this reaches. It’s the whole team, from CEO to seller. It’s across functions: product, finance, marketing. And it’s across the entire customer lifecycle, from first discovery through handoff, expansion, and renewal. Each function has been asking the same questions about customers and rebuilding the answer in silos. But when you put one shared layer underneath, everyone’s questions get answered (from the same source).

Where connectors stop being enough

Since December, Claude and ChatGPT adoption inside revenue orgs has gone parabolic. Most teams are still early. They’ve turned it on, or they’re about to once security and legal clear the enterprise version, and they’re still working out what to do with it. But they know they should be using it (a lot of FOMO on the timeline, some of it coming straight from the board).

The more advanced teams are wiring up connectors (MCPs). And connectors are good at what they’re for. This isn’t connectors versus a context layer. The question is where each one fits.

Connectors shine on narrow, low-stakes work. One deal, one call, one rep, the data sitting in a single tool, a human who can eyeball the answer. They stop being enough the moment the job needs the full customer picture across tools, across records, across time, and across your entire revenue team. At that point the model reconstructs the picture from scratch on every run: slow, expensive, and every rebuild can come out a little different. Ask for the same pipeline review on Monday and on Tuesday, and you can get two different numbers. You can’t trust it to repeat, and you can’t safely hand it to a whole team. And the answer can only be as complete as the fetch. Nothing tells the model that the contact in the CRM and the voice on last week’s call are the same person, and nothing flags the email thread it never pulled. That’s why connector answers feel fine right up until they’re wrong.

A connector only knows “right now.” It reads whatever is in the tool at the moment you ask, and nothing persists. It can’t tell you what changed, when, or why: how a deal actually progressed, where it stalled, what happened after the pricing call. For anything that depends on how a customer or a deal evolved over time, a read of the present isn’t enough. You need a layer that retains memory.

Connectors are the right tool when the work is in one place, the scope is small, the stakes are low, and a person can quickly check the result. You’ve outgrown them when the work needs the full customer picture across tools and history, and when the output drives a real revenue decision. At that point, the team has to trust the answer without re-running the analysis, and the job is to find patterns and track change over time, not fetch or update one thing.

You’ve probably heard the advice to dump all your revenue data into a GitHub repo and point the model at it. But revenue isn’t code. In code, the context sits in the repo. In revenue, it’s scattered across all the tools your team touches, and stitching it together on the fly is exactly where connectors break.

Build vs. buy in the AI era

Building got dramatically easier (everyone knows this). I’m personally shipping working tools without writing a line of code. But, it’s more accurate to say what got easier is not one-shotting end-to-end production-grade solutions, but prototyping. A prototype is the starting line, not the finish. Getting to something you can rely on takes the patterns you only learn by doing the work. I don’t buy that all SaaS is dead. I think there’ll be far more software, and the unglamorous work of context, paired with expertise and taste, becomes the differentiator.

The context layer is where I see GTM leaders underestimate this the most, because it’s an iceberg. Above the waterline, a prototype comes together on a weekend: wire up a few connectors, load a database, point Claude at it. But it’s misleading. A database with a little data in it feels like a context layer. Below the waterline is what it takes to make it real. Things like identity resolution that holds up across edge cases, semantic search across millions of records (the average revenue team is not standing up a vector database and tuning search infrastructure), memory that persists and improves, permissions that hold. And below that is keeping it alive. Things like new tools being added, schemas drifting, techniques evolving, playbooks and processes changing, and the whole thing has to stay fresh enough to trust your revenue with. It’s less of a one-time project, and more of a permanent allocation of engineering, product, and design to internal plumbing.

Even teams with serious technical firepower like Cursor (who built ChatGTM), Ramp, and Rippling poured enormous effort into building and maintaining the context layer, including the custom harness: the tooling, memory, and orchestration around the model. Build vs. buy is a tale as old as time. You didn’t rack your own servers, you’re not vibe-coding your CRM, and you probably shouldn’t build your own revenue context layer either.

I recently published a piece with Kyle Norton: How to Think About Build vs. Buy in the AI Era (”Build Your Intelligence. Buy Your Infrastructure.”). Clearskies is the textbook case of infrastructure you buy, so your team can spend its time building the agents and workflows on top (that’s the “intelligence” part).

Clearskies also wrote a great piece on how operators are rethinking build vs. buy, with tactical examples from Vercel, a16z, and Browserbase. Including advice like: keep agents small, start with one job (not a platform), and keep GTM in the build loop. It’s worth reading the whole thing.

Governance, portability, and the no-seat model

Governance has to be part of the design. Execs have sensitive conversations with customers, HR sends confidential emails, board-level information floats around. You can’t just pipe your executives’ inboxes into Claude and start one-shotting agents. A real context layer controls what enters the shared context, with permissions and an audit trail. That’s the difference between a demo and something you can deploy across an enterprise.

Portability is the piece I find most interesting, and I think it’s changing fast. Right now most teams wire their tools straight into a single harness. Models are leapfrogging each other every few months, and if you’re hard-wired to one, you can’t move to a better one without rebuilding everything. When you own the context layer, the joins and the history live outside the model, so your answers don’t change when your model does. Swapping in whatever harness and model tops the benchmarks next is a lightweight change, not a migration. You get to select the best performance instead of being locked to one provider. (There’s an IP angle too: you keep your own decision-making and institutional knowledge instead of handing it to a single vendor. But the day-to-day win is simply being able to move.)

Kyle Norton put the compounding effect well:

[The winning companies] will be extremely deliberate about the intelligence layer. They will know what context matters, what memory should persist, what workflows create proprietary learning, and what parts of the system need to remain portable.

That is how AI maturity compounds. One good workflow becomes reusable context for the next workflow. One evaluation loop improves the next model output. One proprietary memory layer makes every future agent better.

The companies that win AI-native GTM will not have the most tools. They will not be the companies with the flashiest demos. They will be the companies whose systems get smarter every week because they own the memory that matters.

Which is why I keep coming back to “memory is the moat.” Clearskies made the same case (every revenue team needs its own brain) and built their layer so your context stays yours and works with any model or surface.

You can see the philosophy in how they price it. No per-seat licenses: you either pay as you go or pay a flat rate for the infrastructure, and the whole team gets access. And for the team using it, there’s no new app to learn. You use it through Claude, ChatGPT, Slack, or whatever surface fits. The app is for the builders and admins setting it up. The layer clears a higher bar than connectors where it matters: complete and current, shared across the team, governed, repeatable, portable across models, and priced so your token bill doesn’t balloon each time context gets re-stitched.

Where this goes from here

I expect the model and the harness to decouple. Open-source harnesses show up, and teams route task-specific models through their own context layer. When you own the context layer, you can plug it into anything.

Pouyan’s read on the market right now is that most companies’ “AI strategy” is “we bought Claude.” Few have done anything meaningful with it yet, and even fewer see context as the actual bottleneck; most assume connected tools and better models will sort it out. Which means the teams that figure out context now will pull well ahead of the ones waiting.

The adopt-AI-at-all-costs phase is already sliding into the rear-view mirror. CFOs are starting to look at the Anthropic invoice and ask, “what did we actually get for this?” The teams with a context layer their GTM org (and the rest of the company) can build on are the ones whose results compound. Everyone else keeps shipping one-off AI workflows they have to rebuild each time. That’s the asymmetric bet Pouyan, Cyrus, and the Clearskies team are making. After years of watching them go one layer deeper with each product they build, it’s the most convincing version I’ve seen yet.

Context as infrastructure is the story of 2026.

Visit Clearskies and start building for free, or book a 1:1 with their team.

Or, if you just want to chat more about context strategy and what you’re building, Pouyan is happy to connect and share learning → reach out to him on LinkedIn. He reads the comments here too, and he told me he’s happy to compare notes with anyone working through this.

---

That’s it for today!

As always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡