A provider recently handed me a list of work emails. Every one looked right: right domain, right format, a green "verified" next to each. The agent that pulled them reported the job done.
Then my harness did one more thing. It pulled each person's current LinkedIn profile, and a real share of them didn't work there anymore.
The emails were real. The mailboxes still accepted mail. The people were gone.
That's not rare. One operator ran a 10,000-person list through Apollo, a Clay waterfall and ZeroBounce, and found "close to 800 people had changed jobs. zerobounce passed every one, because the old mailbox still accepts mail."
Two years ago I'd have had a shot at catching that by scrolling a Clay table and squinting at titles that didn't fit. Today nobody scrolls. The agent builds the table, checks the table and tells you it's done.
So who grades the agent?
The screen used to grade it
I haven't worked inside Clay's interface in weeks. Clay is still in my stack. I just don't open it.
My work runs as workstreams, one per campaign. Each workstream has a brain: a long-running Claude session that plans, pushes back and grills me on the approach before anything ships. The brain doesn't do the work itself. It sends out hands, child sessions that build the table, pull the data and draft the copy. Then it reads what they bring back.
I'm not unusual here. Leszek Lammel, second at this year's Clay Cup: "I just don't use its interface anymore." Clay shipped a CLI, and the vendors already have a name for the whole shift: headless GTM.
Here's what the name leaves out. Scrolling a Clay table was QA. Nobody called it that, but it was. You saw every row. You saw the blank emails, the "VP of Sales" who was clearly an intern, the company that was clearly a different company. Your eyes were the grader.
Headless deleted that step and didn't replace it. Agents now build tables I never open. They also touch the automations around those tables: the CRM sync, the routing rule, the sequence that fires on Tuesday. And the failures don't look like failures. From a Reddit roundup of RevOps people: "It ran and produced zero rows, which looks identical to a quiet week." Another team's bounce rate "crept up to like 4.7% over about 3 weeks and nobody noticed."
Coders hit this a year earlier. When agents started writing more of the code, review became the bottleneck, and the answer wasn't to look harder. It was tests, CI that blocks a bad merge and a second model reading the first. GTM went headless without building any of that.
Now the vendor grades it
The second thing my harness caught was quieter, and it cost money.
When an agent works in Clay or with a data provider, it loads that vendor's official skills: instructions on how to use the product. Those instructions are written by companies that sell credits. Run as-is, my agents kept drifting toward the expensive path, with long waterfalls where one provider would do and models running on the vendor's funded credits instead of our own company keys.
Nobody has to plan that. A skill written by someone who sells credits defaults to spending credits. We saw the same thing when we read 2,628 public GTM skills: the pitch lived in the instructions, where only the model reads it. Clay now even ships credit spike alerts for the "where did those credits go????" moment. An alert tells you afterwards.
Now the same vendors are selling the next step: an engine that improves itself. Kareem Amin, Clay's CEO, calls it a "self-learning revenue engine." Clay's blog describes "learning loops where agents improve their own workflows."
Learning needs a grader, something that says this run was better than the last one. In a vendor's engine, the grader is the vendor: its data, its idea of a good result, sitting right next to its credit meter.
My bet: an engine graded by the company that sells the credits will learn to spend credits. Not because anyone wants it to. Because that's what the grade rewards.
To be fair, Clay is publishing numbers. On November 3 it released a benchmark in which its Account Agent caught a hidden duplicate-record risk 30 times out of 30, against 18 for a general-purpose agent wired to Salesforce and Gong. That's a real result. It's also Clay's scenario, Clay's scoring and Clay's agent.
Johnson Lee put the gap well: "continuous execution and continuous progress toward correctness are different things." So when someone sells you an engine that learns, ask one question. Learning against what?
So I grade my own
There's no one-size-fits-all GTM. Your business, your product and your stack decide what a good row looks like, what counts as a signal and who must never get an email. Kareem himself says the edge in GTM is "very specific to your business." That's exactly why a vendor's grade can't be yours.
So I built my own harness. The easiest way to show it is to follow one row from that provider list. Call her Priya.
Before the table even runs, the harness reads how it's built: which key each column uses, whether the waterfall stops at the first hit, whether retries have a ceiling, whose credits pay for each step. That's where it caught my agents spending the vendor's credits instead of ours.
Then Priya's email comes back verified. The harness doesn't take the provider's word for it. "Verified" means the mailbox accepts mail, not that anyone still reads it. So the harness re-checks a sample against live LinkedIn, and Priya left Halcyon AI in June. The row stops there, and the provider gets scored on cost per valid row, not cost per row. Cody Schneider ran into the same gap: one provider marked 33 emails valid, and the verifier passed only 10.
Had the row passed, two more checks were waiting. Workflow monitors count every handoff daily against yesterday and flag any run that produced zero rows, so a quiet week has to prove it's quiet. And every claim an agent attaches to a contact, "just promoted" or "company is hiring", carries the URL it came from, or it doesn't ship.
Afterwards the harness reads the trace of the whole run, not just the output: where the agent looped, which skill pushed it toward the expensive path, which step it quietly skipped. Then it proposes a fix to the skill or the prompt, and I approve it or don't.
Underneath, decision models make the calls that need judgment, and cheap models like DeepSeek do the heavy digging through data for almost nothing.
None of these checks is clever, and none would transfer cleanly to your company. Each one started as something I caught by hand. That's the habit worth copying: find it by hand once, encode it, never check it by hand again.
Learning against your goal
The grader matters even more once agents start to learn, and mine are starting to.
I'm building account agents for AEs and customer success teams on Mastra. Each account gets its own agent with one goal: close the deal, or expand it. It learns from the rep's edits, from outcomes like replies and stage changes, from what was actually said on calls, and from the harness's verdicts.
That last signal keeps the other three honest. An agent that learns only from outcomes will happily learn that more emails mean more replies. Graded against your goal, on your data, by a harness that reads its traces, it learns what you actually wanted.
DeepSeek's harness team landed on the same split in the Super-agent prototype it open-sourced on October 31: a separate watchdog judges whether the workers are making progress. The judge isn't the worker. That's this whole argument in one design choice.
Headless took away the screen. Your benchmark is the screen you put back.
Next week I'm publishing mine.
Vendor dashboards are useful. They just can't be the only judge of their own work.