The Revenue Leadership Podcast · 2 Sep 2026 · From the week of 31 August
E74: Your Agent Isn't Broken. Its Foundation Is. | Jonathan Moss, EVP Growth & Partnerships @ Experity
These are notes on the conversation, checked against its transcript. The episode itself has the full discussion.
In brief
Kyle Norton interviews Jonathan Moss, EVP of Growth and Partnerships at Experity (HIPAA-regulated health tech), on building go-to-market AI as a system rather than a set of disconnected pilots. Moss lays out six layers (data, brain, intelligence, orchestration, agents, interface), admits he first built them top-down, and walks through Experity's GTM Intelligence Center on Snowflake and AWS AgentCore, which lets anyone pull a three-year trend with insights in under 30 minutes without RevOps in the middle. They cover the near-miss of putting Experity's business logic inside a third-party product, why giving budgeted headcount to the data team worked when an ROI pitch did not, preventing agent sprawl, and moving from functional RevOps silos to outcome-based pods. The episode closes with both men's personal agent stacks, including Moss's 121 agents and 57 skill files. The central argument is that AI should be used to redesign workflows on top of a company-owned data and context foundation, not bolted onto existing processes.
For founders
- Moss argues the AI 'brain' (business logic, policies, IP and company context) should be built in-house; if you buy a platform, portability is the most important test.
- Moss built his AI stack top-down from agents and interface and kept hitting missing context and cross-system limits; he says he should have started at the data layer.
- Moss says AI added to an existing process mostly adds a step; the gains come from mapping the workflow and redesigning it to remove, automate or augment work.
- When an ROI pitch failed to get the data team to prioritize GTM, Experity moved two to three FTEs of revenue-org budgeted headcount to the data team, and that worked; Kyle Norton did something similar at Series C.
- Moss says revenue leadership now requires P&L fluency, hands-on AI agency and end-to-end ownership of revenue and the system beneath it, and if the CRO doesn't evolve, a system owner needs a seat at the strategy table.
For revenue leaders
- Experity's GTM Intelligence Center replaced the RevOps request queue with a self-serve chat over a semantic layer, producing three-year trends with insights and recommendations in under 30 minutes.
- Moss made users responsible for correcting bad AI outputs so fixes flow back into the brain, so the data improves with use instead of degrading the way CRM data usually does.
- While running RevOps, Moss began moving Experity's RevOps from marketing, sales and CS ops silos to acquisition, expansion, retention and value realization pods, each with a product manager, engineer, process SME and data support. The transition is ongoing, and he no longer owns RevOps.
- Moss now hires generalists with revenue-architecture grounding and demonstrated AI-building agency, and contracts niche specialists such as Pardot experts by the hour.
- Moss says Experity limited agent sprawl by giving everyone access to connected AI tools on one governed platform and running weekly 'show us what you did with AI' showcases, after restricting access early on backfired.
What was said 33, most useful first
Experity's GTM Intelligence Center lets anyone produce a three-year trend with insights and recommendations in under 30 minutes, without RevOps in the loop. Listen
The old flow was linear and people-heavy: request to RevOps, prioritization, data pull, visualization, dashboard and analysis by people who weren't sales, marketing or CS domain experts. The target outcome was analysis 'federated down to the lowest common denominator of the user.' To get there Experity consolidated data in its warehouse, added business context to fields through a semantic layer so the model wouldn't misinterpret CRM fields, put LLMs on top, and gave users a chat interface that answers questions and builds charts.
“we're able to build like three year trends of visual, get insights and recommendations in less than 30 minutes”
Moss required users to correct bad AI outputs inside the system rather than work around them, so each correction feeds the brain and the mistake doesn't recur. Listen
Moss says users' default was to take a bad output and go do the analysis the old way elsewhere. Experity's message to operators was that they no longer need RevOps for the information, but they must teach the system why an output is wrong and what context is missing. He calls this a paradigm shift that was part of the process change.
“If the system gives me a bad output and I know that it's a bad output, I'm actually teaching it that it is a bad output”
Experity's ROI pitch failed to get the data team to prioritize GTM data, but allocating two to three FTEs of the revenue org's budgeted headcount to the data team succeeded. Listen
Moss's pitch was that acquisition, expansion and retention fund everything, including the data team, so GTM data is the easiest ROI. It produced only a little momentum. In planning, the revenue org instead gave two to three budgeted FTEs to the data team, which hired net-new people focused only on the GTM domain.
“we're actually going to allocate, you know, two, three FTEs of the overall revenue organization to this because it's so important”
When his company raised its Series C, Kyle Norton made an applied AI leader for sales the first role in the new headcount plan and placed it in the data and biz ops team. Listen
Norton says he carved this role out above anything else and didn't mind that it sat outside sales, because he just needed the work done. He has seen the same pattern elsewhere and thinks trading revenue headcount for dedicated data or AI capacity is probably replicable. He explains that data teams treat the revenue leader as one stakeholder among many, alongside product and the CFO.
“The first role that I put into the new headcount plan was an applied AI leader for sales.”
Experity first restricted AI tools to a select group, which angered people and pushed them to outside tools; it then gave everyone access to connected tools to curb sprawl. Listen
Moss says the fix was, first, access for everyone and, second, tools connected to the right systems and context on AgentCore. He notes that the agent is the easiest part to build once the framework, tools and context exist. He also hedges that being a regulated healthcare company probably helped limit rogue building.
“We only had a set group or a set number of people that had it. And what we learned was, A, it pissed a bunch of people off”
In regulated health tech, GTM work rarely touches PHI, and the bigger barrier was people treating everything as regulated. Listen
He says the likelihood of GTM using HIPAA-protected data is very small, apart from things like customer success calls where a customer raises it. Unwinding that thinking took Experity time. AWS controls and walled gardens gave the team confidence it was staying compliant.
“the problem is in this industry people think about everything as regulated and they put it all in the same bucket.”
Moss now hires generalists grounded in revenue architecture who can demonstrate building with AI, rather than marketing-ops or sales-ops specialists. Listen
His criteria are a foundation in revenue architecture and how recurring-revenue businesses work, generalist GTM and operations understanding (with domain-specific agents such as a marketing ops agent filling gaps), curiosity, systems thinking and agency. He says people who use AI only as search are probably not a fit. He sometimes hires from engineering or other functions and teaches revenue architecture.
“The second thing is we look for more generalists than specialists.”
Experity contracts narrow technical specialists, such as Pardot experts, by the hour through agencies, RevOps flex labor or Upwork instead of hiring them full-time. Listen
Moss says the need varies from about 10 to 40 hours a week. Contracting it frees full-time headcount for generalist, AI-capable builders.
“And if we need specialties we can contract that for the amount of time that we need it because we also don't need it all the time.”
If the CRO doesn't evolve into a system owner, a growth- and RevOps-minded leader responsible for the revenue system needs a seat at the strategy table. Listen
He compares it to companies having both a CPO and a CTO over different parts of the product: a CRO may own outcomes and people while someone else owns the system. He says that person can't be layered down, regardless of title.
“you may need someone that's responsible for the system, but that person cannot be layered down.”
Every agent sits on six layers (data, brain, intelligence, orchestration, agents, interface), and without designing that system AI won't scale beyond a few workflows. Listen
Moss describes the layers as: data in a data lake (quantitative and qualitative); a 'brain', a semantic layer of policies, IP and decisions that understands how the company operates; an intelligence layer of models such as OpenAI; orchestration across teams, workflows and agents; specialized agents; and the interface where people work (Teams, Slack, Salesforce or a custom conversational UI). He says you can hit a small outcome on one workflow without it, but it won't scale beyond maybe a few workflows.
“So I think the first thing is if you're not thinking about the system that you're building, you're not going to be able to scale it.”
Moss built his AI system top-down from agents and interface and says he should have started at the data layer. Listen
Starting with agents and interface, he kept hitting the same problems: agents lacked context, couldn't work across multiple systems and tools, and couldn't do what he needed. Solving those pushed him all the way down to the data, which he calls a lesson learned.
“I started at the agent and interface, and every time I started working to build the system, I kept running into things. Why does it not have context?”
System-building and workflow use cases should run in parallel, not in sequence. Listen
He responded to Kyle Norton's point that large companies need early wins. He says the system is the long pole in the tent, so you need a long-term picture of it and should start conversations about where things will break while you build individual workflows. His view is that people go wrong by treating it as sequential, starting with workflows and not thinking about the system at all.
“So I think it's a parallel path, it's not a sequential one.”
A few high-value use cases can earn the credibility to then demand infrastructure investment, especially in large companies with many stakeholders. Listen
Norton describes a big public company where around 50 people are squabbling over ownership, so starting with system fundamentals can stall. He suggests fixing data first but perhaps not all of orchestration, and spinning up a couple of use cases that don't touch six systems but produce real value. He adds that building workflows also shows where the system is broken: missing context, identity not reconciled across systems, or missing access.
“It's like, hey, let's just get a couple interesting use cases up and running, build some value, demonstrate and build momentum. And, and then you have enough credibility to say, okay, I can't do the next thing without the infrastructure being there.”
Adding AI to an existing process mostly adds a step; real gains come from redesigning the workflow around a business outcome. Listen
His sequence: start with the business outcome or constraint rather than an AI use case; map the current workflow, including handoffs, exceptions, required data, where context drops, and which meetings exist only because information or decisions are locked up; redesign by deciding what to remove, automate or augment; deploy with change management and measurement; then run a learning loop of user feedback and tweaks before scaling. He compares this to deploying a product.
“AI is not something that you add into an existing process because then all you're typically doing is you're just adding one extra step or one extra layer, but you're not really solving the business outcome or the root problem.”
RevOps should operate as a revenue product function, because the GTM tech stack is effectively a product built partly on third-party integrations. Listen
He says RevOps should have been working this way long ago: products also rely on third-party integrations rather than building everything. Norton describes the work as studying user behavior and jobs to be done, writing a PRD, redesigning, shipping an MVP and iterating, and Moss agreed that operators now have to think like product people.
“So it's really, you are managing a product and we have to think about it that way.”
Experity didn't wait for clean data: it started with high-impact workflows where data was good enough or the gaps were known, and improved data through user corrections plus ongoing data work. Listen
Moss says the key was not biting off more than they could chew. Known gaps were filled with context in the brain. Data then improved on two tracks: users correcting outputs, and the data team continuing to fix tables, map relationships and extend the semantic layer. He contrasts this with CRMs, where data usually degrades with use.
“every time someone uses a CRM, the data gets worse. But in this scenario, what we wanted and the way we thought about it was as they use it and correct it, I need the data to get better.”
Moss recommends using your data warehouse vendor's experts for semantic-layer and data-structuring work; Experity used Snowflake's team alongside its own data team. Listen
Experity's structural data work was done by its internal data team with help from Snowflake, which Moss says provided resources on how and why to do it and how to approach it. He says Experity had some internal expertise, but advises anyone with a data lake or third-party vendor to use their expertise.
“if you've got a data lake or you got a third party vendor that you use, you know, leverage them for their expertise”
Experity's GTM AI stack runs on Snowflake for data, a GitHub-stored brain of code and context, AWS AgentCore for runtime and governance, and a headless set of interfaces. Listen
Moss says AgentCore provides orchestration, observability, built-in evals and per-user and per-agent permissions, and that this is what made the work possible in HIPAA-regulated health tech. Users reach it through an internal chat UI, Teams, or their own Claude or Codex instances, all connected to the same back end. He cautions that Experity still has access-control and enterprise-scale issues to work through.
“we have Snowflake as our kind of data layer. The brain is basically a bunch of our code, internal context, things like that.”
Moss stopped Experity from putting its business logic and company context into a third-party product, arguing the brain is proprietary and must be built in-house. Listen
His two objections were lock-in, which he sees as a big risk while things are moving fast, and giving a vendor the company's business logic, processes, context and IP. He says some parts of the stack should be bought, but the brain and harness are where to spend time building. Norton noted that the in-house technical capability to do this is not the norm in his experience.
“we were about to put all of this into a third party. And I was, and, and I was like, whoa, whoa, whoa, before we do that, how Are you going to port it over to something else now?”
Moss is not against buying a platform for the company brain, but says portability is the most important factor if you do. Listen
He says you may outgrow the platform, get in too deep, or later have the expertise to build it yourself, so ease of moving off it matters most. Norton said platforms are acceptable as long as you can see the intelligence inside them and take it out, because the brain is a compounding asset.
“the portability is the most important factor if you're going to do it”
Connecting Claude to business systems over MCP and asking questions produces fabricated answers, which is why a purpose-built harness is needed. Listen
Norton says the model fills gaps and makes things up because it is optimizing for an answer the user will thank it for, and the user often doesn't know enough to give accurate feedback. He presents a structured harness or harness platform as the fix for getting correct answers.
“if you just, you know, MCP your Claude code instance or your Claude desktop instance into a bunch of things and ask it questions, it's, it's lies. It lies to you. It just, it fills in the gaps.”
Experity runs weekly open sessions where employees showcase what they built with AI, to steer bottom-up building onto the central connected platform. Listen
People demo what they built and how, and the pitch to employees is to build the agent on the internal platform rather than going to some other tool, because it's easy and already connected. Moss credits this mix of centralized and decentralized building on one connected base with keeping sprawl down.
“Like, show us what you did with AI this week or these kind of open shows where people will come and they'll showcase what they did, how they did it, et cetera.”
Kyle Norton describes four levels of AI maturity: chat as a Google replacement, working agents and workflows, AI as infrastructure, and recursive self-improving loops. Listen
At level three, the company builds infrastructure that others build within, so they don't have to handle MCPs, integrations and governance themselves. Level four has agents watching, building and improving other agents; Norton runs a personal bot that monitors his other bots. Moss said Experity hasn't reached level four in GTM, with such experiments more common in engineering, and stressed that Experity employees still span all four levels.
“level three is AI as infrastructure. And this is AI as infrastructure. This is now you're building things that then people can build within”
Moss began moving Experity's RevOps from functional ops silos to outcome pods for acquisition, expansion, retention and value realization. Listen
Each pod, modeled on modern software pods, has a product-manager type, an engineer who can build, a process-oriented GTM SME (the traditional ops role) and data support. Pods work in cycles, stakeholders set the roadmap, and pods own a journey end to end, shipping capabilities or new processes instead of passing work between marketing, sales and CS ops. Value realization covers the stretch from commitment through implementation and adoption. Moss says the shift has taken over a year and is not complete; his role changed a few months ago, so RevOps is no longer under his scope.
“So you've got like an acquisition pod, you've got an expansion pod, you've got a retention pod, you've got a value realization pod”
Listen to the episode Sales team, hiring & comp Link to this
A modern revenue leader needs P&L fluency, hands-on AI agency and end-to-end ownership of revenue and the system underneath it. Listen
He says leaders don't need to be systems engineers but must understand how AI works and build some things themselves. He criticizes CROs who own only sales and marketing. He thinks the industry is at an inflection point where this becomes more critical as AI agents run more of the work.
“CRO should own the whole end to end revenue and the system underneath it”
Moss's personal stack has 121 domain-expert agents and 57 skill files, with agents defined as domain experts and skills as repeatable processes any agent can use. Listen
His agents are grouped into teams: engineering, product, sales, marketing, customer success, RevOps, enablement, a GTM advisor panel (which includes a Kyle Norton persona) and a personal board of directors. A skill is a repeatable workflow, such as how to pull and analyze Google Analytics, and is kept out of individual agents so several agents can share it. A smart routing agent picks which agents to use based on his request.
“a skill file is kind of a repeatable process”
Moss runs 52 cron jobs in his personal agent system, at least four break almost every day, and he spends his first 15 minutes each morning fixing them. Listen
His homegrown system combines his own code with open-source pieces, including memory components, which he calls a soup that brings its own challenges. He set up a watchdog to report what breaks overnight. He says he'd move more of it to Grokbot if it solves the cron reliability problem; Norton says his Grokbot crons have fired correctly every time.
“Now I have 52 cron jobs and at least four of them broke. Break every day almost.”
Moss had his CTO and systems-architect agents review OpenClaw and recommend what to adopt, instead of porting his whole system onto it. Listen
His system predates OpenClaw. Rather than migrating, he asked his agents whether to port everything or build selected pieces into his own system, and they recommended specific things to adopt. Norton described a similar habit of asking his agent whether a new GitHub repo is worth adding, and often being told it overlaps with existing capability.
“I asked my CTO agent and my systems architect agent agent to review all of openclaw”
Moss built continuous improvement and decision tracking into his personal agent system before applying the same ideas at Experity. Listen
He prototyped on his personal system how it could keep improving through his daily work, then added tracing to record what decisions were made, where and when. These features came from frustrations in use, such as not being able to recall decisions from three weeks earlier or having to repeat himself. His personal brain holds thousands of structured markdown docs, stored in GitHub with the runtime on a Mac Mini.
“why can't I know what decisions were made three weeks ago? Or why did I have to repeat myself multiple times?”
Kyle Norton keeps separate agent channels per job, such as podcast production versus podcast outreach, because one shared thread got confusing. Listen
Moss routes everything through one Telegram channel with a smart routing agent. He said he probably should have used multiple threads, because deep work across many agents in one thread gets confusing, and Grokbot's separate channels were the first thing that drew him to it.
“I separated podcast production from podcast outreach because having them having it go back and forth in the same channel, I found personally confusing”
Kyle Norton writes every skill file back to a GitHub repo so the same skills work across agent tools, which makes moving from OpenClaw to Grokbot easier. Listen
Norton is using a Grokbot setup agent to walk him through porting his OpenClaw instance. Most of it lives in the GitHub skill files, while items such as crons built inside OpenClaw's virtual machine have to be rebuilt.
“everything I build. Build is always instructed right Back to the GitHub repo with these skill files. So I can. I can use multiple experiences with the same tools and skills.”
Kyle Norton gives his personal agent its own email address and a dedicated 1Password vault so it can create and manage its own logins. Listen
His digital chief of staff, Kai, has its own email, creates its own accounts, and stores credentials in a Grokbot vault in 1Password. Norton says this avoids handing over all his own passwords, and he praises 1Password's thinking on agent password management.
“Kai has its own email so it can create its own logins and it could have passwords for those logins.”
Kyle Norton gives his agent a Robinhood virtual card with a $500 monthly limit so it can make purchases without access to his main card. Listen
In Robinhood's banking app, you can create virtual cards meant for agents and either approve every purchase or set a limit. Norton turned off per-purchase approvals and kept the monthly cap. He has only used it successfully once so far, to reorder a specific pair of socks.
“mine's on a 500 limit, so, like, if it goes haywire one month”