Agents are good at reach and bad at judgment

11x raised $74M from Andreessen Horowitz and Benchmark to replace sales development with agents. In March 2025 TechCrunch reported that it was displaying logos of companies that disputed being customers, and vendor write-ups since have put its churn somewhere between 70% and 90% within months. Treat those churn ranges as second-hand, because none of them trace to a primary source.

Plenty of people took the whole episode as proof that AI SDRs do not work. That is the wrong lesson, and taking it costs you the part that does work.

The volume was never the problem

The reach worked, and it still works. Agents will out-send a human team by an order of magnitude without complaining, and nobody in this market is short of sending capacity.

What broke was judgment. Pure autonomy produced generic messages and burned sending domains. Reviews of the 2026 cohort land in the same place: agents are excellent at reach and, left alone, poor at deciding.

That asymmetry is not a temporary model limitation. Reach needs the message. Judgment needs the state of everything else at the moment of sending, and that state is usually not in front of the agent.

Where teams put the guardrail, and why it fails

The instinct is to put the check in the agent. Tell it the rules. Have it verify before it acts.

Here is a real example of why that breaks. I had a check that stopped us contacting anyone already in a conversation with the client. The logic was correct. The implementation was a script that wrote a flag, and the script ran before the push.

Then the pipeline went from hand-driven to automatic, and automatic execution has no order. Nothing guarantees the script runs before the push evaluates. The flag was empty when the send condition read it. An empty flag is not a blocked lead, it is a lead with no reason to stop. The condition passed. The message would have gone to someone already mid-conversation with the client, cold, as if we had never spoken.

Nothing errored. The guard was not bypassed, it was consulted before it existed.

A guard whose correctness depends on things running in the right order is not a guard. In an automated system there is no right order, only whatever happened to finish first.

The fix was not a better prompt. It was moving the check into the data the send condition reads, as a value that must be present and must say yes. The condition cannot evaluate before its own input exists. The ordering problem stops being something anyone has to remember.

The other failure with no error message

Same pipeline, different shape. I turned automatic execution on for a large batch and reported it running. For eighty-one minutes it had processed nothing.

The mechanism: automation fires on rows that are new or changed. These rows already existed and had not changed. Switching it on was a no-op, and a no-op looks exactly like a job that is early.

Worse, the check I ran to confirm progress could never have caught it. I looked at the first rows of the table and saw finished work, which read as “started, just early”. Those ids were creation-ordered, so the first rows were the oldest rows, from earlier runs. I was asking whether today’s batch had run, using a sample containing zero of today’s rows. It would have answered fine forever.

The primitive that answers the question is the run id. Empty means it never dispatched. That took seconds to check and I checked it 81 minutes in, because until then I had a story that fit.

Two habits that come out of this

Pushed is not sent. A successful write to a sequencer is a successful write. It is not a delivery, and on a deduplicating system it may not even be a new contact. Status is not outcome, and most dashboards quietly report one as the other.

A check on an empty set is not a pass. “Zero leads incorrectly routed” proves nothing if nothing had been routed yet. Before trusting any check, confirm it was capable of failing. If it cannot fail, it is not a check, it is a sentence.

So what should the agent do

Let it do reach: research, drafting, variation, volume, the tedious middle of a sequence. That is genuinely ten times faster and the failure mode is a mediocre sentence, which is cheap.

Anything irreversible gets a constraint that lives in the system, not in the agent’s instructions. Whether this person was already contacted. Whether the address is deliverable. Whether this domain has sent too much today. Expressed as a condition on data the action reads, so it is evaluated every single time by something with no memory to lose and no context to compact.

The common framing is “keep a human in the loop”, which I think is slightly off. A human reading every message does not scale, and after two hundred they stop reading properly anyway.

The durable version is narrower: the constraints live in the data, where the agent cannot forget them, and the human sets the constraints. Then reach can run as fast as you like, because the things that would be expensive to get wrong are not the agent’s job to remember.

Sources: AI SDR vs Outbound Agency vs Managed GTM Engineering, GTM Engineering Trends 2026