The expectation is to move quickly, with enough judgment to avoid spending the quarter on something nobody uses.

When I talk to teams about adopting AI, I usually look at how the leader is learning, whether people have time to experiment, and who will help useful ideas become part of everyday work. The tool budget is often easier to agree on than what comes off the calendar or who takes responsibility after the first demo. Those decisions tell me more about how ready the team is to move forward.

What you will learn

• How to build your own AI fluency so you can give the team direction and assess where it needs support.

• What your team needs to adopt AI: paid tools, time to experiment, practical training, and permission to learn through failed attempts.

• How to turn individual experiments into shared capabilities through hackathons, onboarding, and a regular GTM review cadence.

• How to assess your team’s AI readiness, identify the gap holding adoption back, and decide which initiatives deserve further investment.

Where is your AI adoption getting stuck?

Before deciding what to buy or build next, I would check four things: leadership fluency, team capacity, execution, and commercial impact. Use the questions below with marketing, sales, and RevOps, and mark each area as missing, inconsistent, or established. Ask for a recent example behind each answer; “we have access to ChatGPT” leaves quite a lot unanswered.

• Leadership fluency
  Question: Can we judge what AI can do, where it needs review, and which GTM problem deserves attention?
  Next: Build practical fluency and agree on one priority.

• Team capacity
  Question: Do people have the tools, time, training, and technical support to apply AI in their roles?
  Next: Fix the specific access, workload, or skills gap.

• Execution
  Question: Can colleagues use a promising workflow, with clear data boundaries and someone responsible for maintaining it?
  Next: Assign ownership and test whether someone else can use it.

• Commercial impact
  Question: Can we compare results with a baseline, including review effort and ongoing costs?
  Next: Define the KPI and review date before investing further.

Keep the four answers separate. Strong personal usage can coexist with weak team adoption, and a good prototype can still lack an owner. Start with the gap preventing progress on your chosen GTM bottleneck, give it an owner, and agree on what would demonstrate improvement. That gives you a concrete next decision without pretending the whole team fits neatly into one maturity score.

Waiting makes it harder to know where to start

AI is already being used in account research, customer analysis, campaign production, and recurring GTM work. My advice is to start learning through practical use while you develop the strategy. Spending six months planning before testing anything leaves the budget, priorities, and hiring decisions resting on assumptions you could already be examining. By then, the strategy may be beautifully presented and overdue for an update.

Keep the first experiment manageable enough to learn from before expanding the scope:

• Choose one problem. Pick recurring GTM work where you can observe whether the approach helps.

• Give someone ownership. Make clear who will test it and record what happens.

• Review before expanding. Use the findings about your data, team skills, and implementation effort to shape the strategy.

Your team is watching how you use AI

I would treat your own AI fluency as part of the leadership job. If every proposal requires someone else to explain what is possible, you will struggle to judge the investment or give the team direction. Make time for practical training, videos, podcasts, and conversations with experienced operators, then use the tools yourself. Choose a starting point that matches your current fluency:

• Google AI Essentials offers a beginner foundation in everyday AI use, prompting, and responsible use, with hands-on workplace activities.

• Anthropic’s AI Fluency: Framework & Foundations covers delegating work, giving instructions, evaluating outputs, and responsible use.

• OpenAI Academy’s AI Leadership course covers business priorities, ownership, governance, and adoption. Look for AI Leadership under Lead AI Adoption.

Apply the learning to a GTM problem your team actually faces, then share what you are trying, what needed correction, and what proved less useful than expected. Becoming AI-native involves knowing enough about the capabilities and limitations to judge a proposal, ask useful questions, and recognize where human review belongs. Your own participation also makes it easier to set reasonable expectations for a team that is learning alongside you. When I help teams work through these decisions, the priorities, workload, and ownership shape what is worth implementing.

Give your team the time, tools, and confidence to experiment

If you expect your team to adopt AI, pay for the tools they need and make learning part of their workload. Adding subscriptions while leaving everyone’s workload untouched is rather like handing out ingredients and expecting dinner to arrive. The practical decisions sit with you:

• Fund the experiment. Arrange paid tools, credits, and access to relevant company information within an agreed budget.

• Protect the time. Decide what moves off the calendar so people can learn and test their ideas.

• Set clear boundaries. Agree on which data people can use, which actions need approval, and who can help when they get stuck.

• Make disappointing results safe to share. Finding inaccurate outputs or an approach that costs too much to maintain should inform the next decision, rather than count against the person who tested it.

You need those findings to make investment decisions, and people need to know they can bring them to you.

Help good AI ideas spread across the team

Give people a way to learn from each other’s experiments, especially across marketing, sales, and RevOps. I would look at whether a useful idea can travel beyond the person who built it: can a colleague try it, understand its limits, and get help when something breaks? A few practical ways to make that happen:

• Run focused hackathons. Bring people together around one GTM problem, with protected time and enough tool credits to build and test an approach.

• Hold short show-and-tell sessions. Ask people to share what they built, what went wrong, and where a colleague could use it.

• Run peer-led practice sessions. Ask colleagues with more experience to teach the tools and approaches they already use. Someone working in an environment that coordinates multiple agents could walk the team through how they divide tasks, review results, and keep control of the work, then help others try it themselves.

• Keep a shared workflow library. Record useful builds, the problem each solves, approved data boundaries, and who to contact for help.

• Pair builders with colleagues. Have someone outside the original experiment try the workflow; their questions will reveal what needs explaining or fixing.

• Offer technical office hours. Give people access to a technical marketer, RevOps specialist, GTM engineer, or external advisor who can help promising ideas move forward.

• Review adoption and spending together. A simple dashboard can show which builds enter regular use and where people need support. Ranking colleagues by credit consumption gives them a rather expensive incentive.

Choose the formats your team can sustain, and make someone responsible for taking useful experiments into everyday work. I would judge these activities by what colleagues adopt afterward and what improves as a result. A popular prototype still needs someone willing to maintain it.

Share

Closing the AI skills gap in your GTM team

New hires and established colleagues need a shared foundation, with opportunities to update it as AI capabilities change. I would make practical training a recurring part of how the team works, with clear expectations about what people should be able to do afterward:

• Include AI in onboarding. Give newcomers the same foundation as the rest of the team, including approved tools, data boundaries, and workflows already in use.

• Set a regular training cadence. Schedule hands-on sessions at a pace you can sustain, such as monthly, led by an internal expert or external advisor who understands your GTM priorities.

• Build something relevant to the role. Have participants create or improve an agent or workflow for their own work, with time to test it and get feedback.

• Share the learning. Let people explain their approach, compare results, and discuss what needed correction so colleagues can learn from the same exercise.

• Measure what happens afterward. Track completed builds, then check which enter regular use and whether people can explain and maintain them. I would use those as training KPIs; attendance tells you very little about whether someone can apply the learning without help.

From AI pilots to everyday GTM execution

Bring AI progress into the existing weekly GTM meeting, with a few recurring questions that lead to decisions:

• What are we learning? Review what is being tested, what has entered regular use, and which decisions are holding it up.

• Who will make it part of the process? Agree on an owner, where the workflow belongs, and what colleagues need to adopt it.

• What can we retire? Decide which old tasks or process steps can disappear so people have room for the new approach without maintaining both versions indefinitely.

Reinforce that routine through regular feedback and recognition. Give credit to people who improve a process, help colleagues adopt it, or provide evidence that an experiment should stop. Set expectations around examining how AI could improve work in their roles, with room for justified decisions to keep a task human. Rewarding useful judgment makes the standard clearer than rewarding the volume of AI activity.

Keep your GTM thinking ahead of your current playbook

As AI adoption grows, agree with marketing, sales, and RevOps on the commercial result that would justify further investment. I would keep reviewing four things as the tools and your team’s capabilities develop:

• The result you are measuring. Choose a primary KPI, such as pipeline conversion, sales velocity, or production cost, and establish the baseline. Keep it close to the work you are changing, allowing time for commercial outcomes to emerge.

• The full cost of improvement. Include subscriptions, reviewing outputs, correcting mistakes, and maintenance in your view of AI ROI; faster production can still carry substantial costs.

• The infrastructure behind useful work. Connect the data, company knowledge, and systems needed to repeat proven approaches reliably, with an owner who can review performance and adapt the workflow.

• What other operators are learning. Compare what they have put into regular use, what it costs to maintain, and what they have stopped. Those conversations are more useful for your next decision than another impressive demonstration.

Three things to do this week

1. Choose one commercial bottleneck. Bring marketing, sales, and RevOps together to identify a recurring friction point, agree on a primary KPI, and record the current baseline. Assign an owner to a bounded experiment and set a date to review the result.

2. Check whether the team has what it needs. Confirm access to paid tools and credits, time to learn, and someone who can provide technical support. Schedule a practical training session that includes both new hires and established colleagues.

3. Add AI progress to the weekly GTM meeting. Review what people have tried, what they are using, and where they need help. End with a decision about what to continue, adjust, or stop, and recognize contributions that help colleagues improve their work.

Operator note

Before giving an experiment more budget, I would ask three questions. An unanswered one gives you a specific gap to resolve before scaling and a clearer brief for whoever helps you resolve it:

• Value: Has it improved the work?

• Adoption: Can someone else use it?

• Ownership: Who will keep it working?

If the readiness check leaves you unsure which gap to address first, my AI GTM Maturity Snapshot is a useful next step. Answer 10 focused questions about your GTM setup, and I review the pattern behind the friction to give you a practical view of your current stage, the constraint holding adoption back, and one next move. It is designed for leaders in companies with 200+ people, where adoption has to work across teams.

Get AI GTM Snapshot

Book a call

Connect with me on LinkedIn

The question matters because the conventional answer - adding more tools around the CRM - is proving too slow. Customer context still sits across calls, product usage, email, and operator judgment, while critical decisions wait for someone to turn it into a clear next action.

The most interesting companies are attacking that gap first.

They start with high-friction commercial moments: which account deserves attention, how inbound should be qualified, why a deal has gone quiet, or how the next customer interaction should be prepared. Instead of waiting for a complete GTM organisation, they build a loop that connects the signal, a decision, an action, and what happens next.

This article looks at that shift from three angles: where the AI layer sits alongside the existing stack, why early GTM ownership stays close to the customer workflow, and how established teams can begin applying the same logic.

The AI Layer Sits on Top of the Existing Stack

The technical pattern is real. AI-native companies repeatedly describe an execution layer built from models, agents, context, workflows, integrations, evaluation, and deployment.

But when commercial systems appear, they are usually familiar: HubSpot, Salesforce, Slack, LinkedIn, email, Outreach, Gong, Segment, PostHog, Calendly, Shopify, spreadsheets, and vertical operating systems.

The old commercial plumbing has not disappeared. It is becoming the environment around which AI-native teams build.

The pattern looks different by company, but the underlying move is consistent:

About these examples: The companies referenced here are independent market examples. The observations reflect their public positioning and product materials; they do not imply endorsement, a commercial relationship, or access to non-public systems.

Which recurring commercial decision can now move from trusted context to action with less manual coordination?

To go deeper on the operating model behind this shift, read AI GTM in 2026: What High-Performing Teams Do Differently. It explains why advantage comes from connecting signals, context, decisioning, execution, and learning rather than collecting isolated AI tools.

The First GTM Motion Has One Owner

Before a conventional GTM organisation exists, the commercial work is still too close to the product and the customer workflow to be separated cleanly into sales, RevOps, success, and implementation.

The transferable pattern is not founder heroics. It is a single accountable owner for the loop. In an early company, that person is often a founder. In an established team, it could be a revenue leader, customer leader, GTM engineer, deployment lead, or RevOps owner. What matters is that someone can connect the product, customer context, commercial decision, and outcome.

For the ownership question, 2026 State of GTM Engineering: Salary, Skills, Tools & Hiring Trends maps the roles and capabilities emerging around this work. It is especially useful if you are deciding whether the operating layer belongs to RevOps, GTM Engineering, or a new AI GTM function.

This is especially visible in founder narratives. Nex founders repeatedly frame the market problem through CRM cleanup, data quality, routing, re-engagement, and outbound execution. Bizmark’s founder story is grounded in the operational work of making, moving, and selling physical goods. Pango’s is grounded in the cost and complexity of post-purchase operations. These are not feature descriptions. They are explanations of where customer work breaks and what changes when a system can act.

I’m launching Modern GTM in Action, a new LinkedIn Live series with a deliberately simple format:

30 minutes.
One practitioner showing a real GTM workflow live.
And your questions as we go.

For the launch, I’ll be joined by Mathew Joseph, GTM Engineer at Cerebrium.

We’ll talk about AI-powered market research and the verification layers needed to make it trustworthy.

Sign up

The early GTM motion is not a department. It is an owned operating loop:

1. Find a painful, specific workflow.

2. Prove the product can change an outcome inside it.

3. Stay close enough to implementation to see where it breaks.

4. Turn that learning into the next product and commercial decision.

This is why a generic “hire sales earlier” interpretation misses the point. The first commercial hires in AI-native companies may not resemble a traditional SDR or demand-generation hire. They are more likely to sit at the junction of customer workflow, product, implementation, systems, and revenue.

Names for that emerging work already exist: AI GTM Engineer, customer engineer, deployment engineer, forward-deployed engineer, solutions engineer, RevOps engineer, workflow architect, and revenue systems architect.

The titles will vary. The work is converging.

Build One Controlled Commercial Loop

Established teams do not need to rebuild their stack or let AI act without control. The practical starting point is one commercial decision that is currently slow, inconsistent, or overly dependent on operator judgment. Keep the CRM and the systems around it. Improve the path from context to action inside them.

The useful test is whether a capability changes a commercial decision. Can it change which account receives attention, how a lead is qualified, how a deal is routed, how outreach is prepared, or how a renewal risk is surfaced? If it cannot, it may be a useful AI feature, but it is not yet an AI-enabled GTM operating model.

Start with one controlled loop:

1. Choose one commercial decision that is currently unreliable.Examples: account prioritization, lead routing, renewal-risk review, outbound preparation, customer escalation, or pipeline hygiene.

2. Name the context required to make that decision well.This is usually spread across the CRM, product usage, conversations, support data, a spreadsheet, and individual operator knowledge.

3. Assign an owner for the action, not just the tool.Someone needs to own the handoff from signal to decision to execution, including the exceptions.

4. Build one repeatable workflow before expanding.Keep a human approval point where the action has commercial or customer consequences. A useful workflow can be audited, improved, and measured. A broad automation initiative usually cannot.

5. Measure the commercial consequence.Not prompts run or hours saved alone. Measure whether the quality, speed, consistency, or outcome of the decision changed.

The system of record still matters. So do email, Slack, analytics, vertical software, and the data model beneath them. The shift is in how work moves between those systems. This is a more disciplined way to adopt AI because it starts with the commercial system you already run. It does not ask you to replace everything at once.

To see the model translated into practical workflows, AI Agents for RevOps: 7 GTM Plays That Turn Existing Signals Into Warm Pipeline walks through seven concrete plays. Each one connects a usable signal to an accountable owner, human review, a commercial action, and CRM writeback.

What One Controlled Loop Looks Like

Example: re-engaging deals that have gone quiet

Decision: Which stalled opportunities deserve a re-engagement action now?

Context: CRM stage, last interaction, buying committee, product usage, and account changes.

Action: AI prepares the recommended next step and a draft message.

Control: The pipeline owner approves consequential outreach before it is sent.

Measure: Time to action, reactivation rate, and pipeline recovered.

Your Next Move

Before adding another AI tool, ask three questions:

1. Which commercial decision is least reliable today?

2. Is the context needed to make that decision available and trusted?

3. Who owns the action and the outcome once the system makes a recommendation?

The companies that pull ahead will not be those with the longest AI tool list. They will be the ones that make a few important commercial decisions faster, clearer, and more accountable.

Get AI GTM Snapshot

Book a call

Connect with me on LinkedIn

Everyone is talking about AI agents, AI SDRs, autonomous workflows, and agentic GTM.

But after spending the last couple of months studying how B2B companies are modernizing their go-to-market systems, the clearest pattern is more practical: AI GTM readiness is not about whether AI appears somewhere in the workflow. It is about whether the GTM stack can use better context to make better commercial decisions and turn those decisions into repeatable action.

That is why I built The AI GTM Stack Report 2026.

The report looks at how AI is entering internal GTM systems: sales, marketing, RevOps, customer success, growth, data, GTM engineering, workflow automation, revenue intelligence, and the commercial operating model around them. It is not a vendor ranking. It is not a claim that every visible tool is being used deeply. It is a market benchmark for leaders trying to understand where AI-enabled GTM is actually taking shape.

This is also the work I do with established companies: helping teams understand where AI should enter the GTM system, what needs to be fixed first, and how to move from scattered pilots to a practical AI-enabled operating model.

In other words, it is for the teams having a very specific conversation right now:

Are we behind on AI in GTM, or are we missing the operating system that would make AI useful?

What You Will Learn

In this article, I will cover:

• what AI GTM readiness means for established revenue teams;

• why the AI GTM stack is forming around existing commercial systems, not replacing them wholesale;

• where GTM orchestration, decision intelligence, RevOps AI, agentic workflows, and controlled automation are starting to matter;

• how the report separates tool visibility from operating-model maturity;

• why company size changes the complexity of AI GTM modernization;

• how to diagnose whether the next constraint sits in foundation, context, activation, or control.

Table Of Contents

1. Why AI GTM Readiness Needs A Market Benchmark

2. What The AI GTM Stack Report Studied

3. The Main Pattern: GTM Stacks Are Becoming Systems Of Intelligence

4. The Four Layers Of A Modern AI GTM Stack

5. How AI GTM Modernization Changes By Company Size

6. What This Means For Established Revenue Teams

7. Download The Complete AI GTM Stack Report 2026

8. Applying The Framework To Your GTM Stack

9. A Question For Your GTM Operating Model

1. Why AI GTM Readiness Needs A Market Benchmark

AI GTM readiness has become a commercial systems question.

Not just a tooling question. Not just an experimentation question. Not just whether somebody in sales is using ChatGPT to write a better email before lunch.

For established B2B companies, AI has to work inside a revenue system that already has dependencies: CRM data, lifecycle definitions, routing logic, enrichment, sales engagement, marketing automation, customer workflows, forecasting, governance, and ownership across several teams.

That makes the market harder to read.

One company may have a long AI vendor list but still run most GTM decisions manually. Another may use fewer tools but connect account research, routing, and follow-up into one reliable commercial workflow. From the outside, those two companies can look similar. Operationally, they are very different.

That distinction matters because the next stage of AI go-to-market strategy will not be won by activity volume alone. It will be shaped by whether teams can connect intelligence to a decision, a workflow, an owner, and a measurable commercial outcome.

The useful question is not whether AI is present somewhere in GTM. It is whether the commercial system can turn better context into better action.

This is why I wanted a market benchmark.

The report gives revenue leaders a way to compare their own starting point with what is visible across the market. It shows which parts of the GTM stack remain durable, which AI-enabled layers are forming around them, and where the operating model starts to matter more than the tool list.

When I work with companies on GTM stack modernization, this is usually where the conversation becomes useful: not “which AI tool is best,” but which commercial decision, handoff, workflow, or control point is ready to improve.

For mature teams, that benchmark is useful because the question is rarely “Should we use AI?” anymore.

The question is usually:

Where should AI enter next without making the GTM system harder to run?

2. What The AI GTM Stack Report Studied

The AI GTM Stack Report studies how AI is entering internal go-to-market systems.

The emphasis is important: internal GTM systems, not customer-facing AI product features.

A company can sell an AI product and still operate a conventional sales and marketing system. Another company can sell a non-AI product and have a sophisticated AI-enabled GTM motion behind the scenes. The report is interested in the second question: how commercial work is actually supported by tools, data, orchestration, workflows, ownership, and repeatable processes.

Methodology note:

I analyzed a large cohort of B2B companies across North America and Europe, focusing on internal GTM signals: technology visibility, stack layers, company size, workflow patterns, and evidence of AI-enabled commercial operations.

The report studies how AI is entering sales, marketing, RevOps, customer success, growth, and GTM engineering work. It does not treat customer-facing product AI features as proof of internal AI GTM maturity.

The report uses public and visible market signals, so it is careful about what the evidence can and cannot prove.

Tool visibility is a signal. It can show that a category or capability is present around the GTM stack. It does not prove contract value, usage depth, workflow quality, or commercial impact.

That is why the report separates several questions that often get collapsed into one conversation:

• Does the company have a durable GTM foundation?

• Are new data, research, orchestration, or model layers visible around it?

• Is there evidence that AI supports one contained use case?

• Is there evidence that AI has become part of a repeatable workflow?

• Does the operating model show ownership, measurement, governance, and control?

This distinction keeps the report vendor-neutral and more useful for operators.

Buying a tool is a procurement event. Changing how a commercial decision gets made is an operating change. The report is about the second one.

3. The Main Pattern: GTM Stacks Are Becoming Systems Of Intelligence

The strongest pattern in the report is that AI GTM is mostly an augmentation and integration story.

The commercial foundation remains central. CRM, engagement, enrichment, revenue intelligence, customer workflows, and data infrastructure are still doing real work. AI-enabled layers are forming around that foundation rather than replacing it wholesale.

This is where a lot of public AI GTM conversation becomes too dramatic for its own good.

The market is not simply moving from “old GTM stack” to “new AI stack.” It is moving toward a more intelligent commercial system: better context, better prioritization, better routing, better workflow activation, better follow-up, and more explicit control over where automation should and should not scale.

The companies that look more mature are not just “using AI.”

They are connecting AI to the parts of GTM where better context can change what the team does next.

That is the practical shift behind phrases like AI revenue operations, GTM orchestration, decision intelligence, agentic workflows, and controlled automation. They matter only when they connect to the commercial system. Otherwise, they become impressive vocabulary parked next to the same old handoffs.

The direction of travel is clear: GTM stacks are becoming systems of intelligence.

The unresolved question is how much of that intelligence changes the way revenue work is actually done.

4. The Four Layers Of A Modern AI GTM Stack

To make the report practical, I use a four-layer framework:

1. Foundation

2. Context

3. Activation

4. Control

The framework is intentionally simple because the real GTM stack is usually not.

It helps leaders avoid a common mistake: starting the AI conversation with “Which tool should we buy?” before asking where the current system is constrained.

Foundation: can the commercial system be trusted?

The foundation is the commercial system teams already depend on: CRM, account and contact records, lifecycle stages, ownership rules, pipeline definitions, routing logic, permissions, and the basic operating discipline that keeps GTM work coherent.

AI does not remove the need for this foundation. In many companies, it makes the foundation more visible.

If CRM data is unreliable, if lifecycle stages mean different things across teams, or if handoffs are negotiated informally in Slack, AI will not magically turn that into a clean operating model. It may simply make the mess faster and more confident, which is a very modern way to create work for next quarter.

The first AI GTM readiness question is therefore not “Do we have AI?” It is:

Can the system be trusted enough for AI-assisted workflows to use it?

Context: does the team have useful commercial intelligence?

Context is the intelligence layer around the foundation.

This includes account research, enrichment, intent and fit signals, customer health context, conversation intelligence, market signals, buyer context, and the information a team needs before deciding what to do next.

Most companies already have more data than they can use well. The modernization opportunity is not only to collect more information. It is to make the right context available at the moment of commercial action.

That is where AI can be useful: turning scattered inputs into a better view of an account, customer, buying group, opportunity, or risk.

https://www.linkedin.com/in/murei/

But context is still only half the story.

A better insight that stays in a dashboard is not yet GTM transformation. It is a nicer waiting room.

Activation: can better insight become repeatable action?

Activation is where AI GTM starts to become operational.

This layer includes workflow automation, routing, sequencing, playbooks, handoffs, next-best-action logic, sales and marketing execution, customer success workflows, and agentic workflows where the system can safely prepare or trigger action.

The important word is repeatable.

An AI pilot can be useful for one person or one team. A repeatable workflow has clearer inputs, ownership, review points, handoffs, and success measures. It does not depend on one unusually motivated operator holding the process together with browser tabs and optimism.

This is where the AI GTM stack starts to matter as an operating system rather than a collection of tools.

Control: can the system scale without losing trust?

Control is the layer that makes AI-enabled GTM workable at scale.

It includes governance, auditability, permissions, human review, data access, measurement, escalation rules, AI policy, and the operating cadence for improving the system over time.

Control is sometimes treated as the boring part of AI adoption. In established companies, it is often the part that decides whether the work can expand beyond a pilot.

Once AI affects account prioritization, pipeline movement, customer communication, or sales execution, the company needs to know who owns the workflow, what the system is allowed to do, where human judgment is required, and how performance will be measured.

That is not bureaucracy. That is how the organization keeps trust while increasing automation.

5. How AI GTM Modernization Changes By Company Size

Company size does not change the direction of AI GTM modernization. It changes the coordination cost.

Smaller teams can often add research, automation, and agentic workflows faster because the system is lighter. There are fewer approval layers, fewer data boundaries, fewer regional exceptions, and fewer teams required to agree on a handoff.

That speed is useful. It also creates its own risk: a compact workflow can become fragile if it depends too much on one person, one spreadsheet, or one tool configuration nobody else understands.

Larger teams usually have more durable systems. They also have more complexity.

The CRM is more embedded. Data ownership is more distributed. Permissions matter more. Revenue workflows cross regions, segments, business units, and customer motions. A change in routing or account prioritization can affect sales, marketing, customer success, finance, operations, and leadership reporting

This is why established companies should avoid copying AI GTM playbooks from much smaller teams without translating the operating model.

The idea may be right. The implementation path will be different.

A smaller company may be able to connect account research, enrichment, and outbound activation quickly around a lightweight CRM. An enterprise team may need to solve data quality, ownership, consent, governance, CRM handoffs, regional process differences, and measurement before the same workflow can scale responsibly.

The direction is similar across company sizes: AI is forming around the GTM stack.

The work required to make it reliable is not.

6. What This Means For Established Revenue Teams

For established revenue teams, the report points to a practical conclusion: AI GTM maturity should be evaluated through system readiness, not only visible tool adoption.

That does not mean tools are unimportant.

Tools matter when they improve a commercial decision, connect to a repeatable workflow, clarify ownership, and help the team measure what happened next. They matter less when they create another disconnected surface area for GTM work to happen in parallel.

The better diagnostic is to ask where the current constraint sits:

• Is the foundation trusted enough for AI-assisted workflows?

• Does the team have useful context at the moment of action?

• Can insights trigger repeatable workflows, or do they stay trapped in dashboards?

• Who owns the AI-enabled GTM operating model?

• Where do we need control, governance, or human review before scaling automation?

• 

  For established companies, the AI GTM opportunity is not to add another disconnected layer of activity. It is to modernize the commercial system so better intelligence changes the next best action.

  That usually starts with one constraint, not a grand transformation deck.

  Fix the data and process behind one important commercial decision. Connect one useful pilot back into the GTM system. Make one workflow repeatable across inputs, owners, review points, and success measures. Clarify governance before automation expands into customer-facing or pipeline-sensitive work.

  The goal is not to slow AI adoption down.

  The goal is to make the adoption more useful.

  This is the advisory work behind Prompt to Pipeline: helping established B2B teams map their GTM stack, identify where AI can improve revenue operations, and build a modernization path that connects data, workflows, ownership, and commercial outcomes.

Want to see how this transition map applies to your own team? The AI GTM Maturity Snapshot is a short diagnostic for GTM, RevOps, Sales, Marketing, Customer Success, Growth, and AI transformation leaders. Ten focused questions produce a human-reviewed maturity stage, the bottleneck most likely slowing adoption, and one practical next move, rather than another generic score.

Take the GTM maturity snapshot

Read more

The capability is increasingly available, but the operating environment is where the trouble starts.

The company asking for autonomous lead routing may still have three lead-source definitions, duplicate account records, rep-owned spreadsheet logic, stale lifecycle stages, and a Slack channel where exceptions go to retire.

An agent can move through that kitchen faster than the team, but speed is not especially useful when the ingredients are mislabeled and nobody agrees on the recipe.

That is why customer conversations are moving from what agents can do to what they can safely do inside a live revenue system: teams are asking which data an agent should trust, which actions it can take without approval, when a human should intervene, and how to measure whether the decision improved a commercial outcome.

Salesforce frames the shift through context, work, insight, agency, and engagement; OpenAI emphasizes tracing, guardrails, handoffs, tools, and workflow state. The vocabulary varies, but the operating questions are remarkably similar.

I call the layer that answers those questions The Agentic GTM Infrastructure Stack: it connects trusted data, commercial context, permissions, workflow logic, human review, observability, and revenue feedback. This article explains how that infrastructure works, where it tends to break, and how founders and GTM leaders can apply the framework to a real revenue workflow before adding another agent to the stack.

It also connects to the themes behind From AI Adoption to Revenue Architecture, which looks at context, signals, routing, actions, and learning as one commercial system, and MCP vs API vs CLI, which separates the interfaces, execution layers, and controls an agentic workflow needs. This article focuses on the infrastructure underneath both questions.

The teams that get this right will not simply automate more GTM tasks. They will build revenue systems where signals become decisions, decisions become governed actions, and the outcomes improve the next run.

What You Will Learn

This article shows what needs to exist before AI agents can operate across GTM workflows with any reasonable level of trust.

• Why the agentic GTM conversation is shifting from tools and prompts to infrastructure.

• The Agentic GTM Infrastructure Stack: seven layers behind useful GTM agents, from source-of-truth data to revenue feedback.

• How to decide what an agent may read, recommend, write, send, and escalate.

• Where agentic workflows usually fail first: CRM writeback, routing logic, field ownership, approval paths, and invisible decisions.

• A practical audit for one GTM workflow before your team adds another agent to the stack.

What everyone is already saying about agentic GTM

The AI-in-GTM conversation has moved from assistants that draft, summarize, and research to agents that can act inside revenue workflows: enrich leads, route accounts, update CRM, inspect pipeline, and trigger follow-up.

Most market narratives now converge on three ideas: humans will orchestrate while agents execute; data and workflow quality will determine decision quality; and autonomy will require clear permissions, approval paths, and auditability.

That direction is useful, but it leaves the practical question unanswered: what must exist underneath the agent before a company can trust it inside a live revenue system?

Across platforms, the terminology varies, but the operating requirements are similar: trusted context, connected workflows, controlled access, human review, and observable outcomes.

Strip away the product vocabulary, and the pattern is clear: agentic GTM needs infrastructure.

The missing layer is infrastructure

Most GTM systems were built for humans who can work around ambiguity: a rep knows that lead source is unreliable and checks the campaign notes. RevOps knows which deprecated Salesforce field still feeds the board deck. Marketing Ops knows where the lifecycle workflow quietly fails.

Agents, though, do not inherit that street knowledge and it has to be translated into usable context, rules, permissions, and feedback.

Prompt quality cannot repair contradictory fields, unclear ownership, missing account history, invisible attribution logic, or a workflow with no rollback path. A confident answer becomes a liability when it triggers a CRM update, changes a forecast note, or reaches a customer.

The operating layer underneath agentic GTM must let an agent answer five questions before it acts:

1. What source of truth should I trust?

2. What context changes the decision?

3. What am I allowed to do?

4. When do I need a human?

5. How will the business know whether this worked?

Those questions are the first pass through The Agentic GTM Infrastructure Stack.

The Agentic GTM Infrastructure Stack

The Agentic GTM Infrastructure Stack is the set of operating layers that let agents work across revenue systems without creating more mess than they remove. It sits beneath Adaptive GTM™ as the infrastructure diagnostic: before the system can adapt, it has to know what to trust, what to access, who approves the action, and how the outcome is measured. Human-in-the-Loop GTM™ becomes one critical layer inside it: the judgment and approval boundary.

1. Source-of-truth data

Every agentic GTM workflow begins with a trust decision.

If Salesforce says an account is mid-market, HubSpot says enterprise, the warehouse has a different employee count, and the rep’s notes say the account is a strategic logo, which record should the agent use?

Humans often work around this silently. Agents need the hierarchy made explicit.

This layer defines field ownership, trusted systems, update frequency, matching logic, deduplication rules, and the difference between “known,” “inferred,” and “stale.” It also defines which records are safe for agents to touch and which should remain read-only.

Without this layer, agents do not personalize. They improvise with whatever fragment of truth they happen to retrieve.

For a founder or CRO, the practical test is simple: pick one ICP-fit account and ask where the team would find firmographics, engagement, opportunity history, product usage, champion movement, open support issues, and campaign influence. If those answers live in seven systems with no priority order, the agent has the same problem, only faster.

2. Account and customer context

Data is the raw material. Context is the commercial meaning.

An agent deciding whether to route, score, sequence, or escalate an account needs more than a company name and email address. It needs to understand the account’s segment, current business motion, prior relationship history, open opportunities, product usage, support risk, buying committee, competitor mentions, and why the account matters now.

This is where many GTM agent experiments flatten into generic automation. They can enrich a record, but they cannot explain why the moment deserves action. They can draft an email, but they do not know which business problem should shape the message. They can summarize a call, but they cannot connect it to the campaign, the product signal, and the AE’s next best move.

The infrastructure question is not “Do we have data?” It is “Can the system assemble the context a good operator would use before acting?”

This is why data activation matters. Warehouse-to-GTM workflows, such as the model Hightouch describes with sources, models, schema, destinations, and syncs, are not just plumbing for marketers. They are a way to move trusted customer and business data into the places where campaigns, sales motions, and account decisions happen.

3. Tool access and permissions

Once agents can act, tool access becomes a revenue-control problem.

A research assistant with read-only access to public web pages is one thing. An agent that can update CRM fields, trigger sequences, modify lead ownership, create tasks, enrich contacts, post Slack alerts, or influence forecast notes is another.

This layer defines the agent’s identity, scopes, credentials, and boundaries. It answers practical questions:

• Can the agent read all accounts or only accounts in a territory?

• Can it update fields or only recommend updates?

• Can it create a task for a rep?

• Can it send an external email?

• Can it trigger a sequence?

• Can it overwrite a field owned by RevOps?

• Can it call enrichment vendors that create usage-based cost?

The MCP authorization specification is useful here because it makes the security point concrete: tool access is not just a connection problem. Tokens need to be issued for the right audience, validated by the receiving server, and restricted so credentials are not casually passed through systems where they do not belong.

For GTM leaders, the translation is blunt: do not give an agent admin-shaped access because the demo looked impressive. Treat agents as non-human operators with named jobs, scoped permissions, and a visible owner.

4. Workflow orchestration

An agent should not have to invent the business process every time it runs.

Many GTM workflows are partly deterministic and partly judgment-based. Lead routing may follow a defined territory model, but the agent may need to interpret messy job titles or infer account fit from recent signals. Renewal risk may have fixed thresholds, but the agent may need to summarize why the risk exists. Campaign follow-up may use a standard sequence, but the first human touch may need context and timing judgment.

That means orchestration matters as much as reasoning.

Workato's enterprise AI framing is a useful pattern: the best AI workflow is often only partly AI. A deterministic workflow can monitor for an event, gather context, call an agent for a judgment task, route the result through approval logic, and then execute known actions through governed systems. The agent contributes where uncertainty exists. The workflow handles everything that should be reliable.

This is especially important in GTM because many actions have downstream consequences. One bad field update can affect segmentation. One bad lifecycle-stage change can affect reporting. One bad sequence trigger can affect deliverability and account trust. One bad routing decision can affect rep behavior and response speed.

Agentic GTM should not mean asking the model to manage every step. It should mean designing the workflow so the model only owns the decisions where judgment is actually useful.

5. Human review and escalation

Human-in-the-loop design is not a compliance ornament. It is how GTM teams protect judgment, relationships, and revenue trust.

The review model should vary by action type.

Low-risk, reversible actions can move with limited review: enrich a missing company size, create an internal task, summarize account activity, flag a duplicate, or recommend a lifecycle-stage check.

Medium-risk actions may need sampled review or threshold-based approval: route an inbound lead, update lead score, draft an account-specific email, move an account into a campaign audience, or flag a deal as at risk.

High-risk actions need explicit human approval: sending external communication, changing opportunity stage, altering forecast category, suppressing an account from outreach, notifying an executive customer, or launching a campaign to a strategic segment.

The mistake is treating human review as a single checkbox. It should be a policy map.

For each workflow, define what the agent can do alone, what it can prepare for review, what it must escalate, and what it should never touch. Then make those rules visible to the people who live with the consequences: sales, marketing, CS, RevOps, finance, and leadership.

6. Observability and evals

If a human makes a bad GTM decision, you can usually ask them what happened.

If an agent makes a bad GTM decision, you need the system to show its work.

This layer captures the trace of the run: what triggered the workflow, what data was retrieved, which tools were called, what the agent decided, what guardrails ran, what was approved, what action happened, and what changed afterward. OpenAI’s Agents SDK tracing guidance describes traces that include model generations, tool calls, handoffs, guardrails, and custom events. That is the kind of shape GTM systems need if agents are going to operate inside revenue workflows.

Observability is not only for debugging. It is how the team learns what to trust.

If the agent keeps routing a certain segment incorrectly, that may reveal bad territory logic. If it drafts weak messages for one persona, that may reveal missing positioning context. If it frequently escalates one campaign type, that may reveal an unclear approval rule. If it spends too much on enrichment calls for low-fit accounts, that may reveal a unit economics problem.

Evals turn those patterns into a quality loop. The team should evaluate whether the agent selected the right tool, used the right context, followed policy, produced useful output, and improved the commercial outcome. Without evals, the GTM team is left with vibes, anecdotes, and a few screenshots from the demo environment.

That is not enough when the agent is touching pipeline.

7. Revenue feedback loops

The last infrastructure layer is the one many teams forget: outcomes.

If an agent recommends a lead route, what happened to response time, conversion, and accepted pipeline? If it triggered a renewal-risk alert, did the CSM intervene earlier? If it created an account brief, did the AE use it? If it enriched a campaign audience, did the campaign generate better meetings or just cleaner-looking dashboards?

Agentic GTM should be measured against commercial movement, not activity volume.

The feedback loop needs to connect agent actions to revenue outcomes over time. That includes conversion rate, sales cycle, win rate, meeting quality, response time, routed-account acceptance, override rate, campaign influence, expansion risk, and pipeline accuracy.

It also needs a way to improve the system. Useful corrections should flow back into data contracts, prompts, playbooks, routing rules, approval thresholds, and evaluation cases. The system should become more precise because the workflow ran, not merely because a human cleaned up after it.

This is where agentic GTM becomes interesting. A good system does not only execute work. It creates evidence about how GTM work should improve.

How teams are applying the Stack

The teams making progress are starting with one narrow revenue workflow and expanding the agent’s authority as the surrounding system earns trust.

At Archlet, the sequence began with ICP definition and CRM hygiene. The team then connected event-lead enrichment, inbound scoring and routing, structured meeting-note writeback, and reactivation plays across Clay and HubSpot. The vendor case study reports 2.5x BDR productivity and large reductions in weekly processing time. The useful lesson is the sequence: make the data and workflow legible before asking the agent to take on more authority.

Cursor shows a broader version of the same pattern. Its internal ChatGTM system sits above Salesforce, Gong, the warehouse, Slack, and other sources. It retrieves context on demand, drafts signal-based outreach and call briefs, supports account planning and forecast review, and lets sellers create repeatable skills and automations. The reported results are early and self-reported, but the architecture is instructive: live context, scoped tool access, rep review, and measurement against pipeline, ramp time, and sales-cycle metrics.

The systems are different in sophistication, but the operating logic is the same: establish trusted data, make the workflow explicit, keep ownership visible, and expand agent authority only after the team can inspect the result.

Where the Stack breaks

The failure modes are rarely glamorous: duplicate accounts, stale territory fields, segment-inappropriate messaging, unclear ownership, irreversible CRM writes, and attribution that cannot separate agent-assisted pipeline from everything else. The workflow may be faster, but the business still cannot tell whether the decision was right.

Share

Agents expose these operating-model gaps because they remove the human workarounds: the manual double-check, the spreadsheet lookup, and the Slack message to the person who knows how the process actually works. That is why agentic GTM should be designed from one revenue workflow backward. The practical versions are covered in AI Agents for RevOps: 7 GTM Plays That Turn Existing Signals Into Warm Pipeline.

The Agentic GTM Breakpoint Audit

Trace one workflow from trigger to outcome and find the first point where trust breaks:

1. Signal: Did the workflow start from a reliable, timely signal?

2. Context: Did the agent receive the account and customer context needed to decide?

3. Decision: Were the rules, criteria, and definition of a good decision clear?

4. Authority: Was the agent allowed to take that action, and was approval required?

5. Execution: Did the workflow and connected tools carry out the decision correctly?

6. Outcome: Was the result recorded and connected to a business metric?

7. Learning: Did the system capture overrides, errors, and downstream outcomes?

That map will tell you whether you need an agent, a rules-based workflow, better data activation, a CRM cleanup project, a permission model, or a human process decision that nobody has wanted to write down.

How founders and CROs can apply the Stack

Before buying or building another GTM agent, choose one workflow and run this audit.

1. Define the commercial job

Do not start with “build an agent.” Start with the revenue motion.

Examples:

• Route inbound demo requests within five minutes.

• Identify expansion-risk accounts before renewal.

• Turn website intent into account-owner alerts.

• Prepare enterprise account briefs before discovery calls.

• Re-engage closed-lost opportunities when new buying signals appear.

• Detect champion job changes and recommend the right relationship move.

If the commercial job is vague, the agent will be vague with better formatting.

2. Map the signal path

List every signal the workflow depends on.

For inbound routing, that might include form fields, firmographics, account ownership, territory, company size, existing customer status, partner source, product interest, and rep capacity.

For expansion risk, it might include product usage, support tickets, NPS, executive sponsor changes, contract date, open opportunities, renewal owner, and recent call sentiment.

The goal is to see whether the signal path already exists or whether the agent would have to assemble it from fragments every time.

3. Name the source of truth

For each required field, decide which system wins.

CRM may own account stage. The warehouse may own product usage. Marketing automation may own campaign membership. Support may own open-risk signals. Finance may own contract value. Conversation intelligence may own call evidence.

This is tedious work. It is also the difference between a reliable workflow and an agent confidently choosing the wrong field.

4. Decide the action boundary

Write down what the agent may read, recommend, write, send, and escalate.

This should not live only in a vendor admin screen. It should be a GTM operating decision.

If the agent can write to CRM, define which fields. If it can draft emails, define when a human approves. If it can trigger workflows, define rollback. If it can use enrichment credits, define spend limits. If it can route records, define how exceptions are handled.

5. Instrument the workflow

Before launch, decide what must be logged.

At minimum:

• trigger

• input context

• systems queried

• tool calls

• agent recommendation

• approval decision

• action taken

• human override

• downstream outcome

If the team cannot inspect why the agent acted, the workflow is not ready for meaningful autonomy.

6. Choose the outcome metric

Do not stop at hours saved.

Hours saved matter, but GTM leaders need to know whether the workflow improved revenue performance. Track the metric that corresponds to the commercial job: speed-to-lead, lead-to-opportunity conversion, meeting acceptance, opportunity creation, campaign-sourced pipeline, expansion-risk intervention, win rate, cycle time, or forecast accuracy.

If the workflow cannot be tied to a business outcome, keep it in an assistant or recommendation mode until the measurement model is clearer.

7. Build the correction loop

Every agentic workflow needs a way to get better.

When a human overrides the agent, capture why. When the agent uses bad data, fix the source or the data contract. When the agent routes the wrong account, inspect whether the territory rule, context retrieval, or scoring logic failed. When an output is weak, decide whether the issue is prompt, positioning, source context, or the task itself.

The correction loop is where the infrastructure compounds. Without it, every agent remains a clever intern with no memory of last week’s mistakes.

Operator Note

I would not start by asking which agent to add next. I would start with the revenue workflow the team can explain clearly enough for a non-human operator to run.

Name the signal, the source of truth, the owner, the permission boundary, the escalation path, and the outcome. If one of those is missing, the next useful investment is probably an operating decision or data fix rather than another agent.

The teams that build this clarity early will move faster later. They will know where autonomy is useful, where human judgment belongs, and whether an agent improved the commercial result rather than simply producing more activity.

Question Worth Sitting With

When an agent touches your GTM system next, can the team see what it knew, what it was allowed to do, who owned the decision, and what the business learned?

About me

I help founders and GTM teams build or upgrade AI-native GTM engines that turn signals, customer context, and AI workflows into pipeline.

Want to work with me?

Get AI GTM Snapshot

Book a call

Connect with me on LinkedIn

That fragmentation becomes more expensive as more of the buyer journey happens before sales is invited in. Deloitte describes B2B buyers using LLMs to configure solutions and compare vendors, while Forrester points to the need to align qualification, buying-group engagement and value creation across the customer lifecycle.

What You Will Learn

This article looks at how GTM leaders are moving from isolated AI use cases toward revenue architecture: a system that connects context, signals, routing and accountability, actions and learning around an account. You will see what the operator examples reveal about product signals, signal-based outbound, sales coaching and human review, and where founders, sales leaders and RevOps teams need different operating choices. I will close with the changes worth watching over the next six months as AI becomes part of the GTM operating model.

The Revenue Architecture Shift

The account-level coordination problem is why AI adoption alone tells a limited story. A team can have useful tools and active workflows while account prioritisation, handoffs and seller decisions still run on fragmented information.

McKinsey’s 2026 B2B sales research and its analysis of the new economics of B2B growth point to the same commercial change: the advantage comes from rewiring workflows around sellers, customers and measurable impact, rather than adding isolated AI use cases.

By revenue architecture, I mean the structure that turns scattered information about a market, account or customer into a consistent commercial response. It defines what the business knows, which signals matter, who can make which decisions, where work goes next and how the result improves the next decision.

Hassan Mahmood, a GTM Strategist & Revenue Architect, describes what that looks like in the revenue system:

The biggest leverage is making the revenue system more intelligent and measurable end-to-end. AI can evaluate account and intent signals, prioritize who should be worked, enrich and maintain CRM data, and trigger the right outreach or handoff in real time. The opportunity isn’t just using AI to write better emails or automate individual tasks. It’s using AI to connect research, prioritization, outbound, routing, and pipeline management so reps spend more time in high-value conversations and less time figuring out what to do next.

This example puts a commercial outcome behind an abstract term: better account prioritisation and routing, cleaner revenue data, and more seller time for live conversations. That outcome relies on five connected layers: context, signals, routing and accountability, actions and learning.

Taken together, these layers are a practical way to diagnose where an AI-enabled revenue system will hold or fail. A company can have excellent signals but no shared account context, identify the right account without routing a response, or produce useful work that never becomes organisational learning.

Context: From Fragmented Knowledge to Shared Account Context

Most companies already have an ICP (the more interesting question is whether marketing, sales and the CRM are using the same one?)

Across companies, the information needed to make a better account decision sits with different teams, in different systems, and is applied for different purposes: Marketing has an ICP definition. Sales has qualification criteria. Product sees usage. Customer success has the history of what the customer actually values. RevOps owns the fields that are meant to connect some of it.

As AI becomes part of research, prioritisation and customer work, that fragmented context becomes more visible. An SDR can research an account without seeing product usage. A sales manager can coach a rep without the agreed qualification standard. Marketing can build a campaign from an ICP definition that does not match the one used in the CRM. The adjustment is to establish a shared commercial reference before asking AI to act on it.

That reference rarely centralises every document in the business. Instead, it gives the revenue system a consistent answer to a smaller set of recurring questions: who is a good-fit account, what evidence supports the positioning, what counts as meaningful engagement, how an opportunity is qualified, and which team owns the next step.

Across companies building this shared reference, the material being connected tends to be familiar:

• ICP and disqualification rules;

• product positioning and proof points;

• account research and qualification standards;

• sales-process definitions and CRM field ownership;

• approved claim language, tone expectations and examples of good and bad output.

The same principle applies to the workflows teams are now turning into reusable AI skills. The pattern can govern account research, qualification briefs, handoff preparation and CRM enrichment as easily as it can govern content work. The useful versions carry a clear brief, relevant reference material, boundaries and a defined output; without those, each use recreates the same interpretation work.

Norbert Bezzina, a Creative Content Strategist, names the asset correctly:

The system that works best for me is building reusable AI skills rather than one-off prompts. Each skill is a documented process for one task: brand design, content ideation, writing, research, infographics, and carousels. Each holds its own reference files, tone rules, and output format, so the output hits the same standard every time. A prompt gets forgotten. A skill becomes part of how the work runs.

Tahnee Perry, an AI-led founder and educator, shows why clear boundaries matter:

The workflow that worked was breaking my content process into standalone Claude skills, each owning a single job: brand context, audience context, writing style, and campaign execution. They stack instead of overlap. What made it effective was the boundary-setting. When one skill tried to handle strategy and copy at once, it blended the two and produced generic output. Splitting them forced every part of the system to do one thing well.

Their examples come from content work, but the operating implication is broader. Reusable context lets marketing, sales and RevOps apply the same commercial standards across different workflows. In practice, the teams moving first are making the few rules that should travel with the work available where decisions are made.

What Teams Are Building Now

Signals: From Static Lists to Live Commercial Relevance

Once the business has a shared way to assess an account, it can make better use of live behaviour. Most GTM plans still begin with a target list based on firmographic fit, then ask sellers to work through it. AI gives teams a practical way to update that priority when a person, team or account does something that suggests genuine relevance.

This is particularly visible in product-led and self-serve businesses, where product usage and sales pipeline often remain separate. A user can sign up with a personal email, invite colleagues or start paying while sales continues cold-prospecting into the same market. The emerging pattern is to connect that behaviour to an account, interpret it in context and let it change the next commercial move when the evidence warrants it.

The distinction between useful and noisy signals is increasingly being set at leadership level: which combinations of behaviour change account priority, and which response they trigger. A product signup, for example, is one data point. Several users from the same company, a paid upgrade and a relevant hiring pattern tell a more useful commercial story.

Konrad Kucharski, CRO & Co-Founder at Aviato, connects product behavior to account-level GTM:

The workflow I keep coming back to is treating existing self-serve users as your warmest pipeline, not just your user base. Many people sign up or buy with personal emails, but inside that data is a map of who those users are at work. Enrich those emails, connect them to companies, and anonymous signups can become account-level buying signals: which teams are already using the product, where usage is clustering, and where the next enterprise conversation should start. What makes it effective is that you stop guessing. You build outreach on behavior that already happened, from people who have already chosen to spend money or time with you.

Ariel Levin, GTM Automation Consultant for B2B Tech, applies the same logic upstream in signal-based outbound:

The one that’s actually worked for us isn’t an AI copywriter. It’s an AI qualifier. For a cybersecurity client, we monitor about 175 LinkedIn accounts in their category: analysts, practitioner voices, and competitor pages. When one of them posts something relevant, the system pulls everyone who liked or commented. That engagement list is the real asset, because people debating SSE rollouts in a comment thread are far more interesting than anyone sitting on a static list. From there, AI makes two judgment calls: is the post actually about the category, and after enrichment, does the engager match the ICP on title, company size, geography, and industry. Only matches land in Clay for human review. What makes it useful is where AI sits. It is not writing messages. It is making the thousands of small relevance decisions an SDR would otherwise make by eyeballing profiles, and doing that before we spend money on enrichment rather than after.

Together, these examples show the same shift: operators begin with evidence of behaviour, then assess whether it is commercially meaningful for a specific account. Konrad uses product behaviour to reveal warm enterprise potential. Ariel uses category engagement to decide which people merit enrichment and human review.

The workflows that hold together tend to follow the same sequence, even when the data work is difficult: capture the behaviour, connect it to the likely account, assess the pattern against the ICP, set a threshold for sales action, and write the result back to the CRM. This is how a signal becomes shared account history rather than another isolated data point.

What Teams Are Building Now

From Signal to Response: Routing and Accountability

A signal only matters when it changes what the company does next. In a product-led motion, that may be several self-serve users from the same company and a paid upgrade. In signal-based outbound, it may be a person engaging in a relevant category conversation who also matches the ICP. Both patterns give the business a reason to pay attention to an account. In the teams I work with, the handoff that follows is where an otherwise useful workflow usually breaks down: when an account changes, who owns the next move?

A Slack alert with no owner is simply a faster way to create a future apology.

The next decision is the commercial response. Should the system update an account score, create a task, prepare an account brief, notify the owner, draft outreach or wait for human review? Routing and accountability define which response follows, which steps happen automatically, and who owns the result.

The more mature AI RevOps workflows are adding three controls. Access defines which systems a workflow can read and which fields it can write. Escalation defines which customer-facing, high-value or difficult-to-reverse actions need approval. Traceability lets the team inspect the instructions, scoring rules, failures and commercial outcomes behind a decision.

That is the operating change beginning to show up in GTM teams. Account response is moving from something a seller or manager discovers and reconstructs individually to a shared workflow that interprets, routes and records it. Routine steps can run quickly; managers and sellers retain ownership of the commercially consequential move. That creates the conditions for the next layer: using AI to prepare commercial work without handing away the judgment inside it.

What Teams Are Building Now

Actions: From Automated Output to Human Commercial Judgment

Routing determines who receives a signal and what response follows. The next design decision is what reaches that person: AI can assemble account evidence, identify exceptions and prepare a recommendation before a manager, seller or founder makes a commercial call.

That is how GTM work is changing. AI is moving upstream into preparation, while a named person remains responsible for interpreting the evidence and owning the customer, deal, message or coaching decision.

Keith Cordeiro, Revenue Leader and GTM Strategist, shows this in an internal revenue workflow. His system gathers the relevant evidence before a rep 1:1, so the manager can spend the meeting on the conversation and decision that follow.

The biggest lift for my team has been converting manager prep time into coaching time. A rep 1:1 used to start with me stitching together a CRM pull, notes from the last review, and a few call recordings. That assembly work now runs as an agent: it pulls live pipeline, layers in call data and the prior review, compares against benchmarks, and hands me a coaching guide before the meeting. The guide surfaces exceptions I used to skim past: untouched leads at accounts with open opportunities, blank qualification fields, or deals that went single-threaded and quiet. AI is excellent at assembling evidence and flagging exceptions, but the conversation with the rep is where the value actually lands. That part stays human.

Keith’s workflow illustrates a boundary I see repeatedly in client work. Teams can automate plenty of preparation work; the harder design choice is deciding which judgment can be standardised and which still needs the person accountable for the deal. Here, the agent assembles the evidence and flags exceptions; the manager interprets it, coaches the rep and owns the action that follows.

That is where human-in-the-loop GTM matters most: customer-facing work needs the same division, with a tighter boundary. AI can research, structure and identify relevant signals, but the person accountable for the relationship still has to interpret the context, choose the angle and decide what should be said.

Monika Grycz, who works in GTM Partnerships & Content, sees the same boundary in customer-facing work:

For personal-brand-led GTM, the way I see it is that you as a human need to be behind the ideas: your POV, your experience, your specific take on things. AI helps you structure, write properly, format, maybe research, but the raw material has to come from you. The only thing AI truly can’t replicate is life experience. On the outbound side, AI is great at scale and bad at relevance when left alone. I use it to build lists, find signals, and move fast, but I still decide what that signal means for a specific person, what angle to take, and what not to say. The pattern I keep seeing: people who use AI as a thinking partner stay differentiated. People who outsource the thinking to it start sounding like everyone else.

The change is a redesign of work around a decision. In the emerging model, managers receive evidence before a coaching conversation, reps receive account context before outreach, and founders receive a clear account view before a strategic deal discussion. AI prepares the material; a named person remains accountable for the commercial judgment and the outcome.

What Teams Are Building Now

Learning: From One-Off Workflows to Revenue Memory

Once a team has implemented agentic GTM workflows for research, scoring, routing and preparation, the next shift is to turn the commercial decisions those workflows support into a feedback loop. That is what revenue memory means in practice: the business captures why it acted, what it did and what happened next, so the next account decision starts from more than a one-off output.

The teams moving beyond one-off workflows are beginning to retain four parts of the decision: the trigger that started it, the recommendation or human judgment that followed, the action taken, and the commercial outcome.

Without that chain, an account brief, qualification decision or coaching analysis disappears into Slack, a document or an untracked chat thread. The team may gain speed, but it has no reliable way to see whether the workflow improved qualification, conversion, deal quality or rep performance.

Revenue memory gives the next decision some history. A signal threshold can be revised because the previous one created poor-fit opportunities; a routing path can change because accounts repeatedly stalled; a coaching approach can improve because its effect is visible over time.

That is the change in the operating model. AI-assisted GTM becomes more valuable when each decision makes the next one better, rather than producing a new set of disconnected outputs every week.

What Teams Are Building Now

What I Would Watch Over The Next Six Months

The operating choices above will become more visible as AI go-to-market systems move from individual use cases into everyday GTM work. Four developments are likely to separate companies that have adopted useful tools from companies that are actually changing how revenue decisions are made.

The test I keep returning to is fairly mundane: when an account changes priority, can anyone outside the original team see why? If the answer is no, the business has added activity without creating shared commercial intelligence.

1. The buyer-side AI gap will widen

Buyers are adopting AI for research, comparison and internal problem framing faster than many GTM teams are adapting their commercial process. That raises the cost of generic positioning, generic content and generic outreach because a buyer can generate a competent summary of most category information without speaking to a vendor.

The companies worth watching will connect their category point of view, product evidence and account signals earlier in the buyer journey. Their commercial teams will need to add interpretation, relevance and proof that a buyer cannot get from a general-purpose assistant.

2. RevOps will become the AI control function

Once an AI workflow can read and write in the CRM, enrich an account, change a score or trigger a handoff, it becomes part of the revenue system. It needs an owner for permissions, data quality, versioning, audit trails and rollback paths.

This expands the RevOps role beyond buying software or cleaning fields. The strongest teams will define where the workflow can act, where it must escalate, and which commercial outcomes justify extending its scope.

3. The durable advantage will sit in commercial context

Models will keep becoming cheaper and more capable, while access to an assistant remains easy to copy. The harder asset is the company-specific context around it: the definition of a good-fit account, the evidence behind the positioning, the account history, the qualification standard, the handoff rules and the feedback from real outcomes.

That is why the most consequential AI GTM work sits below the interface. It lives in the decisions about what the revenue system should know, remember and improve.

4. Sales leadership will shift from activity management to decision quality

AI can assemble evidence, identify anomalies and prepare the work. Sales leaders still decide whether an account deserves attention, whether a deal has real momentum, whether a message carries a point of view, and whether a rep needs coaching or a process change.

The management question becomes sharper: where does more speed improve a decision, and where does it simply multiply low-quality activity?

Over the next six months, the meaningful divide will emerge in the revenue system itself. The companies making progress will use AI to improve how revenue work is informed, governed and learned from, not only to increase the amount of work produced.

Question Worth Sitting With

When the next strategic account moves, can the revenue system show what signal mattered, who made the call, what happened next, and what the previous decision taught it?

About me

I help founders and GTM teams build or upgrade AI-native GTM engines that turn signals, customer context and AI workflows into pipeline.

Want to work with me?

Get AI GTM Snapshot

Book a call

Connect with me on LinkedIn

As production speeds up, brand voice has to move ups…

Read more

The problem is that these terms describe different parts of the system, but they are often presented as if they are competing products. An API is not an MCP…

Read more

These days buyers get in touch with your sales team once they’ve already read the website, compared three competitors, skimmed a few reviews, and asked ChatGPT whether your category is just five vendors wearing the same …

Read more

Most B2B companies already have enough data to identify warmer paths into pipeline. They know who fits the ICP, which accounts are showing intent, where former champions have moved, which opportunities were lost because …

Read more

To understand what employers are actually hiring for, I analyzed 440 GTM Engineering and adjacent job descriptions across the US and Europe. The research examined how companies define the role, which capabilities they prioritize, where the role sits organizationally and how those differences affect compensation.

This article maps the five mandates hiding beneath the GTM Engineer label - from RevOps operator to AI-native architect - and shows how each changes the required skills, operating scope and compensation, with advertised US salaries reaching $350,000.

It also explains why the US sample contains 81 explicit GTM Engineer titles while Europe contains only three, even as both markets build similar capabilities through different role families.

For candidates, it provides a clearer career map; for leaders, a practical way to distinguish tool administration, workflow design and revenue-system ownership before an expensive title begins making decisions on their behalf.

Share

What you will learn

This article explains:

• How GTM Engineering is emerging in the United States and Europe—and why similar work appears under different titles.

• What companies are paying and which technical skills, tools and AI capabilities they expect.

• How regional operating models shape workflow ownership and where the market is heading next.

• How to distinguish the five GTM Engineering mandates and translate them into better hiring and career decisions.

Methodology note

I compared titles, responsibilities, AI requirements, technical skills and advertised compensation across 440 job descriptions: 296 US roles and 144 European roles. The findings reflect employer demand, not employee adoption or implementation outcomes. Salary figures are directional, based on 75 US and 29 European roles with usable compensation data.

The emergence of GTM Engineering as a distinct function

GTM Engineering is becoming a distinct function because revenue work no longer stays inside one CRM, automation platform or department. Qualification, routing, research, lifecycle management and customer handoffs now depend on connected data, APIs, code and AI. Once those systems influence commercial decisions, someone has to own the workflow as a whole.

The title is formalizing unevenly: among 296 US roles, 81 explicitly use GTM Engineer; among 144 European roles, only three do. Europe has not misplaced the profession somewhere between Lisbon and Helsinki. The capability appears through Solutions and Sales Engineering, Platform and Cloud, Automation, RevOps, Operations and Data roles.

The surrounding evidence confirms that the work already exists. The US sample includes 95 Solutions or Sales Engineering signals, 150 AI-core or agentic roles and 152 API signals. Europe includes 47 Solutions or Sales Engineering signals, 32 AI-core or agentic roles and 48 API signals.

For candidates, the implication is practical: search by capability as well as title. For hiring leaders, the warning runs in the other direction. A familiar title can still conceal three departments’ worth of responsibility and a heroic Slack channel.

GTM Engineer salary in 2026

If one title covers several mandates, salary benchmarking by title can only be directional.

In the United States:

• 75 of 296 roles contain usable salary information

• Coverage is approximately 25%

• The median salary-range midpoint is $167,500

• The highest observed salary is $350,000

In Europe:

• 29 of 144 roles contain salary information

• Coverage is approximately 20%

• The directional EUR median signal is around €90,000

• The directional UK median signal is around £50,000

These figures are market signals, not a clean transatlantic benchmark. European roles span countries, currencies and role families; US descriptions may combine base salary, OTE and different seniority levels. The work itself also varies sharply.

A tool operator may configure enrichment, CRM rules and outbound workflows inside a defined platform environment. An AI-native architect may own custom integrations, production agents, monitoring, human review and commercially sensitive decisions. Pricing them as equivalent creates the comforting appearance of precision while comparing different jobs.

Benchmark the mandate before you benchmark the salary.

For leaders, that means controlling for technical depth, commercial accountability, seniority, geography and operating scope. For candidates, it means evaluating the ownership behind the offer rather than assuming the title explains the opportunity.

GTM Engineer skills and technical stack

The technology requirements reveal which version of the role a company expects to hire.

United States GTM Engineer tech stack

The strongest US technical signals are:

• APIs: 152 mentions

• AI agents: 134

• Python: 115

• Salesforce: 84

• Clay: 72

• JavaScript: 68

• SQL: 61

• REST: 57

• Claude: 46

• HubSpot: 43

The US stack sits between revenue operations and custom systems development. Salesforce, HubSpot and Clay anchor the role in CRM, enrichment and pipeline execution. APIs, Python, JavaScript and SQL show where configuration ends and integration work begins. AI agents add a further requirement: governing context, actions and human review.

European GTM Engineer tech stack

The strongest European technical signals are:

• APIs: 48 mentions

• AWS: 40

• Microsoft Azure: 40

• Python: 39

• AI agents: 35

• Kubernetes: 30

• Terraform: 25

• Docker: 24

• REST: 22

• Google Cloud: 20

The European stack starts closer to cloud infrastructure, deployment and technical delivery. APIs, Python and agentic requirements then connect that foundation to commercial workflows.

From tool lists to capability design

Across both regions, the strongest profiles combine:

• Understanding of pipeline and customer workflows

• CRM and revenue-data fluency

• APIs and system integration

• Workflow automation

• Data handling and transformation

• Coding where platform configuration reaches its limits

• AI orchestration with review and governance

• Ability to connect technical work to commercial outcomes

For candidates, this is a development map rather than a shopping list of certificates. For leaders, it is a reminder that knowing Clay, Salesforce or Python says little about which workflow a person can own. Several purchasing decisions may have formed a small support group; that does not make them an operating model.

Regional differences in role standardization

The clearest regional difference is the organizational starting point. US roles more often begin near Growth, RevOps, pipeline orchestration and revenue systems, becoming more technical as workflows require integrations, code and AI governance. European roles more often begin in Solutions, Platform, Cloud, Automation or Data, then expand toward commercial systems ownership.

That distinction changes how companies should search and benchmark. US candidates can find the title more easily but still need to interrogate the mandate. European candidates may already be doing the work under a different role family. A hiring leader comparing the two markets should therefore look at workflow ownership, technical depth and commercial risk before title or salary.

Both markets are converging on the same requirement: one accountable owner for the systems connecting revenue workflows, data, automation, APIs, AI and human judgment. The title is simply arriving at different speeds.

Market trends and the next 12–24 months

The market is moving toward a more technical, integrated revenue function. AI-core or active requirements appear in 253 US roles and 96 European roles, while APIs are the leading shared technical signal in both regions. Companies are adding AI alongside CRM, data, programming and infrastructure skills because useful automation depends on connected systems.

My operator view is that US title standardization will continue, while Europe will keep converging through adjacent roles before the label catches up. APIs will increasingly be treated as GTM infrastructure. Agentic workflows will move into monitored production, where permissions, observability, escalation and human review matter rather more than the demo’s enthusiasm.

That shifts value toward systems builders who can design reusable workflows, make failures visible and connect technical decisions to commercial outcomes. Candidates should build evidence of that ownership. Leaders should hire for it. Anyone watching the market should expect the title to become clearer before the mandate does.

Subscribe to receive the complete 2026 State of GTM Engineering report, including compensation signals, regional skill data, the five-level Mandate Framework and the hiring maturity diagnostic.

Read more

In 2026, high-performing GTM teams are redesigning the operating model beneath their tools. It’s not a secter that tool access is no longer the moat (everyone has access to the same frontier models, signal sources, AI CR…

Read more

AI saves time - Teams move faster - Manual work disappears.

The spreadsheet finally stops looking like a tiny administrative hostage situation, and for one brief second everyone believes the productivity soufflé will rise on schedule.

But what’s happening under the hood?

Recent reporting on res…

Read more

Build a list. Find contacts. Launch sequences. Generate enough activity and some percentage of it would eventually turn into pipeline.

As databases improved and automation got cheaper, the playbook scaled surprisingly well: teams that could reach the most people, the fastest, often won.

2026 Reality: Most…

Read more

A typical legacy stack runs $300–500 per user per month (that’s just the software). Then there’s the integration hell: hidden costs to make tools that weren’t designed to talk to each other actually work, custom consulting hours to keep it from breaking every quarter. If you have 8–15 SDRs, you’re probably spending $4,000–8,000/month on tooling alone, before accounting for the human hours filling the gaps.

But the real cost isn’t the tools. It’s what the tools don’t do.

Your SDRs spend only 25% of their working hours actually selling. The other 75%? Manual research. Data entry. Logging calls. Chasing down enrichment that should have been automatic.

With a legacy stack, an SDR runs 104 activities per day and lands a real conversation from maybe 18% of them. That is expensive guessing dressed up as a pipeline engine.

You can’t hire your way out of this problem. SDR turnover runs 30%+ industry-wide — some mid-market companies see 55%. Your reps stay 14–18 months on average. After a 3-month ramp, you’re getting barely a year of actual productivity before the replacement cycle begins.

Replace one SDR? $100K–$160K all-in (salary, benefits, stack costs, training, lost productivity). Do that twice a year on a team of six and you’re spending $200K–$320K just to maintain baseline.

Here’s what I see consistently: leaner, newer companies are running smaller outbound teams and generating more pipeline - because their people aren’t doing the data work. Your team is still staffing the workflow. You’re not losing on strategy. You’re losing on how much of your payroll actually touches a prospect.

Mid-market companies locked into legacy infrastructure have to hire 2–3x more headcount to generate the same pipeline volume as teams running modern AI outbound tools. You’re not overstaffed because your people are weak, rather because your tools are inefficient.

The cost of staying isn’t the monthly bill. It’s the headcount you can’t redeploy. It’s the velocity you’re losing because iteration takes months instead of weeks. It’s the talent you’re burning because nobody wants to spend their day logging calls.

If you’re still running manual list-building + a decade-old sequencer in 2026, your leaner competitors aren’t.

WHAT YOUR LEGACY STACK IS ACTUALLY DOING TO YOU

Built for a Different Era (Now It’s Quietly Throttling Your Growth)

The infrastructure you’ve got made sense when you built it. Maybe 2008 or 2015. At the time, it was the right call, and honestly, getting any repeatable process in place was an upgrade over the chaos that came before it. I’ve seen what pre-process outbound looks like. Your old stack was a genuine step forward.

The problem is what it can’t do now.

The typical mid-market setup: A CRM as your source of truth, Outreach or SalesLoft as your engagement layer, maybe Apollo or ZoomInfo for enrichment, and a lot of human labor gluing it all together. No workflow automation between tools. No AI prospecting layer. No intent signals. Just good people doing slow work.

It breaks for three specific reasons:

First: Research is a bottleneck. Someone manually hunts through LinkedIn, job boards, company websites, news. They stitch together what they can from Apollo or ZoomInfo. Fifteen to twenty minutes per prospect. Multiply that by 50–100 prospects per SDR per week. That’s 12–30 hours of pure research time — and you still end up with gaps. Missing job titles. Incomplete tech stack data. No signal about what’s actually happening at that account right now.

Second: There’s no outbound automation layer. Each step requires a human decision and manual input. Research done? Enrich manually. Enrichment complete? Write the message. Schedule follow-ups. Log it. Each handoff is a friction point. You can’t test a new ICP segment in a week. You can’t run a targeted campaign without a month of planning. Your velocity is capped by how fast humans can move data.

Third: Deliverability is a problem hiding in plain sight. Legacy stacks don’t come with native IP warm-up, DKIM/SPF/DMARC configuration, or domain rotation logic. Gmail placement dropped from 89.8% (early 2024) to 87.2% by Q4 as spam filters tightened. Weak authentication can cause an 80% delivery drop.

The deeper issue: these tools were built for control, not leverage. At 5 SDRs, fine. At 15, you’re choking. At 25, you’re hemorrhaging productivity and wondering why you need to keep hiring just to stay flat.

The teams that stay on legacy stacks assume the answer is “get better people.” The teams rebuilding with AI outbound automation assume the answer is “get better infrastructure.” Guess which one scales.

THE MODERN AI OUTBOUND STACK

What Actually Works — Without Ripping Everything Out

The modernized outreach setup isn’t about chasing AI hype. It’s about efficiency: tools that talk to each other, AI handling the grunt work, and your people doing the thinking. When I build these systems for mid-market teams, I think in four layers — each with one job.

Subscribe now

Layer 1 — AI Prospecting + Enrichment: Tools like Clay, Apollo (upgraded tier), or Smartlead. The job isn’t “build a list faster.” It’s “reduce human research time from 20 minutes per prospect to 2 minutes.” You define the criteria — title, company size, tech stack, buying signals — and the system returns verified matches with context. Not a list. A qualified hypothesis about where your buyer actually is.

This is where AI prospecting automation does its heaviest lifting. Instead of an SDR manually hunting for 20 minutes, a custom workflow pulls, enriches, and scores each prospect before a human ever touches it. I build these as tailored Clay or n8n workflows — configured to your ICP, your signals, your CRM. Not off-the-shelf. Built for how you actually sell.

Real numbers: teams using modern AI research tools report 40–60% reduction in research time per prospect. That frees up 10–15 hours per SDR per week.

Layer 2 — Delivery + Inbox Reliability: Instantly, Lemlist, or your existing sequencer upgraded with proper authentication and warm-up. The job is getting emails into the inbox reliably — not just sending them. Modern tools handle DKIM/SPF/DMARC setup, domain rotation, and IP warm-up so your reply rates don’t crater. Legacy tools leave this to chance.

Modern AI outbound infrastructure maintains 87–90% inbox placement. That’s 12–15 percentage points better than an unmanaged legacy setup — before you change a single word of your messaging.

Layer 3 — Intent Signals + AI Buying Triggers: Clearbit, 6sense, or signals surfaced through custom automation — recent funding, hiring sprees in the right department, tech stack changes. You’re not guessing who to contact. You’re responding to actual market signal that tells you why someone should care right now.

This is where AI agents add real, measurable value — not as a vendor gimmick, but as a layer that monitors your target accounts and surfaces the right ones at the right time. Teams that build this layer first report 35–50% improvement in reply-to-opportunity conversion.

Layer 4 — CRM + Workflow: HubSpot, Salesforce, or Pipedrive. This is where data lives and humans make judgment calls. But it’s not where the work happens — the AI outbound stack handles that. The CRM just keeps score, and with the right automation, it updates itself.

The cost picture: A modern AI outbound stack (Clay + Instantly + signal tooling + HubSpot) runs roughly $800–1,500/month for a mid-market team of 5–10 SDRs. The same team on legacy per-user SaaS costs $4,000–8,000/month — plus the human hours gluing it together. That’s a 60–70% cost reduction, plus 10–15 hours per SDR per week freed up.

Modernization is not rip and replace. You keep your CRM. You keep your process. You automate the manual layers around it. Pilot with one workflow first. Then roll.

YOUR 90-DAY MODERNIZATION ROADMAP

Read more

There. I said it.

(Yes, I know. Very brave. Please alert the innovation police.)

Right now, the market is having one of those deeply spiritual technology moments where every normal business process suddenly needs to become “agentic.”

Customer support flow? Agent.

Sales research workflow? Agent.

Internal reporting? Agent.

Someone renamed a Zapier automation with an LLM step inside it? Apparently also an agent.

Very powerful. Very futuristic. Very webinar-friendly.

But what’s actually happening in many companies is much less cinematic.

A lot of “AI agents” being deployed in real businesses are just automations with an LLM stapled on top and a more expensive name.

Because apparently “workflow automation” doesn’t get invited to the cool kids’ table anymore.

But “agentic infrastructure”?

Now we’re cooking. Now we have a category.

The Boring Stuff Is Working

The companies quietly getting real value from AI are usually not deploying some magical autonomous goblin that thinks, plans, reasons, files your SOC 2 evidence, and saves Western civilization before lunch.

They’re doing boring things well:

They’re cleaning up repetitive workflows.

Reducing manual work.

Speeding up internal processes.

Keeping humans in the right places.

Making sure someone can audit what happened.

Disgusting, I know. Actual business value.

And this is where a lot of the agent hype starts to wobble.

Because once you move past the demo, the question is not:

“How autonomous can this be?”

The better question is:

“Does this need autonomy at all?”

Most of the time, the answer is no.

Subscribe now

The Expensive Agent Problem

I keep seeing the same pattern.

A founder spends serious money on a “next-gen AI agent” that sounds incredible in the pitch deck.

It can reason.

It can plan.

It can adapt.

It can make decisions.

It can probably write a poem about your pipeline if you ask nicely.

Then it enters the real world and immediately starts behaving like a Roomba in a room full of cables.

It burns tokens like a yacht burns fuel.

It breaks the second a customer behaves like a customer.

It becomes difficult to test, hard to audit, and almost impossible to explain clearly when someone asks the tiny, annoying question:

“So what exactly does this thing do?”

And that question matters.

Especially if you’re building inside a company where compliance, risk, security, or customer trust are not decorative LinkedIn words.

Regulated SaaS Makes This Even Funnier

In regulated SaaS, the agent conversation gets especially entertaining.

HIPAA and SOC 2 reviewers do not want a TED Talk about emergent reasoning.

They want the boring stuff:

What happens?

In what order?

Under what controls?

Where are the logs?

An automation can survive that conversation.

An agent often turns it into a six-month compliance escape room with worse lighting.

And this is not because agents are inherently bad.

It’s because autonomy adds uncertainty.

Uncertainty adds review time.

Review time adds cost.

Cost adds meetings.

Meetings add spiritual damage.

Very simple chain of events.

My Rough Rule

Here’s how I’d think about it.

Clear workflow?

Use automation.

High cost of error?

Use automation.

Compliance review?

Use automation. Twice. Drink water.

Unpredictable inputs, branching decisions, and actual judgment required?

Maybe you need an agent.

Maybe.

That’s the part the market keeps skipping.

Agents are useful when the workflow genuinely requires dynamic reasoning, adaptation, and decision-making.

But many business workflows do not.

They require consistency.

Controls.

Speed.

Visibility.

Repeatability.

Logs.

Basically all the words that make Twitter fall asleep but make operators quietly nod.

The Trend Says “Make Everything Agentic”

The trend says:

“Make everything agentic.”

The operator in me says:

“Maybe don’t attach a flamethrower to the toaster.”

Because autonomy is not automatically maturity.

Sometimes autonomy is just chaos with better branding.

And sometimes the smartest AI system is the one that does the boring thing reliably and shuts up.

That doesn’t sound as exciting.

It probably won’t get 4,000 likes from people who say “the future of work” five times before breakfast.

But it might actually work.

The Market Is Getting Smarter

I think the first wave of AI adoption was mostly curiosity.

What can we automate?

What can we generate?

What can we replace?

What can we call an agent before someone notices it’s a workflow with a fancy hat?

The next wave is different.

The founders and operators who got burned are asking better questions now.

Not:

“How do we use agents?”

But:

“What actually needs autonomy here?”

Where do we need judgment?

Where do we need reliability?

Where do we need a human in the loop?

Where do we need auditability more than cleverness?

Where is an LLM useful?

And where are we just adding a very expensive raccoon to a process that was already fragile?

That’s the discussion worth having.

Not whether agents are good or bad.

But where they actually belong.

Because most companies don’t need more AI theatre.

They need systems that work when nobody is watching the demo.

And right now, a lot of the value is still hiding in the boring automations.

Which is unfortunate, because boring doesn’t trend.

But it does ship.

So I’m curious.

What’s actually working for you right now?

And what keeps breaking the moment it leaves the demo?

I’ve worked with early-stage teams across different pricing motions - some PLG-first, some API-based, some open-core. And here’s the pattern that keeps coming up: the pricing model you pick in the early days doesn’t just shape your revenue—it shapes your runway, your roadmap, and your reputation with buyers.

Especially if you’re playing in the AI or developer tooling space, where copying functionality is trivial and infra costs rack up before your Stripe account does.

More than once, I’ve seen open-source become a trap. A team gives away too much for adoption, and when it’s time to sell into enterprise, they realize those companies are already using the free version—and have zero interest in paying for “upgrades” they’ve already hacked around.

That’s not a GTM problem. That’s a pricing blind spot.

If you’re not thinking about monetization from day one, you’re not building a product—you’re subsidizing someone else’s.

The good news? You’re not stuck.

Pricing isn’t a one-time bet—it’s a lever you get to design, test, and evolve. But it has to be intentional.

You can’t just copy Stripe’s tiers, slap on “Pro” and “Enterprise,” and call it a day. (Unless your business model is confusion.)

What follows isn’t a pricing formula. It’s a stack of real strategies I’ve seen work—especially for teams building in the wild world of PLG, AI, and open-source. Pick what fits. Combine where it clicks. And if all else fails, at least you’ll have a better plan than “We’ll figure it out after Series A.”

10 Pricing Strategies That Don’t Suck (Even If You’re Open Source, PLG, or Shipping AI Wrappers)

Pricing isn’t just about revenue. It’s positioning. It’s funnel design. It’s survivability. And in the AI era, where copycats move faster than your Notion updates, you need pricing that does more than look good in a pitch deck.

Here are strategies that can actually work—especially for founders juggling open-source traction, PLG growth, and high infra costs.

Let’s go deeper into the first three, because they’re often the deciding factor between “dev love” and “burnout at scale.”

Share this post with a founder or dev team still figuring out their pricing strategy.

1. Infra-Tiered Pricing

💡 TL;DR: Price based on what actually costs you money - tokens, GPU time, API calls, minutes of video generated.

It’s not sexy, but it’s sustainable. You don’t need to explain features - you just need to not go broke.

🔍 What this solves:

• Prevents free users from tanking your infra bill

• Aligns pricing with real usage (and value delivered)

• Lets you be generous without being reckless

🧪 Real Example (OpenAI):

• You get a few dollars of free usage.

• After that? You pay by token, per model tier.

• No confusion. No surprises. Just: use more → pay more.

[OpenAI’s pricing page with GPT-3.5 vs GPT-4 token tiers]

🧠 Pro Tip:

Don’t charge for features. Charge for the output. If your user sends 2M tokens through your orchestrator, that is the moment of value.

2.Feature vs Control Split

💡 TL;DR: Open-source the engine. Monetize the dashboard, monitoring, role controls, alerts—anything a team needs to stay sane.

🔍 What this solves:

• Devs get to explore and use your tool freely

• Teams, companies, and enterprise buyers still have reasons to upgrade

• You don’t have to cripple your OSS to monetize

🧪 Real Example (Langfuse):

• OSS covers core LLM observability logic

• Hosted version adds role-based access, dashboards, team workflows

• Paid tiers kick in for collaboration and scale

Check out Langfuse pricing page showing open-core vs hosted features

🧠 Pro Tip:

Don’t put login buttons behind the paywall—put control behind the paywall. Give usage. Charge for governance.

3. Dev Team vs Org-Based Plans

💡 TL;DR: Not every user is worth the same. Solo devs ≠ startup teams ≠ enterprise security buyers. Don’t price them like they are.

🔍 What this solves:

• Reduces friction for early adoption

• Encourages small team upgrades organically

• Creates logical upgrade moments without sales calls

🧪 Real Example (Replit):

• Solo devs build for free

• Add team features? Need a Pro or Team plan

• Seamless growth from individual → team → org

Screenshot: Replit’s pricing table

🧠 Pro Tip:

Set limits by project, collaborators, or integrations—not just usage. Most users don’t care about tokens, but they do notice when they hit “Add Member” and can’t.

Should I start with a free plan or go premium from day one?

In my experience: if you’re building a technical product—especially in devtools, infra, or AI - you do need to give some stuff away. But not because freemium is trendy. Because awareness is expensive, and distribution is brutal. Free earns you usage. Usage earns you feedback. And feedback earns you credibility.

But here’s the catch: free can’t be forever. And it definitely shouldn’t be everything.

The smartest early-stage teams I’ve worked with treat “free” like a channel, not a pricing model. They make sure what’s free is:

• ✂️ Trimmable later (no core infra costs or entitlements you’ll regret)

• 🎯 Targeted at the right persona (not random tire-kickers)

• 🚪 Directional toward conversion (with natural upgrade moments)

For example: you might give away self-hosted access or a basic agent config builder—but gate the hosted control plane, team collaboration, premium model access, or enterprise integrations.

Think of your free tier as top-of-funnel UX, not a gift. It should earn its keep by qualifying users, teaching them your value, and pointing them toward the plan that actually pays your GPU bill.

Each strategy includes:

🎯 Who it works for

🧪 Detailed real-life use case

📸 Visual example with screenshot prompt

🧠 Includes: Notion pricing planner, AI calculator sheet, OSS monetization matrix, and more.

Read more

Let’s be honest: the hardest part of early-stage marketing isn’t “what channel should I use?”

It’s:

• What the hell do I say?

• Who actually cares?

• And how do I test that yesterday, without sounding like a try-hard on LinkedIn?

I’ve been there — on both sides. As a fractional CMO and growth partner, I’ve worked with early-stage tea…

Read more

Most are just… calendars in disguise.

The startup default is to build a funnel that looks clean on a slide, tracks “awareness → revenue,” and gets updated every Tuesday at 10 a.m.

But ask anyone what it’s actually telling them, and the answers get foggy. Fast.

Because most funnels don’t generate signal.

They just create motion. Meetings. Reports. Activity theater.

Let’s fix that.

Funnels Shouldn’t Be Passive

If your funnel isn’t showing you where trust breaks, where your story fails, or where users stop caring — it’s not doing its job.

The goal isn’t just to convert.

The goal is to expose friction so you can act on it.

A signal-rich funnel gives you:

• A map of drop-off with context

• A way to tie behavior to narrative

• A faster path to alignment between teams (and reality)

Let’s look at what this actually looks like in practice.

Example 1: The Free Trial That Was Lying to You

DevTool startup. Free trials are flowing in.

30% activate. “Not bad.”

Until we start treating the funnel as a signal engine:

• 70% of trials never connect a repo

• 55% open the onboarding email, but don’t click anything

• 80% of successful activations come from just one segment: AI-focused teams

Suddenly the funnel isn’t a static stat — it’s a story:

• We’re overpromising ease-of-use in ads

• Our onboarding email talks about features, not friction

• Our ICP isn’t “developers” — it’s a very specific subset

Same numbers. New lens. Now we’re not reporting — we’re redirecting.

Example 2: The Demo Funnel That Blames the Wrong Thing

Vertical SaaS with an outbound-heavy funnel.

100 demos/month → 30% show → 10% close.

Sounds predictable. But once you peel back the layers:

• 40% of no-shows come from one SDR

• Highest-performing bookings use one specific email template

• SQLs who played with the ROI calculator convert 5x faster

So no — it’s not a “sales problem.”

It’s a misaligned message → asset → handoff problem.

This isn’t about building a better dashboard.

It’s about building a funnel that reflects how people actually buy — and why they bounce when they don’t.

What to Do With This

If you want your funnel to do more than eat budget and spit out KPIs:

• One funnel = one narrative. If it’s not consistent, it’s not useful.

• Label the friction. Don’t just measure drop-off — diagnose the break.

• Kill the vanity stages. No one cares about “MQL to SAL” if nothing actionable lives there.

• Use it to drive conversations. If marketing, product, and sales aren’t seeing the same gaps — the funnel’s a mirror, not a map.

Book your free funnel teardown now

TL;DR

A funnel that doesn’t generate insight isn’t a funnel.

It’s a burn rate with nice formatting.

Coming up next:

Positioning isn’t a tagline.

It’s a decision filter.

See you soon.

“The future is there... looking back at us. Trying to make sense of the fiction we will have become.” — William Gibson

Everyone’s got their hot take on AI.

Most of them are noise.

On one end, there’s the productivity porn: “I built an AI empire in 72 hours using ChatGPT and 14 Chrome extensions.”

On the other, the doomers whispering ab…

Read more

said “Every marketing channel sucks right now.”

And yeah — he’s not wrong. Everyone’s in the same inboxes, fighting over the same tired feeds, remixing the same templates from 2019. Somehow still thinking it’ll break through? That’s delulu, babe.

So the obvious question becomes: What’s left?

And if you’re like me, this is the part where your brain politely suggests “carrier pigeons” or “fax campaigns” - because surely we’ve run out of options, right?

But actually, no.

There’s still leverage hiding in plain sight.

Because while the channels might be loud, formats — the how behind the message — still give you room to play.

Same tools. Same audience. Different outcomes.

• An email doesn’t have to be ignored — it could be a Notion walkthrough someone actually forwards.

• A LinkedIn post doesn’t have to disappear into the scroll — it could be a teardown that gets shared in Slack and sparks demo requests.

• Even a product demo doesn’t have to feel like homework — it could be an instant, no-login tour that does the selling before sales even shows up.

The difference? Not the channel. The format.

And that’s what we’re getting into next:

Real formats that are actually working — and how teams are using them to stand out without chasing whatever platform’s trending this week.

Why Formats Matter More Than Channels

Channels used to be the edge. Being early to LinkedIn, paid social, or even SEO gave you leverage. But now? Everyone’s everywhere. The playing field is flat - and crowded. What used to be a competitive advantage is now just the minimum.

That’s why format matters more. Because how you show up is the only part that’s still uniquely yours. Same post, same inbox, same feed — but a teardown, a behind-the-scenes walkthrough, or a sharp carousel lands very differently than yet another “quick thought” thread.

As puts it, “Products are built to fit with channels. Channels do not mold to products.”

It’s the same with formats. You can’t force attention — you have to earn it with delivery that fits how people actually consume.

Subscribe now

Format-First Plays That Still Win in 2025

Let’s get honest: most marketing formats age like milk — fast, sour, and with a weird aftertaste if you let them sit too long.

But a few? They evolve.

When executed with clarity, speed, and specificity — they cut through the noise and build momentum.

Here’s my take on what’s still working, what’s just getting started, and what’s criminally underused (especially if you’re an AI startup trying to stand out).

Live Founder Teardown Series

Nothing says “trust us with your GTM strategy” like watching someone sweat through a homepage audit on a Tuesday morning Zoom. But somehow, it works. Maybe that’s the point.

Real-time breakdowns of funnels or prompt flows are the new keynotes — punchier, raw, and way more clickable. Bonus points if you fix the mess live, using your own tool. Yes, it’s terrifying. That’s why it lands.

Strategic Partnerships That Actually Multiply

Some of the highest-leverage plays I’ve pulled off didn’t come from new channels — they came from the right partnerships. A well-matched tool, a smartly bundled offer, and a co-hosted session with actual value?

It can feel like a growth cheat code. I’ve seen prompt swaps, AI workflows, and demo bundles outperform entire outbound sequences. But it only works if the alignment is real. That means clear positioning, shared audience logic, and someone (ideally not me) keeping the Notion doc updated.

When it clicks, it scales. Just be ready to juggle landing pages, CTAs, post-webinar follow-ups, and at least one brand team’s “tiny feedback.”

Share

Interactive Embedded Demos

“Book a demo” is the new “check out our whitepaper.” Static, slow, and completely ignorable. Cutting edge startups let you touch the product before you talk to sales. Click-through, no login, straight into the magic.

If you’re not building this, you’re asking people to imagine value. Spoiler: they won’t.

AI-Powered Demo Toolkits

If your product is built on AI and your demo still looks like a 2016 screencast… why? Tools like Arcade are making it embarrassingly easy to storyboard and narrate flows.

If you’re building smart tools, the way you show them should reflect that — or at the very least, show that someone on your team knows how to use them with a bit of imagination.

Reddit Community Formats

Everyone says they’re “community-led” until it’s time to actually show up in the community. Reddit isn’t just for gaming threads and chaos anymore — it’s becoming a high-trust space for bottom-funnel buyers, and it’s indexed by Google andLLMs. If you can’t be helpful there, you probably won’t be helpful in the inbox either.

Creator-Led Micro-Explainers

Influencer marketing for SaaS used to mean 20-minute tech reviews on YouTube with zero emotion. That’s over. Now it’s a 2-minute raw screen-record with commentary like “honestly I didn’t expect this to work.” And somehow, that sells better.

Why? Because creators have what you don’t: trust and reach with a specific community. Borrow both.

Vertical-Niche Content

Here’s a wild idea: talk directly to the exact people you want to sell to. “AI for HR teams with no time to prompt-engineer” beats “AI automation for modern teams” every single time. The deeper you go, the more creative freedom you unlock. Specificity isn’t limiting - it’s liberating.

AI Repurposed Content Kits

I love this one because it saves your team from content burnout and proves you understand distribution. Start with one good piece of thinking, then let AI stretch it across formats: a blog, a carousel, a 45-second clip, a CTA for outbound. That’s not “repurposing.” That’s building leverage.

Prompt Libraries & Mini-Challenges

People don’t believe your AI works until it solves their problem. Prompt libraries give them a head start. Mini-challenges? Even better.

Make it a game: “Can our AI write a better onboarding email than your intern?” Spoiler: yes. But let them discover that on their own.

Build-in-Public Founder Logs

Transparency isn’t a virtue signal. It’s a strategy. Especially in AI, where trust is still earned. I’ve seen founders win loyal early users just by sharing bugs they fixed and prompts that failed. No polish, just presence. Build in public — and people will root for you.

AI-Repurposed Content Kits

This one’s pure leverage. You start with one solid idea — a product insight, a teardown, a hot take — and let AI spin it into multiple formats: a short video, a carousel, a blog draft, maybe even a few cold outbound hooks. I’ve used this to test tone, find traction, and avoid the “one-and-done” trap. It’s not about flooding channels. It’s about giving the same idea more ways to land.

Channels are distribution. Formats are differentiation.

The 5-Part Format Check We Use Before Hitting Publish

(Because vibes aren’t a strategy)

Before anything goes out — a post, a demo, a live session — me and the team give the format a quick gut check. Not in a big process-heavy way, just five fast filters we’ve come to trust.

It helps us catch the difference between “this looks fine” and “this could actually land.”

The goal isn’t to be perfect — it’s to avoid publishing something that relies entirely on the channel doing the heavy lifting. Because channels are noisy. But if the format has a hook, gives people something to do, earns some trust, and delivers a clear payoff? It tends to work harder, longer, and better than we expect.

This check has saved me from approving forgettable work more than once.

And when everything lines up — it’s usually the format, not the channel, that made it win.

⚙️ Format Flywheel Framework

Vibes aren’t a strategy. Before you publish anything — a teardown, a demo, a carousel - you need to know if the format can actually carry the weight.

That’s where this framework comes in.

The Format Flywheel helps you gut-check your creative before it hits send: Is there a hook? Will anyone interact? Does it earn trust? Can it spread? And most importantly — what’s in it for the audience?

When these five layers click, the format pulls its weight. When they don’t, no channel can save you.

Why Format Still Works — Even If Everything Else Is on Fire

I didn’t get into marketing just to run A/B tests and optimize conversion paths. I got into it because I liked the idea that one message — said well, delivered right — could shift how people think, act, or decide. From a small town in Europe, that felt like a kind of superpower.

Years later, not much has changed. Except now, we’re all flooded with content. Everyone’s running the same plays. Every channel feels maxed out.

But format — how we show up — is still where the difference happens.

It’s not just about reach. It’s about resonance.

That’s why format still works. Even now. Especially now.

Leave a comment