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 upstream, from the final edit into the brief, the evidence and the judgment behind the draft. Otherwise, AI scales a company’s output while sanding away the parts that make it recognisable.

I asked some industry experts what becomes more valuable when everyone has access to the same tools. Sean Weisbrot, Founder of SparkVox, put the problem bluntly:

“The biggest problem I see everywhere (including LinkedIn), is that everyone’s voice has been replaced by AI’s and become clones of each other because they’re directly pasting something written by AI.”

That sameness has a commercial cost. Buyers have less to remember, sales inherits fewer distinctive claims to carry into conversations, and outbound becomes even easier to ignore.

This article brings together five expert perspectives on the human advantage, shows where brand-voice tools genuinely help, and gives GTM leaders five practical ways to make AI-assisted content sound like their company.

So, what do the experts say?

Sean identified the symptom: AI-assisted content can erase the voice it is supposed to scale. The other experts pointed to the human inputs that keep a brand recognisable.

Nick Rajadurai, Head of GTM at Expertise AI, sees self-awareness as the starting point:

“I think what matters more now is self-awareness. The edge isn’t the AI generating the message. It’s the person behind it, their style, their thought process, their judgment, even the little quirky jokes that make something feel real. AI can help you produce faster, but it still needs to be fed the right taste and perspective. When everyone has access to the same tools, the advantage goes to the people who bring something distinct into them.”

Andrew Royal, Founder and Principal of Full Stack RevOps, focused on the judgment required when production speeds up:

“While AI has improved workflows, speed of execution, and the ability to get more done in less time, there is one skill that has become increasingly important: critical thinking and an eye to catch mistakes. Getting the perfect response from an AI requires you to balance the speed of delivery with a meticulous, intentional critical eye. Not only is it about prompting the right things, but it also requires questioning the machine.”

Justyna Waciega, B2B marketing strategist, content creator and ghostwriter, brought that judgment back to the brand:

“AI can’t make objective decisions (at least not yet) and it can’t say which option is better or what angle doesn’t work for a specific brand. You need a human expert on the other end that has the final say and that can make a decision based on insights from years in the industry.”

Ina Toncheva, creator of The Irreplaceable Marketer newsletter and a speaker on content marketing in the AI era, adds the ability to make instinctive expertise explicit:

“One skill that becomes super valuable because of AI is the ability to make your instinctive knowledge explicit. To take something you do on autopilot and break it down precisely enough that a machine can follow it. What’s different now is that AI gives you an immediate test: if your breakdown is right, the result will show it. This skill will help people do things that weren’t possible before instead of just doing more of the same.”

Taken together, the experts point to the same division of labour: tools can apply a voice; people have to decide what the brand believes and what deserves to be said.

The experts’ views have a commercial edge. In LinkedIn and Edelman’s 2024 study of nearly 3,500 managers, 75% said thought leadership had led them to research a product or service they had not previously considered, and nine in ten were more receptive to outreach from companies producing consistently strong thought leadership. Yet only 15% rated the thought leadership they consume as very good. Buyers respond to useful thinking; the market simply produces too little of it.

Five tools promise to protect your brand voice. Where do they actually help?

Choose the tool according to where the voice breaks down. Five subscriptions will not give the company five times the personality.

1. Notion and Notion Agent: shared company context

Notion Agent can query a database of approved positioning, customer language, proof and claims before drafting. Use it when the main problem is scattered or outdated context.

2. HubSpot Brand Voice: content produced inside HubSpot

HubSpot’s Brand Voice learns from writing samples and applies the voice to content created in HubSpot. Use it when the website, blogs and marketing emails already live in that ecosystem.

3. Writer: rules across teams and channels

Writer can enforce terminology, style and restricted language across different workflows. Use it when marketing, sales, support and compliance need the same rules.

4. Jasper IQ: brand-grounded marketing generation

Jasper IQ combines brand voice, audience definitions, company knowledge and style rules across Jasper’s content tools and agents. Use it when Jasper is the main marketing-production workspace.

5. Grammarly Brand Tones: guidance wherever people write

Grammarly Brand Tones gives writers real-time feedback against an organisation’s tone profile. Use it when the team needs a lighter editing layer rather than another content-production system.

Opinion: HubSpot, Writer and Jasper overlap. Most B2B teams need one context source, one application or governance layer, and one human-in-the-loop owner. That person approves the source material, new claims and proposed changes to the voice. The five-tool tasting menu is optional.

Five things GTM leaders can do today to make AI content sound like their company

1. Create a voice snapshot. Choose three to five traits and add one approved and one off-brand example for each.

2. Write the constraint list. Record banned phrases, preferred terminology and claims that require evidence.

3. Build one approved context source. Store current positioning, customer language, proof, differentiators and common objections with an owner and review date.

4. Set agent permissions. Decide what agents may read, draft and propose, and which changes require human approval.

5. Run a monthly voice audit. Compare the website, sales deck, outbound and recent content; retire stale claims and return useful buyer language to the context source.

The output is one voice snapshot, one constraint list, one current context source, one permission rule and one review cadence. Together, they create the Alignment Flywheel™ for brand voice: define the context, use it, learn from the market and improve it.

What else to read on this topic

If this raised questions about what AI systems learn from your company’s content, read How to Make ChatGPT Recommend Your Product: A Practical AEO Guide for AI Search Visibility. It covers the other side of the same problem: making your positioning, proof and customer context clear enough for answer engines to understand and recommend the product accurately.

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

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. RAG is not an integration. A gateway is not another version of either. And a CLI is sometimes the most sensible option in the room, which is inconvenient if you were hoping for one tidy acronym to solve the whole thing.

So what the heck is MCP actually? Where does it fit if your team already uses APIs, automation tools, or a CRM with AI features? And when does an agent need MCP, a script, a direct API connection, or simply better context?

In this article, I will explain the practical difference in plain English, show how each layer appears in a real GTM workflow, and give you a way to decide what your team should use without needing to become the person who maintains the Python script.

What you will learn

• What MCP, APIs, SDKs, CLIs, RAG, and gateways actually do in an agentic GTM workflow - without the engineering theatre.

• How to choose the right interface for exploratory research, repeatable batches, and deployed production workflows.

• Which security and human-approval decisions need to exist before an agent can take action in a CRM, outreach system, or data environment.

• Where direct APIs win on cost, volume, reliability, and repeatability.

What is what: MCP, APIs, SDKs, CLIs, RAG, and gateways

They are complementary layers that serve different jobs in the same workflow. A single GTM workflow might use RAG to provide approved account context, MCP to help an agent find the relevant tools, an API to execute a known CRM update, an SDK or CLI to run a recurring batch, and a gateway to control the whole route.

Here is what each one actually does.

What is an API?

An API, or application programming interface, is a defined way for one piece of software to request data or trigger an action in another. It can fetch an account record from Salesforce, create a contact in HubSpot, send an email through a sequencing platform, or pull campaign performance from an ad platform.

Use an API when the job is already clear. The workflow knows which action to take, what information to send, and which permissions it has. APIs are the reliable execution layer beneath many SDKs, workflow automations, and MCP servers. They leave the choice of what to do next to a developer, a rules-based workflow, or an agent.

What is MCP?

MCP, or Model Context Protocol, gives an AI application a standard way to connect to tools, data, and instructions. It helps the agent see the capabilities it has access to, understand what they can do, and use an approved one while it works through a task.

Use MCP when the agent needs to investigate, weigh up options, and choose its next step with a human still in the loop. Account research, CRM-quality checks, enrichment-source selection, and campaign preparation all fit that shape. MCP commonly connects an agent to APIs, databases, and command-line tools. The quality of the agent’s decisions still depends on the context it receives, the permissions it has, and the approval rules around it.

What is an SDK?

An SDK, or software development kit, is a package of ready-made code for working with a service. Instead of writing every API request from scratch, a developer can use the SDK’s functions to authenticate, send data, handle errors, and get a result in Python, JavaScript, or another language.

An SDK earns its keep once a GTM task has stopped being an experiment. Think weekly enrichment, product-signal syncs, or scheduled lead scoring. The workflow is known, needs to run the same way every time, and needs someone to own the code when it breaks. MCP is more useful earlier, when an agent still needs to explore the context and decide which tool to use.

What is a CLI?

A CLI, or command-line interface, lets a person or script interact with a system by running commands in a terminal. It is a direct, practical way to test an operation, manage files, run a data job, or automate a task that has clear inputs and outputs.

Use a CLI when the command is known and the team needs the same thing to happen predictably every time. It is often a good fit for local scripts, scheduled jobs, and operational tasks that can be written, reviewed, and rerun. A CLI can sit behind an approved agent tool or an MCP server, but it relies on the person, script, or agent having already chosen the right command.

What is RAG?

RAG, or retrieval-augmented generation, is a way to give an AI model the relevant information it needs at the moment of work. It pulls from approved documents, product information, account notes, call transcripts, or playbooks and adds the most useful material to the model’s context.

Use RAG when an agent needs current, grounded knowledge to write a brief, explain positioning, or understand account history. It works alongside MCP, APIs, and CLIs: RAG helps the agent understand the situation, while the other layers can help it find more information or take an approved action. Its quality depends on the source material, retrieval logic, and permission model, so a neglected knowledge base will still produce a neglected answer.

What is an AI or MCP gateway?

An AI or MCP gateway is the control layer between an AI application and the systems it can access. It can route requests, manage authentication and secrets, enforce policies, limit usage, create logs, and require read-only access or human approval before a write.

Use a gateway when several agents, services, teams, or sensitive systems share the same environment. It works across the other layers: an API still performs the action, an MCP server can still expose the tool, and RAG can still supply the context. The gateway sets the guardrails and records what happened; it does not replace the underlying systems or make a weak workflow sensible.

The shortest useful version: APIs and CLIs carry out specific operations; SDKs make APIs easier to build with; RAG provides relevant context; MCP helps an AI application discover and use capabilities; and gateways govern access along the way.

If you lead sales, remember this: use MCP when an agent needs to explore and help a rep decide. Use RAG to give it the right customer and company context. Use an API or workflow once the job is known and needs to happen reliably at scale. Keep a human involved whenever the action affects a prospect, customer, forecast, or revenue record.

That distinction turns “we need MCP” into an operating question: where does this GTM workflow need context, tool discovery, repeatable execution, or tighter control?

What does MCP add beyond an API or OpenAPI specification?

The question is who knows the next step. With a direct API integration, the developer or rules-based workflow already knows. It sends a precise instruction such as “create this contact in the CRM” or “pull activity from this account.”

MCP earns its place when the agent needs to work through the task first. It can look at the tools available to it, read relevant context, ask for missing information, and choose an approved action. The underlying API may still do the actual work; MCP gives the agent a more usable way to find and use that capability.

OpenAPI documentation is useful when a developer is building an integration because it describes the available API calls. MCP brings a similar map into an agent environment, where the model needs to discover and use approved tools as part of its work. For technical readers: the host, client, and server are the plumbing that makes this discovery and tool use happen.

When APIs win - and what MCP can cost

When a direct API wins

MCP is useful when an agent needs to investigate, interpret context, and work out the next step. A direct API wins once the team already knows exactly what should happen.

Use a direct API when the workflow runs at high volume, needs predictable speed, has fixed business logic, or creates a consequential change in a system. Syncing product usage every hour, routing leads with defined rules, updating approved CRM fields, and running recurring enrichment across thousands of accounts all fit this shape.

At that point, asking an agent to reason through every step is expensive theatre. Put the proven logic into a workflow with ownership, logs, retries, and a clear failure path.

Does MCP use more credits than a direct API?

Usually, an agent using MCP will consume more model tokens than a direct API workflow completing the same known task. The model needs to understand the available tools, decide which one to use, send a call, read the result, and sometimes take another step. Anthropic’s token-counting documentation includes tool definitions in the input it counts.

That does not make MCP inefficient. It means you are paying for exploration and judgment. A direct API workflow is cheaper when the judgment has already happened and the task is ready to execute repeatedly.

One nuance matters: an API called by an agent still uses model tokens for the agent’s reasoning and tool calls. The real comparison is not “MCP versus API cost.” It is “agent-led exploration versus a known workflow running reliably in production.”

Practical GTM use cases: where each layer earns its place

These examples matter more than a taxonomy. Notice the job first, then the layer that makes the job reliable.

Practical use case: turn a territory list into targeted micro-campaigns

A Zendesk SMB AE showed this Sumble-and-Claude workflow. He uploaded a territory list and asked the agent to identify accounts using call-centre technology, then locate senior contacts and prepare small, tailored campaign batches.

MCP made the enrichment capability available inside the agent’s working context. The rep could investigate a narrow segment, decide whether the signal mattered, and use the resulting context to shape outreach. This is where MCP earns its place: exploratory work with incomplete information and a human still making the commercial judgment.

Practical use case: turn a prospect screenshot into a usable CRM record

Clarify demonstrated a workflow that takes a screenshot of a prospect conversation, extracts the deal details, and creates the company, person, and deal records in the CRM.

The CRM actions are still conventional system operations, likely exposed through APIs. MCP brings the interpretation and the action together in one agent workflow, so the rep does not have to manually move information from an unstructured conversation into a dozen fields.

Practical use case: move a recurring data request out of chat

A GTM Systems Engineer at Nooks documented this progression: Claude first matched two CSVs for an ad hoc Finance request. Once the same question kept returning, the team moved the data into a warehouse, set scheduled ETL jobs, and exposed repeatable queries.

The first step was exploratory; the later system needed reliable data refreshes, known logic, and a home outside a chat session. This is where an SDK, CLI, or direct API workflow becomes the better fit than an agent-led task.

Practical use case: keep the context behind account plans current

WorkSpan’s operator example started with product, persona, competitor, and proof-point context scattered across AI experiments, then found it went stale quickly. The team used an MCP-connected context layer to update those shared objects after product and positioning changes, so the same current information could inform account plans, onboarding, reporting, and prospecting.

RAG or a comparable retrieval layer supplies the right material at the moment of work. MCP gives the agent a consistent route to the systems that hold and update that context.

What I have learned from using MCPs and APIs every day

I use both MCPs and direct APIs almost every day, and I choose based on the job rather than the acronym. MCP is better when the task starts with ambiguity: look across a few systems, work out what matters, and help me decide the next step. A direct API or repeatable workflow is faster when I already know the action, need it to run reliably, or do not want an agent burning credits while it rediscovers the same answer.

The connector quality matters too. Some MCPs are genuinely useful; others are slow, token-heavy, or weaker than using the underlying tool another way. Canva’s MCP, for example, has not been reliable enough for my own workflow.

My practical workaround is to keep secure API access in macOS Keychain and save the reliable MCP and API routes in local skills: what the agent can use, when each route is cheaper or faster, and when it needs to ask for approval. That way, the agent can choose the useful path without turning every task into a fresh technical experiment.

The MCPs getting the most GTM attention - and where they actually help

The market is producing a lot of MCP announcements, which is lovely for conference slides and less helpful when you are trying to decide what to connect first. Recent GTM-focused roundups cluster around the categories below, although they are vendor perspectives rather than an independent ranking: Databar’s overview and Amplemarket’s sales comparison.

This is a July 2026 market snapshot. Connector support, pricing, permissions, and maturity change quickly.

Start with the work your team does often, where the context is already valuable, and where a wrong action will not create a small crisis in your CRM.

1. Workspace and knowledge MCPs

Examples: Gmail, Google Calendar, Notion, Google Drive, and Slack.

These are becoming the default starting point because they help an agent understand the day-to-day work around a deal: meeting history, open threads, account notes, positioning documents, and next commitments. For a sales leader, that can mean better pre-call preparation, more useful follow-up drafts, and fewer “I did not see that Slack thread” moments.

2. CRM MCPs

Examples: HubSpot, Salesforce, Attio, and Clarify.

CRM MCPs give an agent access to account history, contacts, pipeline stages, activity, and deal context. Start with read-only access. Let the agent find gaps, summarise context, and recommend an update before it earns permission to change a record.

3. Prospecting and enrichment MCPs

Examples: Clay, Apollo, Amplemarket, Sumble, and Explorium.

This category turns an agent into a more useful research partner. It can identify accounts that match a signal, find relevant contacts, enrich a list, and prepare a small campaign around the reason the account matters now.

The practical use is finding a narrow, commercially useful segment and giving a rep a better reason to start a conversation. Enriching the entire database because the connector exists is an expensive hobby.

4. Product, revenue, and web-analytics MCPs

Examples: PostHog, Google Analytics, Stripe, and data-warehouse or BI connectors.

These matter most for PLG, hybrid, and usage-led GTM teams. They help a seller or customer-success leader connect account activity to product usage, marketing performance, expansion signals, or churn risk without waiting for someone to build a report.

The caveat is definition quality. An agent can retrieve data quickly; it still needs agreed definitions of an activated account, a meaningful usage signal, or a qualified opportunity.

5. Conversation-intelligence MCPs

Examples: Gong, Grain, Granola, and Attention.

Call recordings become more useful when the agent can connect them to the CRM, email history, calendar, and approved messaging. The goal is not another meeting summary. It is a better follow-up, a clearer next step, and a view of which objections or buying signals are showing up across the pipeline.

6. Content and growth MCPs

Examples: Ahrefs, Canva, Alai, research, and web-search connectors.

Marketing teams are using these for keyword research, content briefs, competitive analysis, reporting, and repeatable sales or marketing assets from existing company context. They become especially useful once the team has a maintained positioning and proof-point library for the agent to work from.

What to connect later

Outreach sending, broad CRM write access, billing, and production automation can create value, but they also create consequences. Connect them once the team has a proven workflow, an owner, clear permissions, and a human approval step where it matters.

The best first MCP is rarely the flashiest one. It is the one that helps your team make a better decision in work they already do every week.

How to choose the right layer: explore → repeat → deploy

Use this as the practical decision model:

• Explore with MCP: Interactive, context-dependent work with a human present, such as account research, data-source evaluation, or a one-off CRM audit.

• Repeat with an SDK or CLI: A known workflow that needs consistent inputs, retries, logs, and reproducible outputs, such as enrichment or account scoring for a campaign.

• Deploy with a direct API: A continuous, high-consequence, or business-critical workflow that runs outside an agent session.

• Use RAG across each stage: Supply approved positioning, customer evidence, and exclusions before the agent reasons or acts.

• Use a gateway across each stage: Apply routing, permissions, policy, and logs.

The useful pattern is to let a workflow earn its way into production. MCP helps an operator test whether the data and decision rule are genuinely useful. Once both are clear, the repeatable portion usually belongs in a controlled batch or direct integration.

Is MCP security the same as API security?

The starting controls are familiar: authentication, authorization, encrypted transport, input validation, rate limits, least-privilege access, and logs. Those matter whether the caller is a conventional application, a workflow, or an agent.

MCP introduces an additional decision and context boundary. An agent may encounter instructions in retrieved content, choose between several tools, carry delegated credentials, or act on incomplete context. Teams therefore need to consider prompt injection, misleading tool descriptions, excessive scope, and the consequences of a wrong but technically valid action.

The practical security question is whether the agent has been given more freedom than the workflow can safely tolerate. Start read-only. Separate the ability to research from the ability to write. Require explicit approval before external-facing actions, and make sure the team can reconstruct which tool was called, with what inputs, and why.

Practical use case: let an agent inspect pipeline without edit access

MintMCP described an Attio connector configured for read-only deal access. An agent could inspect pipeline data but could not update records.

That is a useful starting boundary: give the team evidence that an agent can reason over the right data before granting it permission to change that data.

What GTM leaders should do next

1. Find one place where reps lose judgment time

Start with account research, post-call follow-up, CRM hygiene, or planning a first outreach angle. These are good places to begin because the agent can help a rep prepare better before it is trusted to change a record or send a message.

2. Decide what the agent may read, recommend, and do

Make the boundary explicit. An agent may read CRM history and call notes, recommend next steps, and prepare a draft, while a rep approves anything that reaches a prospect or changes a forecast.

3. Give the agent the context your best reps already use

Current positioning, customer proof, competitor context, account history, and the language buyers actually use will improve output more than another connector. The goal is to give the agent the same starting material a good rep would ask for before a meeting.

4. Choose one success signal before expanding

Measure preparation time, CRM completeness, follow-up quality, or meetings created. If the workflow does not improve one of these, wider access will only make the existing mess move faster.

5. Ask RevOps or engineering for the safest implementation path

The GTM leader owns the commercial problem, quality bar, and approval boundary. RevOps and engineering can decide whether the safest path uses MCP, an API, an automation, or a script.

Common questions from GTM teams

Does MCP replace APIs?

MCP usually sits on top of existing APIs, databases, or command-line actions. It gives an AI application a standard way to discover and invoke those capabilities.

The underlying system still needs an API, query, or command that actually reads or changes data. MCP makes that capability easier for an agent to find and use in the right moment.

MCP vs CLI: when is a command-line workflow better?

A CLI wins when the job is known, repeatable, and needs predictable execution: run a data export, validate a file, refresh a table, or trigger a scheduled script. It is especially useful when a person or workflow already knows the exact command to run.

MCP is more useful when an agent needs to inspect context and choose from several possible tools before acting. A CLI may still sit behind that agent workflow once the right command has been chosen.

MCP vs RAG: what is the difference between context and action?

RAG retrieves relevant knowledge so the model can reason from current positioning, account history, product details, or approved proof. MCP exposes tools and resources so the model can look up more information or act on the conclusion.

A solid GTM agent often needs both: RAG to understand what it should say, MCP to find or use the relevant system capability.

What is an MCP gateway?

An MCP gateway is a control point for access to MCP servers and other agent connections. It can centralise authentication, secrets, policies, rate limits, logs, and approval rules.

It does not provide the CRM action or the agent’s reasoning. It decides which routes are permitted and gives the team visibility into how those routes were used.

MCP vs API in Python: does the language decide the architecture?

Python is an implementation choice, not the architecture decision. A Python script can call a direct API, use an SDK, run a CLI command, host an MCP server, or support a retrieval workflow.

The right option depends on who or what is consuming the workflow, how repeatable it is, the consequence of failure, and the required controls.

Before you connect the next tool

The useful question is not whether your team has adopted MCP. It is whether the workflow needs exploration, reliable execution, better context, or a decision that should remain human. Once that is clear, the connector choice becomes far less mystical and much more useful.

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

Connect on LinkedIN

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 jacket.

The question is whether ChatGPT mentioned your product while your buyer was researching, or sent them to the competitor your team still describes as “not really in our space.”

With that in mind, AI is now a serious part of the conversation before the website visit: it helps buyers form a category, assemble a shortlist and decide which claims sound credible enough to investigate.

(Your product page and sales team do matter, but they enter the picture after the first version of your company has already been created.)

What is Answer Engine Optimization (AEO)? It’s a practice of making it easy for AI assistants to understand, trust, and recommend your company and product.

It involves creating clear positioning, direct answers to common questions, credible third-party evidence, and technically accessible content so AI models have reliable information to draw from. Instead of improvising your story, answer engines can accurately explain why your product fits a buyer’s specific situation.

Does website remain important? Yes, but it is only one input. Answer engines assemble their “view” from a variety of sources: product content, customer stories, reviews, partner pages, industry coverage and the old category description someone published three years ago and never corrected.

That’s why AEO sits across product marketing, SEO, customer marketing, PR and RevOps.

A 2025 generative-search study found that source selection changed by engine, language and prompt. In its US consumer-electronics sample, earned media represented 92.1% of cited sources. It is not a B2B study, but the underlying lesson travels: the market needs more evidence than a well-optimized product page before it can confidently repeat your story.

What you’ll learn

• How to assess how ChatGPT, Perplexity and Gemini currently describe and recommend your product

• How to find the positioning, evidence, content and technical gaps behind weak AI visibility

• How to turn that diagnosis into an agent-assisted AEO workflow with clear owners and measurable GTM outcomes

How to track your visibility in ChatGPT and AI search

Before building your AEO strategy, you need to see the version of your company AI is already giving buyers.

This section is a practical starting playbook: the questions to test, the signals to track and the tools to use when a spreadsheet stops being enough. It helps you turn “we are not visible in ChatGPT” into a specific problem with a clear owner and next step.

Start with buyer questions

Start with 20 buyer questions from sales calls, CRM notes and competitive deals. Run the same questions across ChatGPT, Perplexity and Gemini every month. (You’re looking for recurring patterns in how AI describes and recommends you.)

Track four signals:

• Mention coverage: how often your product appears

• Positioning accuracy: whether AI describes your category, customers and capabilities correctly

• Competitor context: which alternatives appear beside you

• Citation sources: which websites support the recommendation

Use a tool if you want to automate or scale

Add a monitoring platform when the volume of prompts, competitors and cited sources makes a manual review unreliable.

I’d recommend:

• Semrush One or Ahrefs Brand Radar - if your team already uses that SEO suite and wants AI visibility alongside existing search data

• Peec AI for focused tracking of prompts, mentions, positioning, sentiment and citations

• Profound for enterprise programs that need prompt-volume research, source analysis and broader AI-agent monitoring

Tip: these platforms overlap, so choose one based on your current stack and reporting requirements.

Turn the results into a prioritized list of buyer questions, claims to prove and sources to fix. That list becomes the starting point for the AEO strategy in the next section.

Six practical ways to increase AI search visibility

Once you know how AI describes your product, which competitors it places beside you and what sources it cites, you have the shopping list.

Now you can stop throwing more content into the pot and fix what is actually missing: clearer pages, stronger evidence and market proof that makes your positioning easier to repeat.

1. Build authority around topics connected to revenue

Cover the category, problems, use cases, integrations, implementation questions and alternatives that influence real buying decisions. Then go deeper by answering the follow-up questions buyers ask during evaluation.

Unrelated traffic content creates inventory faster than authority. Start with questions from sales calls, competitive deals and customer interviews before expanding the topic map with keyword data.

2. Publish at a pace you can maintain

Consistent publishing gives answer engines more current evidence, but every new page creates a maintenance obligation.

Set a publishing cadence alongside a refresh cadence. A smaller collection of accurate, commercially relevant pages will usually be more useful than a large library of generic comparisons and AI-generated listicles. Publishing velocity without maintenance becomes content debt with better reporting.

3. Make important pages easy to extract and cite

Give the direct answer early. Use headings that reflect real buyer questions, focused sections, comparison tables where they help and links to supporting evidence.

Length alone does not create more citations. Each section should answer one clear question and remain understandable when an answer engine retrieves it without the surrounding article.

That is a useful AEO rule: machine-readable content helps when it carries distinct positioning and credible proof. If every company publishes the same AI-smoothed explanation, answer engines get more content and very little reason to recommend one brand over another.

4. Remove technical barriers

(A bit of good old SEO, I know)

Check whether important pages are crawlable, indexed, internally linked and represented correctly in your sitemap. Review robots.txt, canonical tags, URL structure and structured data.

Treat llms.txt and AI information pages as optional experiments, not substitutes for basic technical hygiene. A beautifully formatted AI information file will have limited value when the useful product evidence remains blocked, duplicated or buried.

5. Refresh content based on signals

Monitor product changes, outdated statistics, declining citations, changing competitors and pages that no longer match buyer intent.

Classify each page as requiring a light refresh, a substantial update or a complete rewrite. An agent can flag likely candidates and draft changes, but a human owner should verify the claims and decide whether the page still deserves to exist.

6. Manage how the market describes your brand

Your website is only one source (The market, inconveniently, has its own version of your company.)

Reviews, customer stories, partner pages, credible media, communities and comparison content all influence how AI understands your category and reputation.

Owned channels explain your positioning, while independent sources verify it. Track both, respond to inaccurate market descriptions transparently and avoid manufactured community promotion. AI systems are quite capable of indexing bad judgment at scale.

These six approaches should produce a prioritized list of evidence gaps, each connected to a buyer question, source, owner and measurable signal.

Pro tip: build your AEO strategy around buyer questions

Why start AEO research from a blank prompt when buyers have been telling your sales team exactly what they need to understand before they shortlist you?

Sales calls, CRM notes and lost-deal reviews already contain the homework; the market has done its part, which is more than we can say for most content calendars. Start with one question: Which commercially important claims can the market verify about us today?

E.g. your buyer asks:

Which AI sales assistant works for a 50-person B2B SaaS company using HubSpot and requiring EU data compliance?

To recommend your product, an answer engine needs evidence that it fits the company size, integrates with HubSpot, supports the required use case and meets the compliance requirement. A generic page describing it as an “AI sales assistant” will not provide enough proof.

Turn each priority buyer question into one working record:

Buyer prompt: AI sales assistant for a 50-person EU SaaS company using HubSpot
Approved claim: Fits the team size, integrates with HubSpot and supports EU data requirements
Current evidence: Product page and integration page
Evidence gap: Independent customer proof
Owner: Customer marketing
Commercial signal: Qualified AI referral or self-reported discovery

The record forces the team to decide what it wants AI to understand, where that claim can be verified and who can close the gap. It also prevents a visibility problem from automatically becoming a content request.

An agent can compare the monitored answer with approved positioning and evidence. Keep the prompt constrained:

Compare the AI response with our approved positioning and verified claims.
Return:
1. Any inaccurate or missing claim
2. The evidence currently available for that claim
3. The gap type: positioning, content, proof, technical or distribution
4. The recommended owner and next action
Do not invent claims, customer evidence or sources.

Product marketing should review the output and route each gap to content and SEO, customer marketing, PR, partnerships, engineering or RevOps. The agent can extract, compare, classify and create the task. A human owner remains responsible for the claim, evidence and publication decision.

Rerun the same prompt after the fix and record whether the description, recommendation and cited sources changed. The output should be a decision queue for the monthly GTM review, not another content-idea backlog.

Give AEO one owner and measure business impact

Once you have done the research, mapped the citations and set the workflow in motion, somebody needs to own the whole thing. (Otherwise it becomes one of those cross-functional projects everyone agrees is important, right up to the point someone has to update a page or ask a customer for proof.)

My view: product marketing should run the cadence. SEO makes the evidence discoverable, Sales brings the real buyer questions, customer marketing and PR add independent proof, and RevOps connects the work to pipeline.

Product marketing owns whether those pieces produce one accurate market story rather than five departments each describing a slightly different company.

Then keep the reporting practical. Are the priority buyer prompts more accurate? Are credible sources supporting the answer? Are AI-discovered buyers becoming qualified opportunities? Raw referral traffic is useful context, but it has a habit of arriving at the meeting dressed as proof.

Your first 30 days of AEO

1. Choose one revenue-relevant prompt cluster. Focus on a category, use case, integration, migration or compliance question that already appears in active deals.

2. Capture the baseline. Record how AI describes your product, which competitors it recommends and which sources it cites.

3. Fix one evidence gap. Improve the positioning, product content, customer proof, technical access or third-party validation behind the answer.

4. Rerun the same prompts after 30 days. Compare the description, recommendation coverage, citations and qualified buyer response.

At the end of the first cycle, your team should know whether AI understands the product more accurately, whether stronger sources are shaping the answer and whether qualified buyers are finding you through AI search.

Dashboard growth only matters when it leads to a concrete GTM decision. That is the standard I would use for AEO: clearer market understanding, stronger evidence and a measurable path from AI visibility to qualified demand.

About me

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

Request GTM Audit

→ 360° assessment + 6-month action plan: Your GTM blindspots revealed

Book a call

Or

Connect on LinkedIN

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 of timing, and which contacts already have a relationship with the business. The problem is that these signals arrive across different systems and rarely become coordinated action.

Outbound still pays the bills for many companies, but the version that works increasingly depends on timing and context. Buyers have developed a reasonable allergy to generic AI outreach, while messages connected to an actual relationship, business change, or demonstrated interest still have a credible reason to exist. Warm outbound now includes far more than referrals and introductions; it can begin with any reliable signal that gives the account a reason to care and the seller a reason to reach out.

A relatively advanced workflow used to mean detecting a signal, enriching the account in Clay, generating an AI-written email, and adding the contact to a sequence. In 2026, agents can monitor signals continuously, retrieve CRM, conversation, website, and relationship context, recommend an action, route it to the appropriate owner, and write the outcome back into the system.

This creates a practical opening for RevOps. The seven plays that follow apply this logic across relationship activation, champion tracking, LinkedIn engagement, focused outbound campaigns, website intent, account briefing, and dormant opportunities. The goal is to turn existing signals into better commercial decisions and conversations without treating every new data point as permission to send another automated message.

What You Will Learn

This article shows how to design seven practical AI agents for RevOps, with the trigger, context, human review point, action, and tool chain required for each workflow.

- Seven workflows covering existing relationships, customer champions, LinkedIn signals, focused outbound campaigns, website intent, account briefing, and dormant opportunities.

- How to determine what the agent should monitor, what it should prepare or execute, and where a human must make the commercial decision.

- How to build a clean tool chain with one primary platform responsible for each function.

- How to test one play manually, record the outcome in the CRM, and decide whether the workflow is ready for automation.

Play 1: Relationship Signal Engine-

GTM teams reach for another cold list surprisingly often while warm contacts sit quietly across the CRM, LinkedIn network, and opportunity history.

Main purpose: An agent turns your existing relationships into a prioritized pipeline queue.

The workflow begins with customers, former customers, LinkedIn connections, proposal recipients, event contacts, referrals, and previous sales conversations. The agent cleans the records, enriches current roles and companies, and scores each relationship using ICP fit, history, seniority, engagement, and timing.

When a contact crosses the scoring threshold, the agent retrieves the relevant CRM notes and relationship history, then prepares a short context brief and recommends the next step. Tier 1 relationships route to the founder or an executive for a personal message. Sales can handle lower-risk contacts, while weak or sensitive opportunities remain in nurture.

Use case: One founder-led company had approximately 6,000 LinkedIn contacts alongside years of CRM and BDR activity. The first activation pass reduced that network to 300–400 relevant contacts, then identified which relationships justified a founder note, sales follow-up, referral request, or no outreach.

The key shift: Relationship history becomes a continuously updated pipeline asset rather than a contact database reviewed whenever cold outbound starts underperforming.

Tool chain: CRM or contact database → LinkedIn export or relationship data → Clay (or Apollo (cleanup and enrichment) → Claude or another LLM (scoring, context briefs, and draft preparation) → Slack or Notion (human review) → sales engagement platform or direct founder outreach → CRM writeback.

Play 2: Champion Tracking and Customer Alumni Graph

A former champion changing jobs creates a warm path into a new account, yet many teams reduce that relationship to an automated “congratulations on the new role” email followed by a meeting request with all the subtlety of airport lighting.

Main purpose: An agent tracks where champions and customer alumni move, then identifies when their new company creates a credible opportunity.

The trigger is a verified job change into an ICP-fit company, ideally combined with another relevant signal such as new funding, team expansion, a strategic initiative, or hiring around the problem your product solves.

When the trigger fires, the agent retrieves the previous relationship, the contact’s role in the original deal, the problems they cared about, and the internal owner who knows them best. It enriches the new company, evaluates the commercial fit, and recommends a personal congratulations, a relationship-led reconnection, an executive introduction, or quiet monitoring.

Example: A former customer champion joins an ICP-fit company that is hiring RevOps and automation roles. The agent connects the job change with the champion’s previous use case, prepares a short account brief, and routes it to the original relationship owner. The human decides whether the moment deserves a conversation or simply a thoughtful note with no ask attached.

The key shift: Champion tracking becomes relationship intelligence rather than a job-change alert with an email sequence attached.

Tool chain: CRM and customer records → UserGems, Champify, LoneScale, LinkedIn, or another job-change source → Clay (company enrichment and ICP scoring) → The Swarm or relationship graph tooling (relationship paths and ownership) → Claude or another LLM (context brief and recommended action) → Slack or Notion (human review) → direct outreach or sales engagement platform → CRM writeback.

Play 3: LinkedIn Signal-to-Conversation Engine

LinkedIn contains live commercial signals across job changes, posts, comments, company announcements, shared relationships, and profile updates, yet most teams use it as either a content channel or a place for sellers to browse without recording what they find.

Main purpose: An agent turns relevant LinkedIn activity into prioritized engagement and relationship-building actions.

The trigger can be a champion starting a new role, a target buyer posting about a relevant problem, an ICP account announcing a strategic change, a prospect engaging with company content, or a mutual relationship creating a warmer path. The agent compares that activity with CRM history, account fit, relationship strength, and opportunity context before recommending an action.

Depending on the signal, the next step might be a thoughtful comment, a connection request, a direct message, a founder note, a referral request, or quiet monitoring. The human decides whether the relationship and timing justify engagement because not every LinkedIn notification needs to become an outbound event.

For the connection-request step, I built the Signal-Led LinkedIn Icebreaker Copilot. The Chrome extension scans visible profile signals and produces a draft icebreaker in a few seconds. The seller adds the context the profile cannot provide, edits the note, and decides whether to send it.

Use case: A former prospect moves into an ICP-fit company and begins posting about rebuilding its revenue workflows. The agent connects the job change and LinkedIn activity with the previous CRM relationship, then alerts the original account owner. The owner reviews the profile, decides that a connection request is appropriate, and uses the Copilot to prepare the first draft.

The key shift: LinkedIn becomes a relationship and buying-signal layer connected to CRM context and deliberate next actions, rather than an isolated feed where useful commercial information disappears by lunchtime.

Tool chain: CRM or relationship tracker → LinkedIn or Sales Navigator (profile and activity signals) → signal scoring and action recommendation → Signal-Led LinkedIn Icebreaker Copilot (connection-note drafting) → human engagement or outreach → CRM writeback.

Play 4: Signal-to-Segment Campaign Engine

Most outbound campaigns begin with a list and search for a reason to contact it later. Signal-triggered micro-campaigns reverse that sequence by starting with a specific change in the account.

Main purpose: An agent turns a narrow cluster of buying signals into a small, testable outbound campaign.

The trigger might combine a relevant hiring pattern, technology change, funding event, competitor complaint, website activity, or engagement with category content. The agent waits until enough evidence supports a clear timing hypothesis rather than treating every isolated signal as an invitation to launch another sequence.

When the threshold is reached, the agent identifies matching accounts, enriches the relevant contacts, retrieves existing CRM context, and prepares account briefs and message drafts. A human reviews the hypothesis, audience, and messaging before activation, while responses and opportunity outcomes return to the CRM for comparison by signal type.

Use case: A B2B company identifies accounts hiring RevOps and GTM engineering roles while adopting tools associated with revenue workflow redesign. The agent builds a small account list, finds the relevant operations leaders, and prepares outreach connected to the hiring and technology signals. The campaign launches only after RevOps confirms that the segment and timing hypothesis are commercially credible.

The key shift: Outbound begins with a testable reason the account may care now, rather than a large contact list waiting to be seasoned with generic personalization.

Tool chain: CRM → Sumble (company and market signals) → Clay (enrichment and orchestration) → Claude (account briefs and message drafts) → Slack (human review) → existing sales engagement platform → CRM writeback.

Play 5: Website Intent Routing Engine

Website intent becomes alert theater when every visitor is treated as a lead and every pricing-page view is delivered to sales with the urgency of a small electrical fire.

Main purpose: An agent determines which website activity deserves sales action, marketing nurture, customer follow-up, or no response.

The trigger combines account fit with meaningful behavior: repeat visits, pricing or comparison-page activity, content engagement, an existing CRM relationship, product usage, or multiple people from the same company appearing within a short period. A single blog visit should rarely be enough.

When the threshold is reached, the agent identifies the account, retrieves its CRM history and ownership, evaluates the pages and signals involved, and recommends the appropriate route. High-value accounts can trigger a brief and Slack review for the account owner, while lower-intent visitors enter nurture or remain unassigned.

Use case: An ICP-fit company visits the pricing and implementation pages several times while a known contact engages with an integration guide. The agent confirms that there is no active opportunity, prepares a short account brief, and routes it to the appropriate seller. The human decides whether the combined activity supports direct outreach or whether marketing should continue nurturing the account.

The key shift: Website activity becomes an input for account-level routing rather than a stream of isolated alerts that sales eventually learns to ignore.

Tool chain: CRM → Common Room (visitor identification, signal aggregation, and account scoring) → Slack (human review and routing) → existing sales engagement or marketing automation platform → CRM writeback.

Play 6: Account Context Briefing Engine

Account research becomes expensive when every seller reconstructs the same company history across CRM records, call transcripts, emails, and browser tabs before an important conversation.

Main purpose: An agent assembles the account history and current context required for a useful commercial conversation.

The trigger can be an upcoming executive meeting, account handoff, deal-stage change, renewal review, or new activity from a Tier 1 account. The agent retrieves previous calls and emails, CRM notes, stakeholders, objections, commitments, deal risks, and relevant company developments.

It turns that context into a concise brief covering why the account matters, what has changed, which priorities and objections have already surfaced, which proof points are relevant, and what the seller should ask next. The account owner reviews the brief before relying on its recommendations because a polished summary can still reach the wrong conclusion with excellent formatting.

Use case: A sales leader is joining an executive meeting with an account that has already completed several discovery calls. The agent summarizes the previous conversations, identifies an unresolved implementation concern, highlights a recent leadership change, and recommends questions for the meeting. The original account owner reviews the brief and corrects any assumptions before it is shared.

The key shift: Account research becomes cumulative and event-triggered rather than being rebuilt manually before every important interaction.

Tool chain: CRM trigger → Gong AI Briefer (conversation, email, CRM, and web context) → email or Gong workspace (delivery and human review) → CRM next-step writeback.

Play 7: Re-Engagement Signal Engine

Closed-lost opportunities often become CRM archaeology, even though the reason a deal died is one of the strongest signals for knowing when to reopen it.

Main purpose: An agent monitors dormant opportunities and identifies when the original buying context has changed enough to justify another conversation.

The trigger is a cluster of re-engagement signals: new leadership, funding, hiring around the relevant problem, renewed website activity, competitor dissatisfaction, a product launch, or an integration that resolves the original objection.

When enough signals stack, the agent retrieves the closed-lost reason, CRM notes, previous emails, and the relevant Gong transcript. It identifies the objection that stopped the deal, compares it with what has changed, and prepares outreach grounded in the previous conversation. Tier 1 accounts route to the original rep or an executive for review, while lower-risk opportunities can enter an approved re-engagement sequence.

Example: An account selected a competitor because your product lacked a required integration. The agent monitors product releases, competitor reviews, leadership changes, and website activity. When the integration becomes available and the account returns to the pricing page, it drafts a message that references the original concern and explains what has changed.

The key shift: Re-engagement timing becomes signal-based rather than calendar-based, and the message addresses the actual reason the deal was lost instead of offering a generic “checking in.”

Tool chain: CRM closed-lost pipeline → Gong (previous conversations and objections) → Clay (external signals, enrichment, and orchestration) → Claude (context comparison and draft preparation) → Slack (human review) → existing sales engagement platform or CRM sequence → CRM writeback.

Related reading: These seven plays show what agentic GTM workflows look like in practice. For the broader operating model behind them, read AI GTM in 2026: What High-Performing Teams Do Differently, which explains how signals, context, decisioning, execution, and learning work as one system. If you are deciding who should build and own these workflows, the 2026 State of GTM Engineering maps the roles, skills, tools, and operating mandates emerging around this work.

How To Decide Which Play To Build First

The first play should be the one your team can operate with the least guesswork. Look for a signal that already exists, a person responsible for acting on it, and a next step that can be approved or rejected without opening six tabs and convening a small parliament.

Use four checks:

• Signal: Is the underlying data reliable and frequent enough to support action?

• Owner: Who reviews the recommendation and owns the next step?

• Action: What should happen when the signal crosses the agreed threshold?

• Learning: Will the response, meeting, rejection, or opportunity outcome return to the CRM?

If all four are clear, run the play manually with a small group of accounts before automating it. A champion job change connected to a known CRM relationship and account owner may be ready immediately; anonymous website activity with no scoring threshold or routing rule probably needs more design.

Build the workflow after the manual version produces useful conversations or better commercial decisions. Automation should follow a working operating rule, not volunteer to discover one on the company’s behalf.

Three Things To Do This Week

If the seven plays feel like a large menu, use this week to identify one signal, test one workflow, and decide where automation stops.

1. Build a Signal Inventory

Review the signals already available across your CRM, customer records, closed-lost opportunities, LinkedIn network, website activity, event lists, and previous conversations.

For each signal, capture: location · frequency · reliability · current owner · action it can support.

The output is one ranked list of usable signals, with the strongest candidate at the top.

2. Run One Play Manually

Choose the signal with the clearest owner and commercial action. Process a small batch of around 20 accounts or contacts before connecting additional tools.

Good starting points: former champions · closed-lost accounts · ICP-fit website visitors · relevant LinkedIn relationships.

Record the result: useful action · conversation · meeting · monitor · no action.

If the manual workflow produces no useful decisions, automation will only help it reach the same conclusion faster.

3. Set Permissions and CRM Writeback

Map the workflow as a simple sequence:

Enrich → score → stage → route → draft → send

For each step, choose one permission: automatic · human approval required · prohibited. Sensitive relationship outreach and important accounts should remain human-reviewed before anything is sent.

Define the CRM writeback in one line:

Signal · owner · recommendation · decision · response · commercial outcome

By the end of the week, you should have one prioritized signal, one manually tested workflow, one accountable owner, and clear evidence about whether the play is ready for automation.

Operator Note

Across all seven plays, teams already have plenty of signals and an increasingly crowded shelf of tools. What remains scarce is operational clarity: which signal matters, when it deserves action, who owns the decision, and what the system should learn from the outcome.

RevOps should be able to describe any agent workflow in one sentence:

When this signal appears, this owner reviews the recommendation, this action follows, and this outcome returns to the CRM.

Start with one signal and one accountable owner. Choose one primary tool for each function, run the workflow manually with a small group of accounts, and keep human review wherever timing, relationships, or reputation are involved. Automate only after the operating rule produces useful decisions consistently.

Once that logic is clear, agents can remove a meaningful amount of research, routing, and administrative work. Before then, another platform mostly gives the existing confusion a more expensive interface.

Question Worth Sitting With

If your RevOps team added agents this quarter, would they help the company notice warmer buying signals sooner, or would they mostly help the team send more messages to people who were never warm in the first place?

About me

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

Request GTM Audit

→ 360° assessment + 6-month action plan: Your GTM blindspots revealed

Book a call

or

Connect on LinkedIn

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 CRMs, and automation platforms.)

The real advantage comes from how you combine your stack into a system that consistently makes better decisions.

Besides, these four shifts have completely changed how the best GTM teams operate in 2026.

New AI-native GTM roles are emerging across organizations.

AI has a much richer understanding of your business context.

MCP connects AI directly to your GTM stack.

Agents can execute multi-step workflows instead of isolated tasks.

Most importantly, the best teams have stopped thinking in terms of individual plays and started designing systems that continuously sense, decide, execute, and learn

(e.g. automatically prioritizing accounts based on buying signals, generating personalized outreach using CRM and customer research, or identifying upsell opportunities from product usage and customer conversations).

Let’s get into more details below

The Great GTM Reorganization

The old GTM orgs were designed around departments: marketing = demand, sales = opportunities, CS = retention, RevOps = tried to make systems behave ))

AI-native GTM is organized around systems, not functions. The bottleneck is no longer executing work - it’s designing the revenue system itself.

Someone has to define how agents access business context, where humans stay in the loop, which decisions can be automated, and how the system continuously learns from outcomes. In other words, someone has to own the operating model.

We’re already seeing the rise of roles like GTM Engineer, AI GTM Architect, Context Engineer, and AI Ops Lead. Different titles, same responsibility: designing the revenue operating system that humans and AI work inside.

(I’m still waiting for someone to make “Chief GTM Fairy” an official job title)

Context Is the New GTM Infrastructure

AI becomes useful when it has access to real business context AKA sales calls, customer objections, website activity, content performance, strategy docs, customer success notes, onboarding data, etc.

Most teams have more context than they think. Scattered across tools, trapped in call recordings, buried in notes, or stored in someone’s head under the charming label of “tribal knowledge.”

Until it’s organized into a usable context layer, neither your people nor your AI can make consistently better decisions.

Once that context is structured, it becomes useful across your entire GTM motion. Customer research is a great example. Instead of relying on assumptions, AI can analyze what buyers actually say in sales calls, support conversations, interviews, and reviews. Those insights improve messaging, content, segmentation, lead scoring, and sales outreach.

Try now

Practical examples:

• AI analyzes sales calls to uncover recurring objections and recommends updates to messaging, content, and sales playbooks.

• Buying signals, CRM history, and customer research are combined to generate personalized outreach for every target account.

• Product usage, support conversations, and renewal data identify which customers are ready for an upsell, at risk of churning, or need proactive support.

• Every closed-won and closed-lost opportunity improves lead scoring, ICP definitions, and account prioritization for future deals.

• When a champion changes jobs, a company raises funding, or a new executive joins, the system automatically surfaces the opportunity and recommends the next best action.

MCPs connect AI directly to GTM stacks

MCP (model context protocol) become mainstream (think of APIs, but for AI tools).

Most advanced SaaS tools are adding them, so you can connect your AI agnets to theit functionality (makes AI dramatically more useful, but also need a lot of botsitting as they break often - the technology is still new)

With MCP you can copy information between tools or better - your AI agent can work directly with the systems your team already uses.

(e.g. - connect to Notion MCP that clean up/structure docs, organize knowledge, and pull the right context before agent starts working)

Agents can execute multi-step workflows (from plays to micro-campaign systems)

One of the biggest shifts is that AI agents no longer stop after a single task. They can coordinate entire sequences of work (and even rule an army of sub-agents).

Traditional GTM plays were mostly static: define ICP - build list -write message - launch sequence - review performance later - repeat.

In more detail:

2025: Most teams knew warm introductions converted better, but it was manual: someone would search LinkedIn, ask around in Slack, check the CRM, message the founder, and hope somebody knew the right person.

2026: AI agents can continuously map your relationship graph across LinkedIn, CRM, customer history, investor networks, and previous conversations. When a champion changes jobs, a mutual connection appears, or a former customer joins a target account, the system automatically surfaces the opportunity, provides the context, and recommends the next best action.

Even better:

2025: Competitor displacement was mostly reactive. Sales relied on battlecards and only talked about competitors after they came up in a deal. By then, you were already playing catch-up.

2026: AI agents continuously monitor signals like competitor mentions in sales calls, customer reviews, hiring trends, CRM notes, LinkedIn activity, and community discussions. When they detect evidence that a competitor is creating friction, they automatically surface the account, explain why it’s relevant, and generate messaging based on the buyer’s actual pain instead of your internal battlecard.

Or:

2025: Most outbound campaigns were triggered by a single signal, like intent data or a funding announcement. Every account received the same sequence, regardless of whether there was a genuine reason to reach out.

2026: AI agents continuously monitor a variety of signals across your ICP and wait for them to align. When competitor mentions, website activity, hiring changes, CRM insights, and relationship data all point to the same opportunity, the system automatically launches a focused micro-campaign with messaging tailored to that specific buying moment.

The Adaptive GTM™ Framework

With all of these shifts happening at once, it’s easy to get distracted by the latest model, agent, or workflow. But before you build anything, you need a clear way to think about the whole system.

That’s why I put together the Adaptive GTM™ Framework. It’s the mental model I use to design AI-native GTM systems that actually create better decisions, not just more automation.

The Adaptive GTM™ Framework is the mental model I use when helping founders and GTM leaders redesign their revenue systems for the AI era. It gives you a structured way to think about how signals become decisions, how context improves execution, and how every outcome makes the system smarter over time. Instead of jumping straight into tools and workflows, you build the foundation first.

I’ve used this framework while designing GTM systems across mature startups and growth-stage companies because the same pattern keeps showing up: teams automate execution before they’ve designed the system underneath it. That’s why the framework starts with signals, context, and decision-making before it gets anywhere near automation.

Whether you’re modernizing one workflow or rebuilding your entire GTM operating model, these five layers provide a practical blueprint for designing AI systems that create better decisions, not just faster execution.

What To Do This Week

You don’t need a 90-day transformation deck to start. Start small.

1. Pick one micro-campaign system to prototype

Don’t try to overhaul your entire GTM motion overnight. Pick one repetitive process that’s slowing the team down and improve it (e.g. meeting prep, content ideation, lead enrichment, or account research). Build momentum from there.

2. Use the tools you already have

Most of these workflows can be built using the free versions of ChatGPT or Claude alongside affordable tools like Clay, n8n, or Zapier. You don’t need enterprise AI licenses or a team of engineers before you can start experimenting.

3. Audit where your customer context lives

Output quality = input quality. Your agent is only as good as the context you give it. Start collecting structured knowledge (e.g. customer calls, sales conversations, objections, CRM notes, and your best-performing content) before worrying about the next shiny AI tool.

Generic prompts like “write a blog post about AI” rarely produce anything worth publishing.

4. Constrain the output heavily

The more specific your instructions, the better the results. Tell AI what you want, how you want it structured, what to include, and what to avoid. (Tip: store your prompts in Markdown files so your team gets consistent outputs.)

5. Define where human judgment is required

The best workflows keep humans in the loop where it matters most. Let AI handle the research and first draft, then rely on people for taste, strategy, and final decisions. (Trust the agent. Just don’t let it run your company unsupervised.)

6. Measure outcomes, not activity

Don’t celebrate because the workflow ran. Measure whether it actually helped. (AKA: did it create qualified conversations, improve conversion, shorten research time, or generate more pipeline?)

About me

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

Request GTM Audit

→ 360° assessment + 6-month action plan: Your GTM blindspots revealed

Book a call

Or

Connect on LinkedIN

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 research from Glean’s Work AI Institute found that UK digital workers save roughly 12 hours per week using AI, but spend about 6.3 to 6.4 hours supervising, correcting, rerunning, and managing AI-generated work.

That number did not surprise me.

I have seen teams build elaborate automation workflows only to discover they did not remove the work. They moved it into a new category: supervising the thing that was supposed to save them.

Some people are calling this “botsitting” (unpleasant word, but a very accurate job description).

The workflow is automated, technically. But someone still has to check whether it understood the brief, used the right context, updated the right field, routed the right lead, hallucinated something with full executive confidence, or turned a simple task into a small operational séance.

The ROI model usually misses the cleanup layer

Most AI and automation projects are evaluated with a simple promise:

Hours saved.

Tasks removed.

Headcount avoided.

Productivity improved.

The spreadsheet looks clean because spreadsheets are loyal little creatures. They will support almost any argument if you format them nicely enough.

What usually gets left out is the maintenance layer.

Every AI workflow creates obligations and someone has to monitor failures, update prompts, check outputs, manage exceptions, adjust integrations, review edge cases, and decide when the machine is confidently wrong versus merely unhelpful.

A workflow that saves ten hours, but creates five hours of supervision is not a ten-hour saving. It is a five-hour saving with a dashboard attached.

In the companies I work with, this distinction shows up very quickly.

Founders and GTM teams rarely have a “we need more AI usage” problem. They have a much more practical question: is this actually reducing the work required to create a better business outcome?

More seats, more prompts, more generated drafts, more internal screenshots of the team being “AI-first” can look good in an update deck. But none of it proves the system is improving revenue, speed, quality, or decision-making.

That is usually where I push the conversation back to the operating layer: what work is being removed, what work is being created, who owns the supervision, and whether the outcome is better than before.

Especially visible in GTM?

In go-to-market work, the difference between useful automation and expensive babysitting becomes obvious very quickly.

AI can help research accounts, summarize calls, enrich CRM data, draft first-pass outreach, flag buying signals, route leads, clean up admin work, and speed up follow-ups.

Those are good use cases when the rules are clear and the process already works manually.

But if the ICP is vague, the qualification logic changes depending on who is asking, and the handoff between marketing and sales mostly lives in someone’s head, AI will not rescue the motion.

It will expose the mess faster: the agent will not magically know which accounts matter. The scoring model will not understand political nuance. The automated sequence will not rescue a weak offer. The CRM cleanup workflow will not solve the fact that nobody agrees what a qualified opportunity actually means.

That is where botsitting becomes the real productivity tax.

People spend time feeding the tool missing context, checking whether the output makes sense, correcting errors, rerunning prompts, rewriting drafts, and explaining to themselves why the AI sounded so confident while being so deeply unserious.

I say this as someone who loves automation, builds these systems, and knows the small emotional journey of watching a workflow behave beautifully in testing and then collapse the moment it meets messy inputs, and a CRM field last updated during a previous economic cycle.

Before automating, use a filter

The best AI systems are usually built around boring clarity.

They have a narrow job.

They know where the data comes from.

They operate inside defined rules.

They flag uncertainty.

They keep a human in the loop where judgment matters.

(that last part is important!)

AI is useful when it supports judgment. It becomes expensive when it pretends to replace judgment the company has not even defined yet.

Before automating anything, I would ask six questions:

1. Does this task happen often enough for the saved time to compound?

2. Has the process survived 10-20 manual runs?

3. Can someone explain the workflow end to end?

4. Is the work rules-based, or does it require context-heavy judgment?

5. Does the time saved beat build time, maintenance, and error handling?

6. Who owns monitoring when the workflow breaks?

I use this as a simple automation filter. It keeps teams from turning every annoying task into a workflow, an agent, or a dashboard with opinions.

Automation is worth it when the work underneath it is frequent, stable, clear, and measurable. If the process is still vague, automation usually creates supervision work.

What is actually worth automating

Good automation usually starts with repetitive work that already has a clear process.

Lead routing is a strong example.

If a company knows the rules by region, segment, account owner, company size, and SLA, automation can remove delays and reduce missed handoffs. The workflow is boring, which is usually a good sign. Boring workflows behave better in public.

Follow-up reminders are another obvious case.

If sales keeps missing next steps because everything depends on memory, automate the reminder. No agent needed. No dramatic “autonomous revenue engine.” Just fewer opportunities quietly dying in the CRM because everyone was busy.

CRM cleanup can also be worth automating, especially when the rules are clear: standardize fields, detect duplicates, flag missing values, update lifecycle stages, or alert someone when records look wrong.

Document processing, proposal generation, meeting summaries, customer response workflows, Reddit monitoring, and email triage can all create real value when the inputs are predictable and the output can be reviewed quickly.

The pattern is simple:

Frequent work.

Stable process.

Clear rules.

Visible outcome.

Low drama.

A rare combination in business, but beautiful when it appears.

What should stay manual (for now)

Some work does not deserve automation yet.

One-off tasks usually fail the ROI test. If something happens once a month, takes two minutes, and does not cause errors, leave it alone. The build cost alone will quietly eat the savings while pretending to be strategic.

Unstable processes are another trap.

If the workflow changes every few weeks, automation becomes a rebuild subscription. Run the process manually first. Let it survive reality. Then automate the version that actually works.

Judgment-heavy decisions also need care.

Lead scoring, qualification, hiring decisions, strategic prioritization, and account selection can all be supported by AI, but they should rarely be fully owned by AI until the organization can explain how good judgment is being applied.

When AI starts making context-heavy decisions inside a process nobody has clearly defined, mistakes happen quickly. They also tend to arrive wearing the confidence of a senior executive who has not read the room.

And then there is automation tourism.

Every builder has done this at least once: you discover a new tool. You build something clever. It connects three systems, sends a Slack alert, updates a spreadsheet, and makes you feel briefly like a systems genius.

Then you realize it saves three minutes per week and requires emotional maintenance.

Congratulations. You built a tiny productivity monument to your own curiosity (been there myself!)

The real metric is work removed

The companies getting real value from AI are not simply adding more tools.

They are redesigning work around clearer context, better rules, and measurable outcomes.

Less “we used AI.”

More “lead response time dropped from four hours to five minutes, routing accuracy improved, and sales stopped manually fixing half the records.”

That is the difference between AI activity and AI productivity.

The market will not reward companies for generating more output if the output needs constant adult supervision.

Before building the next AI workflow, ask the question that belongs in every ROI model:

Are we eliminating work, or are we creating a new job that happens to sit behind a very impressive interface?

Source note: Based on recent reporting on Glean’s Work AI Institute research via TechRadar and ITPro.

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 GTM Teams Are Solving GTM with a 2016 Playbook

In 2026 the biggest change in GTM isn’t AI.

It’s visibility.

These days buyers leave signals everywhere: they’re hiring for new initiatives, evaluating vendors in public, discussing challenges in communities, adopting new technologies, and preparing for compliance requirements.

Interestingly, most of these signals never make it into a CRM.

As a result, many GTM teams have access to more information than ever before, yet they are still operating as if the hardest part is finding prospects.

The new challenge is knowing which prospects matter right now.

Instead of asking, “Who fits our ICP?” the better question is, “What changed inside this account that makes this the right moment to engage?”

Did anything change inside the account?

Did they hire a new security leader?

Start preparing for SOC 2?

Evaluate a competitor?

Expand into a regulated market?

The challenge, then, is turning tens of scattered signals into something actionable. That means building systems that can detect meaningful changes, enrich them with context, prioritize what matters, and route opportunities to the right people at the right time.

That’s what I mean by a modern GTM engine.

Why More Automation Isn’t Creating More Pipeline

At this point, it’s fair to ask: maybe AI SDR platforms already solved this problem?

After all (in theory), most of the outbound workflow can now be automated and produce more pipleine.

In practice, the results are much less impressive.

Across 75 AI SDR deployments tracked between 2025 and 2026, the median positive reply rate for email was 2.3%, while top-performing deployments reached 4.7%.

LinkedIn showed a similar pattern, with a median reply rate of 3.1% and a top quartile reaching 6.2%.

The interesting part is that many teams are using similar tools, similar models, and similar workflows, but some consistently generate twice the results of others.

So the difference comes down to ICP quality, signal relevance, personalization depth, and continuous optimization.

In other words, the quality of the system surrounding the automation.

This is why I think many GTM teams are asking the wrong question.

Instead of asking:

“Which AI SDR should we use?”

They should be asking:

“How does our system decide who deserves attention?”

Modern GTM is increasingly becoming a systems design problem, with advantage coming from building better systems for detecting opportunities, enriching context, prioritizing accounts, and deciding when action should be taken.

The AI gap is shrinking, while the execution gap is exploding.

The best teams aren’t winning because they have better AI.

They’re winning because they’ve built systems that make average AI perform extraordinarily well.

That’s the foundation of a modern GTM engine.

The Signal-to-Pipeline Operating Model

When I work with founders and GTM teams modernizing their revenue infrastructure, I rarely see a shortage of tools.

What happen more often? I see disconnected systems, where signals live in one platform, enrichment happens somewhere else, while outreach runs in another tool, and reporting sits in a dashboard nobody checks.

The result is predictable: opportunities are discovered too late, acted on too slowly, or missed entirely.

That’s why I encourage teams to think less about individual tools and more about the flow of information through their GTM engine:

Detect → Enrich → Prioritize → Orchestrate → Activate → Pipeline

I call this the Signal-to-Pipeline Model.

I often get asked: what counts as a strong signal versus someone simply venting in public?

If you look at the cybersecurity signals above, it’s easy to feel overwhelmed because there are so many of them. The reality is that a single signal rarely means much on its own.

What matters is signal combination. When a company is hiring a new CISO, researching competitors on G2, and preparing for SOC 2 at the same time, that pattern may indicate an active buying cycle.

The advantage comes from connecting these signals together and filtering out the ones that don’t create enough context.

So in practice, most signal-driven workflows discard far more accounts than they activate. The goal is relevance vs volume.

Modern GTM systems collect signals, enrich them with company and contact intelligence, prioritize the accounts most likely to buy, orchestrate the flow of information between systems, and activate the appropriate sales or marketing motion.

The result is a repeatable process for turning market signals into pipeline instead of relying on larger lists and higher outreach volume.

That’s the essence of the Signal-to-Pipeline Model.

Human Judgment Is Still the Moat

One of the biggest misconceptions about modern GTM is that better automation automatically produces better outcomes.

In reality, the more signals, workflows, enrichment sources, and AI tools you introduce, the more human judgment becomes a moat.

While AI is remarkably good at processing information, identifying patterns, and executing repetitive tasks, it struggles with deciding what matters.

Markets change. ICPs evolve. Messaging becomes stale. Signals that produced pipeline six months ago stop working.

Someone still needs to decide which signals matter, which accounts deserve attention, and whether the system is producing outcomes rather than activity.

The most effective GTM systems combine automation with human oversight because human-in-the-loop isn’t a temporary limitation.

It’s the mechanism that keeps the system aligned with reality.

What’s next?

The biggest mistake I see companies make is treating GTM as a collection of tactics.

They buy Clay.

Then Apollo.

Then a few AI agents.

Then they automate outreach.

But pipeline doesn’t improve because they never designed the system.

The teams getting the best results aren’t winning because they have access to better tools. Most are using the same platforms everyone else can buy.

The difference is that they’ve built a system for detecting opportunities, enriching context, prioritizing accounts, orchestrating actions, and continuously improving based on outcomes.

That’s why I believe GTM Engineering is becoming one of the most important functions in modern revenue teams, as someone has to design the infrastructure that turns signals into pipeline.

The future of GTM is better systems.

Companies creating predictable pipeline are already building better ways to decide which signals matter.

Leave a comment

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