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

Your Outreach Stack Isn’t Broken. It’s Just Bleeding You Dry.

I’ve audited the GTM stacks of more sales teams than I can count, and the pattern is almost always the same. They know the contract line for Outreach or SalesLoft. They don’t know the actual math.

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.

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 teams where the funnel looked more like a fog machine. Endless noise, no direction. And when I say “growth plan,” I don’t mean spending two weeks renaming Notion folders.

If you’re building something new and searching for traction, you don’t need another 45-tab Miro board.

You need signal. You need structure. You need speed with a spine.

That’s what these frameworks are for.

What these frameworks actually help with

I’ve spent years helping technical founders turn “we built a thing” into “we’re getting users.”

These five frameworks are my response to all the fuzzy funnel moments I’ve had to fix — too much content, wrong message, great product, zero pull.

Each one is designed to help you:

• Find early traction (not just “create content”)

• Say sharper things in smarter places

• Use speed strategically, not chaotically

If you’re trying to get your first 100 users, build narrative clarity, or stop reinventing your positioning every time you write an email — you’ll want to bookmark this.

Let’s break them down.

TL;DR: You don’t need a massive team — you need the right systems and someone to help you run them

I work with early-stage founders to cut through the noise, sharpen messaging, and launch fast GTM experiments that don’t die in Notion.

In this post, I’m sharing five AI-powered frameworks I use to help you find early traction without hiring a full marketing team or spinning in strategy loops.

1. SCOPE – Quickly turn market signals into testable campaigns with messaging, offers, and channel focus

2. The Alignment Flywheel – Keep your story tight across all touchpoints, even as you move fast

3. Message Engine – Test value props and sharpen narrative before committing to a full relaunch

4. Content Barbell – Balance SEO and social with one idea → many outputs (without burnout)

5. The Traction Stack – Run structured growth tests that actually scale instead of random tactics

You don’t have to do this alone. I bring the structure, the systems, and the speed — so you can focus on building.

1. SCOPE – AI-Powered Campaigns That Don’t Waste 3 Months

Let’s say you’re pre-traction.

You’re staring at a blank doc titled “launch campaign.” You’ve got vague buyer personas, a gut feeling about Reddit, and 20 half-baked content ideas in a Notion graveyard.

SCOPE is the framework I use to build actual campaigns that ship fast, sound sharp, and aren’t pulled out of thin air.

It stands for:

Signals · Content · Offers · Placement · Execution — and AI plugs into every part.

What problem it solves:

You’re not sure what message to lead with, what offer to pair it with, or where to test it.

SCOPE gives you a way to structure all of that in one repeatable loop.

How AI helps:

• Finds early signals (complaints, questions, trends) across Reddit, Hacker News, YouTube comments, forums

  → Tools: Octolens, GummySearch, Perplexity, Glasp, Hacker News search

• Distills market language from transcripts, tweets, or reviews

  → Tools: Claude, ChatGPT, Fireflies.ai, Fathom

• Drafts fast variations of hooks, explainer copy, ad headlines

  → Tools: Custom GPTs, Copy.ai, Jasper

• Suggests offer ideas from trends (e.g. “everyone’s asking for [X], give them a checklist”)

  → Tools: ChatGPT, Airtable for clustering

• Rewrites content per channel — so your cold email doesn’t sound like a blog post

  → Tools: ChatGPT + Typefully / Taplio

• Automates campaign setup

  → Tools: Zapier, Notion, Airtable templates

Use case: A 3-months brand campaign now takes a week — with more creative variation.

If you want the full step-by-step behind how I run SCOPE in real founder workflows — I share the deep dives, templates, and system breakdowns inside the paid newsletter. Worth it if you’re building for speed and signal.

2. The Alignment Flywheel – Keep Your Messaging From Falling Apart

The faster you build, the messier your messaging gets.

One week you’re promising speed. Next week, your product page leans into security. Your emails sound like a SaaS founder, your ads like a self-help coach. No one’s on the same page — because there is no page.

The Alignment Flywheel keeps your message consistent across channels as you scale.

It helps you turn raw insight into reusable message blocks, push those across touchpoints, and evolve your story without rewriting your positioning doc every two weeks.

How AI helps:

Extracts repeated themes from calls, support convos, Slack threads, and demos

→ Tools: Claude, ChatGPT, Fathom, Fireflies.ai

Rewrites your core narrative for different personas, channels, or tones

→ Tools: Custom GPT, Jasper, Notion AI

Audits message drift by comparing what’s working vs. what you’re actually saying across your funnel

→ Tools: Claude, ChatGPT, Loom transcripts, landing page crawlers

Remixes messaging across assets like outbound, onboarding, and paid campaigns

→ Tools: ChatGPT, Taplio, Typefully, Copy.ai

Organizes message blocks into a single source of truth

→ Tools: Notion, Airtable, Coda, Supernormal

What problem it solves:

You’ve got traction, but the story isn’t scaling with you. This framework helps you stay clear, consistent, and aligned — without slowing down.

Want to see how I run this with early-stage teams? The paid newsletter includes a breakdown of how I structure messaging hubs, run async audits, and keep everyone saying the same sharp thing.

3. Message Engine – Sharpen Fast, Test Faster

You’ve got five versions of your value prop, and your team can’t agree on which one actually makes sense. Meanwhile, your website says one thing, your cold emails say another, and your latest deck starts with “We’re revolutionizing…”

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. Meeti…

Read more

“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 about jobless marketers and prompt-replacing overlords.

Meanwhile, the real shift is quieter — and smarter.

AI isn’t replacing marketers.

It’s redefining what great looks like.

Founders aren’t asking, “Should we use AI?”

They’re asking, “Why is our messaging still slow?”

“Why are we guessing what works?”

“Why does it take a team of five to run a funnel?”

Here’s the unlock:

They reach for it instinctively.

To test. To think. To prototype. To scale.

The AI-First marketer isn’t the person who knows the most tools.

It’s the person who knows how to think in systems, build for momentum, and ship faster - without losing the thread.

This is the inflection point:

Not AI vs. humans.

But AI as leverage — and the marketers who know how to wield it win.

Share

What Is an AI-First Marketer?

First off - no, it’s not the person sending ChatGPT “write me viral LinkedIn post” and calling it a growth strategy.

And no, it’s not your colleague who downloaded 12 AI tools and built absolutely nothing.

Being AI-First isn’t about flexing your stack. It’s about defaulting to leverage.

When a new challenge shows up, your instinct is:

“Cool. How do I loop this, automate it, scale it, or make it smarter with AI?”

An AI-First marketer is not:

• A prompt monkey cranking out SEO sludge

• A growth hacker rebranding spreadsheets as “LLM automations”

• A startup mascot who spends more time screenshotting GPT responses than shipping work

Here’s what they are:

• A systems builder with creative taste

• A marketer who can write and wire things together

• Someone who actually understands how ideas turn into motion

They can:

• Turn a messy founder rant into a narrative and a Notion workflow

• Spin up 15 ad angles using customer pain, not “brand adjectives”

• Catch GPT when it’s hallucinating — because they’ve actually read their own outputs

• Stack tools like Clay, Zapier, Notion, and GPT to build growth loops that don’t suck

They don’t worship the tools — they orchestrate them.

They don’t say “let’s test this” and then wait three weeks.

They say “brb, shipping a working draft in 10 minutes and a meme while it renders.”

AI-First marketers move fast.

Not because they’re hustling. But because their systems are.

Voices from the Fields

“AI marketing isn’t just a thing, it’s basically the future. The biggest shift I’ve seen is AI taking the guesswork out of ad performance. We’re testing AI that not only optimizes ads in real-time but also predicts which creatives will perform before we even launch them. It’s making campaign management way more efficient.”

“AI marketing tools are a full-time job to keep up with … but optimising campaigns using reinforcement learning is next-level.”

“AI will not take over digital marketing… [it] will likely redefine their roles. …Digital marketers of the future will focus more on creativity, strategy, and ethical considerations while leveraging AI for data analysis, personalization, and automation.”

“Honestly, if you’re still writing every line from scratch in 2025, you’re either doing it for the love of pain or seriously underestimating your time. […] The real skill now isn’t avoiding AI—it’s knowing when to use it and when to step in so your copy doesn’t sound like it came out of a corporate blender.”

Turns out, the AI-First marketer isn’t a mythical job title — it’s already a Reddit regular with three browser tabs open, one broken Zap, and a strong opinion about reinforcement learning. Some are automating ad campaigns like it’s NBD, others are drowning in tool fatigue, and a few are just trying to stop their copy from sounding like it was written by a well-meaning robot with zero social life. The vibe? AI isn’t replacing anyone. It’s just making it painfully obvious who’s thinking in systems… and who’s still manually updating the Monday board.

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, th…

Read more