The use case is validated. You have run it manually, you know the volume, you know what good output looks like, and you are confident reasoning is genuinely required rather than a rules engine in disguise. If that last part is not settled, settle it first — most requirements that reach this stage are still workflows rather than agents, and the build-versus-buy question is irrelevant until it is answered.
Assuming it is settled: platform or custom?
The framing that wastes the most time is treating this as a cost comparison. Cost matters, but it is rarely what decides correctly. Two other variables do more work: where your integration ceiling sits, and who owns the system eighteen months from now.
The trade-off grid
Six dimensions. Each has a genuine advantage on one side and a genuine risk on the other.
| Dimension | Buy | Build |
|---|---|---|
| Time to first production use | Weeks. Infrastructure, monitoring and guardrails already exist. | Longer. You are building the scaffolding as well as the agent. |
| Upfront cost | Low. Subscription, minimal setup. | Meaningful. Published Indian ranges for agentic builds run roughly ₹3–8 lakh. |
| Cost at scale | Scales with usage. Per-execution pricing rarely favours growth. | Fixed build, then infrastructure and model cost. Favourable at volume. |
| Integration reach | Bounded by the vendor's connector set and roadmap. | Bounded only by what you are willing to build. |
| Data control | Data transits the vendor. Fine for most, disqualifying for some. | Stays wherever you put it, including fully self-hosted. |
| Maintenance burden | Vendor absorbs model updates, uptime, infrastructure. | Yours. Model deprecations, prompt drift, monitoring, on-call. |
Read the last row carefully, because it is the one that most often decides the outcome and least often appears in the business case.
Where buying genuinely wins
The use case is common rather than differentiating. Support triage, meeting summarisation, document classification, lead qualification. Thousands of businesses need the same thing. A vendor has already solved the edge cases you have not encountered yet, and you are buying that accumulated learning.
Your integrations are mainstream. If the agent reads from Google Workspace, writes to HubSpot, and posts to Slack, every platform handles this. Building your own connectors to well-supported SaaS is work with no differentiating return.
Nobody on your side will own maintenance. This is the honest one. If you cannot name the person responsible for this system in eighteen months, buy. Vendor-maintained systems survive organisational neglect. Custom ones quietly degrade — a model version is deprecated, a prompt stops behaving, and there is no one watching.
You need to validate before committing. Buying to learn is legitimate and often smart. You discover the real edge cases at low cost, then decide.
Where building genuinely wins
The agent needs live state from a system no platform reaches. Custom order management, an internal pricing engine, a proprietary inventory model. Vendors integrate with what has market demand; your internal system does not have market demand. This is the most common honest reason to build.
Data cannot leave your infrastructure. Health records, financial data, anything under a residency requirement. Not a preference — a constraint that removes the buy option entirely.
The workflow is the differentiator. If how you handle this process is part of why customers choose you, encoding it in a platform every competitor can also subscribe to gives away the advantage.
Volume makes per-execution pricing painful. Platform economics that are comfortable at 500 executions monthly can become the largest line item at 500,000. Model the two-year curve rather than the first invoice.
The two risks each side actually carries
Buying: the integration ceiling. The failure mode is not that the platform is bad. It is that six months in you need one capability outside its boundary, and that capability is load-bearing. You then choose between a workaround that accumulates fragility, or a migration you did not budget.
Find your ceiling before signing. List every system the agent must touch, and ask the vendor to demonstrate each live. Not confirm. Demonstrate. "That is on the roadmap" and "you can handle that with a webhook" both mean custom work you will end up paying for.
Building: the ownership gap. Agents drift. Model providers deprecate versions, prompts that worked degrade as models change, and business processes shift underneath. A custom agent without an owner does not fail loudly — it gets progressively less accurate while everyone assumes it is fine.
Before approving a build, name the person, allocate the time, and decide whether that is in-house or retained. If you cannot do that, the honest answer is buy.
The sequence that usually works
For most businesses reaching this decision, buy-then-build is stronger than committing either way upfront.
Buy to validate. Run it for a quarter. You learn what the real edge cases are, what volume actually materialises, and where the ceiling sits — all at subscription cost rather than build cost.
What makes this sequence work rather than becoming an expensive detour is keeping three things outside the platform from day one: your prompts, your evaluation cases, and your integration logic documented as specifications rather than only as vendor configuration. Then if you build, you are porting knowledge rather than rediscovering it.
The brands this goes badly for are the ones who treat the platform as permanent from day one, configure everything inside it, and then find migration means starting over.
It is worth noting that building does not eliminate lock-in — it relocates it. A custom agent still depends on a model provider. What changes is depth: orchestration, prompts, evaluation and integrations are yours, so swapping models is a contained change rather than a rebuild.
Deciding
Four questions, in order. The first two are disqualifiers.
Can your data live on vendor infrastructure? If no, build. Decision over.
Does the agent need live state from a system no platform reaches? If yes, build. Decision over.
Can you name the person who owns this in eighteen months, with time allocated? If no, buy. Whatever the other arguments, an unowned custom system is a liability.
Is this workflow a differentiator or a commodity? Differentiator leans build. Commodity leans buy.
Most decisions resolve on the first three. The fourth breaks genuine ties.
If you want this assessed against your actual integration list, data constraints and team capacity — including an honest read on whether the use case needs an agent at all — book an architecture review. We build custom agents and we also implement on existing platforms, so the recommendation is not a function of what we are trying to sell you.
