Build versus buy is not a referendum on engineering taste. It is a decision about where you want to spend ownership: on the distinctive workflow, or on the machinery around it.

Buy the parts that are not your advantage

Managed identity, model routing, knowledge ingestion, conversation history, basic deployment, and usage controls are often useful foundations. Buying them can get a real workflow in front of users while the team learns what deserves custom work.

Build where the boundary matters

Custom work is justified when you need a proprietary decision process, unusual latency or residency, deep integration with systems of record, specialised evaluation, or a control surface a managed platform cannot provide.

Be honest about the bill that comes with that freedom: upgrades, security fixes, provider changes, observability, on-call, incident response, and the people who maintain the prompts and data contracts.

Use a hybrid boundary

A common answer is to keep the conversation and knowledge experience managed while your service owns sensitive actions. Or keep retrieval and policy enforcement custom while using a hosted interface for deployment and review. The right boundary follows the risk and the differentiation.

Ask the exit questions early

• Can you export content, prompts, transcripts, and configuration?
• Can you scope data, tools, and memory by user or tenant?
• Can you evaluate a change before releasing it?
• Can you disable one action without taking the whole agent down?
• Who owns support when the agent is wrong?

Prototype with the option that gets you to evidence fastest. Then move only the parts that have earned custom investment. “We might need it one day” is not a good reason to own a platform today.