Elyndarin Zorkal 
The spreadsheet is open on a second monitor. Two columns, familiar labels: Build and Buy. License fees stacked on one side, developer salaries and timelines on the other.
Someone in the meeting asks the obvious question: where does the AI agent go? Nobody answers right away, because the answer doesn't fit either column.
The older framework assumed "build" meant a team of engineers typing for months and "buy" meant a vendor contract and a login. Agents sit in the middle and change both sides of the math.
A coding agent can draft a service in an afternoon. A workflow agent can take actions inside your systems the way a junior employee would. Neither one is a line item the spreadsheet was designed to hold.
Decide What You're Actually Comparing
Before you argue build or buy, figure out what the agent column represents on your particular problem. An agent that drafts code for your engineers to review is a productivity tool. An agent that executes workflows inside your billing system is closer to a new employee with system access.
Those two things belong in different rows, with different risks, and probably different approvers. A useful framing from Harvard Business Review is to treat agents less like software features and more like team members who need onboarding, scope, and oversight.
If that framing fits the problem in front of you, the comparison isn't "build vs. buy" anymore. It's "hire a vendor, hire a person, or hire an agent." Firms like DEV approach the agent column that way from the start, scoping the work before the agent gets access.
Decide What the Agent Is Allowed to Touch
Blast radius matters more than cost on this spreadsheet. A buy decision usually caps the damage at a seat count and a monthly bill. A build decision with an agent in the loop can cap the damage much higher if nobody draws the box early.
Before the agent writes a single line or clicks a single button in production, answer three questions in writing:
These aren't philosophical questions. They map directly onto the cost side of the agent column, because every "the agent needs a human to approve" answer adds a reviewer hour to the running total.
Decide Who Owns the Code the Agent Writes
An agent-written feature isn't free, and it isn't maintained by magic. Somebody on your side has to read the diff, understand it well enough to defend it in a code review, and own it when it breaks at 2 a.m. If no one owns it, you've bought a liability and labeled it an asset.
This is where the honest version of the spreadsheet gets uncomfortable. Agents shift the bottleneck out of writing and into reviewing, and review takes senior time. A study of 1,255 teams and more than 10,000 developers found that AI-augmented code is getting bigger and buggier, pushing the real work downstream to review. The agent column needs a line for that review labor, or the number is a fiction.
The ownership question also shapes vendor selection. If you're hiring a partner to build with agents on your behalf, you want one that hands over clean, readable, documented code with a human engineer's name on every pull request.
Decide What a Good-Enough Answer Looks Like
The spreadsheet was usually a decision aid, not a decision. Its real job was to force a conversation about trade-offs. That job is bigger now, not smaller, because the agent column introduces a kind of risk the old two-column view wasn't designed to price: execution risk inside your systems, not just content risk on a screen.
A good-enough answer usually looks like a hybrid. Buy the commodity. Build, with agents and senior humans together, the thing that actually differentiates you.
Keep the agent on a short leash where the blast radius is high, and give it more rope where mistakes are cheap and reversible. Rewrite the columns so they reflect what you're really choosing between, and the number at the bottom will mean something again.
