For twenty years the go-to-market tooling decision was buy versus build. Agents collapse that axis. Capability stops being the constraint, and the real question becomes should this run at all, and should it run on its own.
Brad Webb, Chief Growth Officer
||8 min read|
tl;dr
For most of my career the go-to-market tooling call was buy versus build: license a vendor, or spend engineering time you did not have. Agents collapse that axis. When an agent can stand up most of what you used to buy or build, capability stops being the thing that is scarce. The question stops being "can we get this built" and becomes "should this run at all, and should it run on its own." Here is a simple test for answering the second question, and why I think judgment is the new moat.
The decision I used to make
I spent a lot of years standing at a whiteboard drawing the same two columns.
On the left, buy. Find a vendor, run the trial, negotiate the seats, wire it into the stack, and accept that it would do eighty percent of what you wanted and none of the last twenty. On the right, build. Open a ticket, wait for a sprint that never quite arrived, and accept that the thing you actually needed sat behind three other things engineering owed the rest of the company. The whole exercise was about capability: who could get this built, at what cost, by when.
That question was hard because capability was genuinely scarce. Standing up something that could watch a signal, score it against your definition of a good account, and carry it into a real action took either a product someone else had spent years building or a team you did not have. So you picked a column. You lived with the tradeoff. And the next quarter you drew the two columns again for the next job.
I do not draw those two columns anymore. Not because I got disciplined, but because the axis stopped meaning what it used to.
The axis collapsed
Here is what changed, in plain terms.
An agent can now stand up most of what used to sit in either column. The watch, the score, the enrichment, the message, the write-back to the system of record, the record of what it did and why. Not a toy version. A working version, wired into your own stack, running against your own definitions, in a fraction of the time and cost that either buying or building used to demand. I have watched this happen inside our own walls, and I have watched it happen for teams far smaller than mine.
When that is true, the buy-versus-build matrix quietly stops being the interesting one. Both columns converge. You can have the capability. The cost of getting it dropped through the floor.
And that is exactly the moment a lot of teams get into trouble, because the old question was load bearing in a way we did not notice. "Can we get this built" was doing more than scoping a project. It was a natural brake. It forced a prioritization, because you could only get so many things built, so you only asked for the ones that mattered. Take the brake off, and you do not automatically get better judgment. You get more things running. Some of them should be running. Some of them should not.
So the question I scope now is not "can we build this." It is "should this run at all, and should it run on its own." Those are two different questions wearing one coat, and both matter.
Should this run at all is a prioritization question. Just because an agent can take a job does not mean that job is worth taking. The scarce resource is no longer engineering capacity, it is attention: yours, and your team's, and your buyers'. Every job you hand to an agent is a thing you now own the outcomes of, whether you watch it or not.
Should it run on its own is a governance question. There is a real difference between a job you are comfortable letting run end to end and a job you want to see before it goes out the door. The mistake I see teams make is treating that as a single switch, on or off, autonomous or not. It is not a switch. It is a spectrum, and where a given job sits on it depends on how well you understand the trigger, how bad the worst case is, and whether you can reconstruct what happened afterward. Move the marker to see how a job's risk maps onto the autonomy it earns:
How much autonomy does the job earn?
Approve, see every moveRun, let it go end to end
Let it run (Run). Well understood, recoverable, high volume, like moving a warm signal into a first touch. Run mode, end to end.
Kill-switch stays in your hand at every setting.
This is the same move my colleague Chris made when he wrote about why we narrowed. When you can do anything, the discipline is in choosing one thing. Can-versus-should is that discipline applied to the tooling layer. The capability is not the achievement anymore. Choosing well is.
A test you can run on Monday
I want to give you something concrete, because "exercise better judgment" is useless advice on its own.
Here is the test I actually use before I let an agent take a job. Four questions. If a candidate job is a clear yes on all four, it is a should, and you can let it run. If it fails any of them, it is not a no forever, it is a not-yet: fix the failing condition first, or keep a human in the loop until you can.
Should we run it?
Is the trigger well defined?Can you state in one sentence exactly what fires this and what does not?
Is a mistake recoverable?If it does the wrong thing once, can you undo or absorb it, or does it burn something you cannot get back?
Can you read the record afterward?Will there be a log of what it did and why, that a person could audit later?
Do you keep a kill-switch?Can a human stop it, override it, or take the wheel back immediately, without a deploy?
Should. Let it run.A clear yes on all four. Judgment stays in the loop through the guardrails, not by watching every run.
Notice what this test is not. It is not "is the agent smart enough." Capability is assumed now, that is the whole point. The test is entirely about the shape of the job and the guardrails around it. A well defined trigger, a recoverable mistake, a readable record, and a kill-switch. Those four things are how an operator keeps judgment in the loop over something that can already do the work.
You will find that a lot of high-value jobs pass cleanly. Moving a high-intent signal into a first-touch action has a crisp trigger, a recoverable outcome, an obvious record, and an easy stop. You will also find jobs that fail on purpose, and it is good that they fail: a net-new pricing negotiation, a sensitive executive relationship, anything where the worst case burns something you cannot get back. Those are not-yets. Keeping them out is the judgment.
Where this shows up in what we build
I would not put a test in front of you that our own product could not stand behind, so let me be direct about how this connects.
Bryn, our Signal-Based GTM agent for Growth teams, is built around exactly this spectrum. It is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack. Every Play runs in one of three modes that map straight onto the questions above. Run, when the job clears all four and you are comfortable letting it go end to end. Approve, when you want to see the move before it leaves. Kill, the switch that is always in your hand. Underneath all three sits the audit log, the work record that answers the third question by default, so that "can you read the record afterward" is never a hope, it is a given.
That is what it looks like to build for the should question instead of the can. In our own workflows, Bryn moved high-intent signals from "we'll review this later" to action within minutes, and it kept the receipts while it did it, so we could always answer why a given account got contacted on a given day. The speed matters. The fact that a person set the rules and could read the record afterward matters just as much.
Judgment is the moat now
If capability used to be the thing that separated good go-to-market teams from the rest, it is not anymore, or it will not be for long. The tools converged. Anyone can have the eyes and the hands.
What does not commoditize is knowing which jobs are worth running, which ones a human keeps a hand on, and which ones you deliberately choose not to automate at all. That is judgment, and it is the scarce thing now. The buy-versus-build column I used to draw was a proxy for a capability question that has mostly been answered. The question worth drawing columns over is can-versus-should, and the should column is where the work of a growth leader actually lives now.
Run the four questions on one candidate job this week. It will tell you more about how ready you are to operate an agent than any feature list ever will.
If you are working through the should question on your own team, I would be glad to compare notes. You can reach us through civic.com, or try Bryn yourself at civic.com/bryn.
Brad Webb is the Chief Growth Officer at Civic; he's been building the bridge between Engineering and GTM/Sales for over two decades, merging them into the science better known as Growth.
If Brad isn't running experiments or sending off Agents to verify data, he's probably building tube-based HiFi gear with his sons, hopefully remembering to drain the capacitors before soldering.
