When is buying a vertical agent the right call?

When the workflow is table stakes rather than a differentiator. Contract review is not where a fintech competes and test coverage is not where a marketplace competes. What you give up is the pass bar: you inherit the vendor definition of good, which is usually good, and when it is not you have opinions and no lever.

How should you choose an agent framework?

One model family in production, use that vendor SDK, because less abstraction means fewer bugs. Multi-vendor or self-hosted, use something with real state and checkpointing, which is why graph-based frameworks became the default for regulated work. Prototyping, use whatever reaches a working demo fastest and expect to discard it. The framework rarely determines the outcome; the eval suite does.

Buy a Vertical AI Agent or Build on an SDK?

Q: Should you buy a vertical AI agent or build on an SDK?

Reframe it as who owns the eval suite. If the quality bar is specific to your business you have to own the grading, and owning the grading pulls you toward building, because you cannot set a pass bar on a product whose behavior you cannot change. If the workflow is standard and someone has shipped it already, buy it.

Should you buy a vertical agent or build on an SDK? The question is usually framed as build versus buy. The better frame is: who owns the eval suite?

If the quality bar is specific to your business, you have to own the grading. Owning the grading pulls you toward building, because you cannot set a pass bar on a product whose behavior you cannot change. If the workflow is standard and somebody has already shipped it, buy it and stop.

Buy when the workflow is the product

There is now a serious vertical agent for most common jobs. Coding, terminal-native development, legal review, autonomous engineering tasks. Each represents years of workflow design that you would otherwise rebuild badly.

The test is whether the way your team does this work is a differentiator or just the way it gets done. Reviewing a contract is not where a fintech competes. Writing test coverage is not where a marketplace competes. If the workflow is table stakes, buying it is not a compromise, it is the correct allocation of a team that has more valuable things to build.

What you give up is the pass bar. You get the vendor's definition of good, and it is usually good. When it is not, you have opinions and no lever.

Build when the pass bar is yours

Building on an SDK means you own the prompts, the evals and the user experience, and the vendor owns the model and the runtime. That split is the whole appeal. You are not training anything. You are deciding what correct means in your domain and enforcing it.

This is the right call when being wrong is expensive in a way specific to you. A wrong answer about a customer's chargeback is not the same failure as a wrong answer about a recipe, and no general-purpose vendor is going to encode your definition of an acceptable error.

The cost is not the build. It is the eval suite, which is permanent work, has to sit in the release path, and does not get built by accident. I went through what that actually takes in Evals Are the New QA.

The framework choice is smaller than it looks

A handful of frameworks dominate and the selection rule is short. Running one model family in production, use that vendor's SDK, because less abstraction means fewer bugs and the agent-as-tool model collapses orchestration into tool use the model already understands. Multi-vendor or self-hosted, use something with real state and checkpointing, which is why the graph-based options became the default for regulated work. Prototyping, use whatever gets to a working demo fastest and expect to throw it away.

Teams spend weeks on this decision and it is rarely the thing that determines the outcome. The eval suite determines the outcome.

The third option nobody lists

Buy the agent and wrap it. Use the vertical product for the workflow, then own the grading layer on top: your scenarios, your pass bar, your gate on what reaches a customer.

You get the vendor's workflow investment and keep the definition of correct. It is the right answer more often than either pure option, and it is unpopular because it does not make a clean slide.

What actually kills these projects

Not the framework. Not the model. Access, permissions and the review burden, in that order, which is the same list that stalls internal automation and the same list I went through in Automate the Handoff, Not the Task.

A team that has chosen a framework and not chosen who approves the connection to the system of record has not started yet. That is the sequencing error, and the reason so many pilots look healthy for 6 weeks and then quietly stop being mentioned, which I looked at across the published surveys in Production Is an Org Problem.