Build, buy, or blend: the investment decision

Buying means licensing a SaaS agent product - a support agent, an SDR agent, a coding assistant - that someone else built, runs, and improves.

• Time: days to weeks to deployment. The vendor has already made the thousand small decisions.
• Money: license fees typically run ~$50k-500k+ per year depending on seats and volume - often priced per conversation or per resolution.
• When it wins: when speed beats customization on a commodity use case - a problem shaped the same at your company as at a thousand others. Ticket triage, meeting notes, standard outreach.
• The cost you do not see on the invoice: lock-in. Your prompts, workflows, and accumulated tuning live in their product. Exit cost is a real number; ask for it up front.

Building means your team assembles the agent on a framework - LangGraph and its peers - and owns it end to end.

• Money, honestly split in two: the MVP costs roughly $15-50k of team time. The number budgets forget is the run-rate: ~$3.2-13k per month for tokens, infrastructure, monitoring, and continuous tuning. A build is a product with an operating cost, not a project with an end date.
• When it wins: when the agent IS the differentiator - it encodes how your organization works, touches proprietary data and processes, and would be worth less as everyone else's product. And when you have the team to own it (details in the self-study card in Part 2).
• What you get for the money: control. Your data stays where you put it, the roadmap is yours, and the governance stack from session a4 is built to your matrix, not the vendor's defaults.

The pattern serious organizations converged on: buy a vendor platform for commodity workflows, build custom for the differentiating ones. Not a compromise - a portfolio decision.

• The sorting question: for each use case, ask "would our version of this be meaningfully better than the market's?" If no - buy it and move on. If yes - that is build territory, and probably worth it.
• The discipline blend requires: a clear line. Organizations that blend badly build commodity things for pride and buy differentiating things for speed - the exact wrong assignment on both sides.
• What it means for skills: even a mostly-buy portfolio needs in-house capability to evaluate vendors, run evals, and own governance. Blend is not an excuse to skip building the muscle.

Vendors price per conversation or per resolution; builds cost a team plus tokens. Those two cost curves cross, and the crossover sits around one million conversations a year.

• Below the line: buy usually wins. The vendor's per-conversation fee is smaller than a standing team, and time-to-value arrives in weeks instead of quarters.
• Above the line: per-token build economics undercut per-conversation pricing - the same volume that makes vendor invoices painful makes a fixed team cheap per unit.
• How to use it: before any build-vs-buy meeting, get your realistic annual volume for the use case. Which side of ~1M are you on? That one number sets the burden of proof - whoever argues against their side of the crossover owes the room a reason.

MIT's GenAI Divide research found that bought or partnered solutions succeed roughly twice as often as internal builds. Sit with that: the default outcome of "we'll build it ourselves" is worse, at the population level, than writing a check.

• Why builds fail: not usually the framework. Underestimated run-rate, no eval discipline, teams staffed part-time, and use cases that were commodity all along - meaning the build never had a differentiation payoff to justify its risk.
• The leadership translation: BUILD is not the default it feels like to a proud engineering culture. A build proposal needs a reason (differentiation), a team (real, staffed, permanent), and evals from day one - or the base rate says you are funding the failure statistics.
• The caveat, honestly: the same MIT research carries a methodology caveat you will meet again in a6 - definitions of "success" vary and samples skew. Use the 2x as a burden-of-proof setter, not a law of physics.

If a build proposal reaches your desk, the team sheet matters more than the architecture slide. The credible minimum:

• 1-2 engineers who own the agent as a product, not a side quest - including the 2am circuit-breaker pages from session a4.
• A product owner who decides what the agent should do and holds the approval matrix.
• A part-time domain expert - the person whose judgment the agent is trying to encode, available for eval reviews every week, not just at kickoff.
• Eval maintenance as a permanent line item. Test suites rot as the business changes; someone owns keeping them honest, forever. If the plan has no name next to "evals", the plan is not real.

And the risk-side anchor for your spreadsheet: the average failed agent project runs around $340k once team time, licenses, and opportunity cost are counted. That is the number the build option has to beat on a risk-adjusted basis - not just the vendor's license fee.

LangChain the company gives away LangChain and LangGraph under the MIT license - genuinely free, forever. It makes money on LangSmith: the observability, evaluation, deployment, and compliance layer that wraps the free frameworks for production use.

• Translation: companies do not pay for agent logic - the market has made that free. They pay for trust and control: seeing what agents did (tracing), proving they work (evals), running them reliably (deployment), and satisfying auditors (compliance). Notice that this list is session a4's governance stack, productized.
• Why this matters beyond one vendor: it is the dominant model across the market. "Open-source core" companies monetize the operational wrapper. So when any vendor pitches you, locate the boundary - where does free end and paid begin?
• The question to ask every "open-source core" vendor: "If the framework is free, what exactly am I paying you for?" A good vendor answers crisply - trust, operations, support, compliance. A vendor who cannot answer is charging you for something you could have downloaded.