When the Agent Proposes to Build or Bypass: An Approval Path for Procurement

SaaStr’s Jason Lemkin writes that “one estimate we got puts our cost at as much as $240,000 a year” for agent API access. It is a single estimate from an unnamed vendor, for an agent making 35,000 to 40,000 API calls a day. The team behind it is 3 humans and 21+ agents.

The agent’s answer was to stop paying for access and mirror the system of record into a $5 Postgres instance. The post’s title carries that number. By the author’s own framing the $5 was never costed, and he admits the mirror “would get out of sync.”

We read this as a procurement event. The proposal came from an agent, and it sits among three moves: buy the access, build a replacement, or bypass the vendor’s gate.

Two proposals, one pattern

The first proposal is the mirror. SaaStr also describes the market in a few lines. Salesforce is “rolling it out now, with a banner.” Atlassian “already did it.” On HubSpot’s charging, the author writes that “so far it looks aimed at their own first-party agents.” That is his reading of a pricing move, not a published HubSpot policy, and we pass it on as his.

He also describes an earlier API-limit problem. Marketo “would go down on us after 10 or 20 minutes each day because of API limits,” so the team migrated off it. API limits had already forced one migration at this team.

The second proposal is the build. In a separate post, SaaStr says its agent pushed the team to replace Calendly with a scheduling tool, built on Replit in “about 20 minutes.” The post’s own reasoning is cost-based: had the build been estimated at two weeks, the team says it would have kept Calendly.

That sentence is the useful one. The team’s reasoning is about cost: change the estimate and, by its own account, the decision changes with it.

What the evidence is

Both posts are one operator’s account of his own team. The Calendly post reports no bookings, conversion or cost figures, and we found none in the first post either, so we have no outcome data for either decision. The $240,000 is an estimate. The measurement the Calendly post does give is that Zapier was “silently losing about 20% of our signups before they reached Salesforce,” and the author gives no method for it.

There is a disclosure point too. The author promotes his own agent product, and we found no disclosure of that relationship on the pages we read. Neither page shows a visible publication date. We treat both as October 2026, which is what the page metadata indicates.

So this is not proof that agents buy well or build well. It is a record of what an agent proposes when it meets a pricing wall and a subscription, and of how one team responded.

The gate is the artifact

The most reusable part is a line from the Calendly post: “An agent wanting to build something is a bad reason to build it. Agents like to build.” The author’s response is four questions for any agent-proposed build:

1. What does it do that the vendor cannot?
2. Would an API integration cover most of it?
3. What data does it need that only we have?
4. How long will it take, and what happens if it breaks?

Question four is where the Calendly decision turned. A 20-minute build and a two-week build get different answers. Question two is where the mirror proposal should have been tested, because API access is what the $240,000 estimate was for.

The gate is useful because it is short enough to run on every proposal. It has a limit, though. It was written for builds. The mirror is a build of a different kind, since it copies the system of record to avoid a charge.

Where we would extend it

This section is our argument, not the source’s.

A mirror of a system of record creates a second copy that someone has to keep correct. The author concedes it drifts. Two copies that disagree are a governance problem before they are a cost problem: a report built on the mirror and a report built on the original can both be defensible and both be wrong. The $5 line item hides that.

We would add two questions for any proposal that routes around a vendor’s access terms rather than replacing the vendor:

• Which copy is authoritative when the two disagree, and who owns the reconciliation?
• Do the vendor’s terms allow the copy, and who reads those terms before the agent builds it?

We do not claim to know what these vendors’ terms say. The posts do not report it. Nothing in the posts shows the agent asking, and the four-question gate does not make it ask.

We would also add an extra step before the questions: a named approver. The gate only works if a human with budget authority sees the proposal. An agent that originates the proposal and then judges it against its own gate is a proposer approving itself. Related reading: Your Coding Agent Approved Its Own Overage 97% of the Time, Making Your Product Agent-Ready Is a Governance Decision, Three Prices for One Agent and When the Agent Is Its Own Procurement Department.

What an approval path contains

We propose five elements, and we label them as ours:

• Origin. Record that the proposal came from an agent, and from which one.
• Category. Buy, build or bypass. Each gets a different reviewer.
• The four questions, answered in writing before work starts.
• An estimate that someone other than the agent produced, because SaaStr’s own conclusion turned on one.
• A named approver and a review date. A build you keep must be re-judged against the vendor you dropped.

Nothing here needs new tooling. A ticket template does it.

Do this now

Pull the last agent-originated suggestion in your team that involved a vendor: a subscription to replace, a tool to build, an integration to skip. If none is written down, that is your finding: the proposals have no record to review.

Run it through the four questions, add the two bypass questions, and write down who approved it and on what estimate. Then make that the template for the next one. Do it before the agent’s next proposal, because an agent can originate such a proposal at any time, and the approval path is cheaper to build before one of them needs it.

---

This analysis synthesizes We Got a $240,000 Estimate for Agent API Access. Our Agent Suggested a $5 Postgres Instance. (SaaStr, October 2026) and We Vibe Coded Our Own Calendly. Our AI Agent Pushed Us To Do It, and It Was Right. (SaaStr, October 2026).

Victorino Group helps teams design approval paths for agent-originated buy, build and bypass decisions. Let’s talk.