Agentic go-to-market, and the parts I would not automate

The definition, and the number that sets the ceiling

On OSWorld — a benchmark of real tasks in real desktop environments — humans finished 72.36% of tasks and the best model in the original paper finished 12.24% (OSWorld, April 2024). Anthropic's computer-use release scored 14.9% screenshot-only, 22.0% when given more steps (Anthropic, October 2024). Hold those numbers while you read any agentic GTM pitch.

Agentic go-to-market is a revenue operation where software picks the next step — which account, which message, which channel, whether to stop — inside limits a human set in advance, instead of executing a sequence a human already drew.

That is the only line that matters. Not volume. Not personalization. Not "AI-native." The question is who holds the decision.

Anthropic's own framing is the cleanest one published: workflows run predefined code paths; agents direct their own process and tool use (Building effective agents). A sequence with an LLM writing the second line of the email is a workflow. I wrote more about that boundary in autonomous agents, defined by who picks the next step.

Most software currently sold as agentic GTM is a workflow with a model in one slot. That is not an insult. Workflows are cheaper, easier to debug, and correct more often. It becomes a problem when you price, staff, and trust it as if it were something else.

What holds up in production, and what does not

τ-bench puts a tool-calling agent in a retail or airline support scenario with a simulated user and a policy document. The best function-calling agents solved under 50% of tasks, and the paper's pass^8 metric — the same task succeeding eight times in a row — drops sharply (τ-bench, June 2024). METR's time-horizon work estimated a 50%-success horizon of roughly 59 minutes of human task time for Claude 3.7 Sonnet (METR, 19 March 2025).

Read those two together: an hour of coherent work, and inconsistency across repeats. Fine for research. Not fine for anything that sends.

The reversibility column is doing the work. Anything an agent can undo, it can own. Anything that leaves your infrastructure and lands in a stranger's inbox, a CRM audit log, or a credit card statement needs a human release or a hard deterministic gate.

How one bad enrichment call becomes a blocked domain

That chain is why send authority is the wrong first thing to delegate. Google's sender guidelines ask bulk senders to keep the spam rate reported in Postmaster Tools below 0.10% and never let it reach 0.30%, on top of SPF, DKIM, a published DMARC record, and one-click unsubscribe (Google, Email sender guidelines). A 0.30% complaint rate on 5,000 messages is 15 people. Fifteen clicks, and the shared domain your AEs also send from is degraded.

CAN-SPAM adds the other hard edge: opt-out requests honored within 10 business days, accurate header and subject information, a valid physical postal address (FTC compliance guide). None of that is a model behavior you prompt for. It is a suppression table the agent cannot write to and a send service that refuses anything not on the allowlist.

The control plane is the actual product

An agentic GTM system is 20% prompt and 80% the runtime around it. The failure modes are documented and boring, and every one has a mechanical fix that lives outside the model.

A run you cannot replay is a run you cannot debug.

The minimum shape I would ship for any new GTM agent: three tools, a step cap, an append-only run log. That minimal shape is laid out in build an AI agent: three tools, a step cap, a JSONL note.

What a per-account research run costs

Take a research agent that works one account: pulls the site, three filings or funding items, two hiring signals, writes a brief. Call it 40 model turns, ~15,000 input tokens per turn as context accumulates, ~1,500 output tokens per turn.

That is 600,000 input tokens and 60,000 output tokens per account. Across 5,000 accounts: 3 billion input tokens, 300 million output tokens. Multiply by whatever your model charges on OpenAI's pricing page or Anthropic's and you get either an easy yes or an obvious no. There is no middle.

Two levers move that figure. Caching first: Anthropic prices cache writes at 1.25× base input tokens and cache reads at 0.1× (prompt caching docs). Your system prompt, schema, and playbook are stable across 5,000 accounts, so the repeated prefix belongs in a cache read, not a fresh input charge. Turn count second. Forty turns is 12 turns of work and 28 turns of the model re-reading its own scratchpad. Cutting turns beats cutting price per token.

Salesforce meters Agentforce by action rather than by seat (Agentforce pricing). That is the honest shape for agent work, because the cost is per action and so is the value. If you are building rather than buying, build the meter before the agent — I have argued that the meter is the first artifact, and for agentic GTM specifically it is what lets you kill an unprofitable play in week two instead of quarter two.

Three patterns I would not ship

I would not give an agent unattended send authority. Not on email, not on LinkedIn, not on SMS. The draft is reversible and the send is not, and the blast radius diagram above is the whole reason. Agent drafts, deterministic checks run, a human releases the batch. That single gate costs minutes per campaign and protects an asset — domain reputation — that takes months to rebuild.

I would not use browser-driving agents against logged-in systems. The reliability numbers are the first reason: 12–22% on OSWorld-class tasks. The second is contractual. LinkedIn's User Agreement prohibits using bots or other automated methods to access the service, scrape, or send messages (LinkedIn User Agreement). If a capability only exists because you are driving a browser around a terms-of-service clause, it is not a capability. It is a liability with a good demo.

I would not build a manager agent that delegates to sub-agents for outbound. The pattern is seductive — an SDR agent, a research agent, a writer agent, a coordinator — and in practice you have replaced a debuggable state machine with a conversation between four stochastic processes. Route with code. Let each agent own one bounded task with a typed input and a typed output. The A2A protocol's Agent Cards describe capabilities across organizational boundaries well enough (A2A repo), but inside one company's GTM stack, a function call is clearer than a negotiation. More on that in multi-agent system, defined without the hype.

What I would ship, in order: an agent that researches accounts and writes briefs a rep actually reads; an agent that keeps CRM fields clean and logs every write as a diff; an agent that triages inbound replies into three buckets and hands ambiguous ones to a person. All three are reversible, all three are measurable against a baseline you already have, and all three have a cost per run you can put on a slide.

Where the compliance line sits, before you design around it

GDPR Article 22 gives a person the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them (Article 22). For most outbound that is not triggered. For automated pricing, credit terms, or qualification decisions that gate access, it is. The design consequence is a logged human decision point on anything that denies or prices — not a checkbox after the fact.

The EU AI Act, Regulation (EU) 2024/1689, carries transparency obligations in Article 50 — people must be informed when they are interacting with an AI system unless it is obvious — with application dates staged through Article 113 (Official Journal text). If your agent is the one replying in chat or on email, disclosure is a product requirement with a deadline attached, not a brand-voice decision.

Both are cheap to build in and expensive to retrofit. The retrofit is expensive because disclosure and human-decision points change the schema: you need a field recording who or what made the decision, and a trace you can produce on request. That field costs nothing on day one.

The measurement that tells you it is working

Run the agent against the baseline you already have, on the same list, in the same week. Not a pilot. A holdout.

Three numbers, and only three. Cost per accepted output — accepted meaning a human used it, not that the run completed. Rejection rate by a named reviewer, tracked per prompt version, because a rejection rate that stops falling means the agent has hit its ceiling and more prompting will not move it. And repeat-run consistency: take 50 tasks, run each three times, count how many produce the same decision. τ-bench's pass^k idea exists because single-pass success rates flatter agents badly (τ-bench); the same trick works on your own pipeline for a few dollars.

If consistency is under 80% on your own tasks, the agent is not ready to own the step. It is ready to propose it. That is not a failure — a proposal an AE accepts 9 times out of 10 is worth real money, and it ships this month.

The Harvard field experiment on AI and venture teams found effects on the work itself rather than on the org chart. Read what that study actually measured before you plan headcount around any of this.