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.
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.
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:
AUTONOMY SPECTRUM: slide from Approve (see every move) to Run (let it go end to end). A job's risk sets where it lands, and the 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.
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 candidate: the job you are weighing 1. TRIGGER Is the trigger well defined? Can you state, in one sentence, exactly what fires this and what does not? 2. RECOVERABLE Is a mistake recoverable? If it does the wrong thing once, can you undo it or absorb it, or does it burn something you cannot get back (a key account, a brand moment)? 3. RECORD Can you read the record afterward? Will there be a log that tells you what it did and why, that a person could audit later? 4. KILL Do you keep a kill-switch? Can a human stop it, override it, or take the wheel back, immediately, without a deploy? Yes to all four -> should: let it run. No to any one -> not yet: fix that condition first, or keep a person in the loop until you can.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.
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.
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.
Source: https://www.civic.com/field-notes/buy-vs-build-can-vs-should