Build vs buy for enterprise AI agents
Buying gets you running faster. Building is the only route where your data, rules and approvals shape the agent.
The short answer
Buying a platform gets an agent running sooner, with vendor support and a standard way of working. Building gives you control over the data, the tools, the approvals and the evaluation. The decision turns on whether your workflow is standard enough for a platform, and whether your team can run what it builds.
Decision table
| Question | Build | Buy a platform |
|---|---|---|
| What it is | Your own agent, built on models and tools you choose | A vendor's agent product, configured for your use |
| Who owns the outcome | Your team, with the builders | Shared with the vendor, within the product's limits |
| Typical duration | Weeks to a first slice, then ongoing | Days to configure, then vendor release cycles |
| What you get at the end | A system you control, with its evaluation and runbook | A configured product and the vendor's roadmap |
| Main risk | Building what the team cannot run | Limits the platform cannot change |
| Best for | Workflows with unique rules, data or approvals | Standard workflows with a good fit to the product |
Use cases for build
- Approvals that match your policy. A claims or credit workflow where each action needs a named approver under your own rules. The approval logic is yours to design.
- Data that cannot leave your environment. A workflow that reads records the product would have to host elsewhere. Building lets the data stay where the policy requires.
- A workflow that differs from the market. Your process is unlike what products assume. Configuration cannot express it, so the logic has to be built.
- A capability you want to own. The agent is part of how you compete, and you want the know-how inside the company.
Use cases for buy a platform
- A standard service desk or document workflow. The process is common, the product covers it, and the fit is good enough to start.
- A pilot to test whether a use case is worth it. A buy decision lets you learn quickly before committing to a build.
- A small team with no capacity to run a system. If nobody can own the agent after launch, a vendor that owns the upkeep can be the safer choice.
- Integrations the product already supports. The systems you use are on the vendor's list, so the integration work is small.
Trade-offs
Build
Advantages. Full control of data, tools, approvals and evaluation. Can be shaped to your policy rather than the product's defaults. Know-how stays in the company.
Disadvantages. Needs people who can run the system after launch. Slower to a first answer than configuring a product. You own the upkeep, including model changes.
Buy a platform
Advantages. Faster to a first working answer. The vendor carries platform maintenance and model updates. Predictable scope for a standard workflow.
Disadvantages. Limits are set by the product, not by your policy. Data may need to be hosted under the vendor's terms. Switching later can be costly if the workflow outgrows the product.
How each option runs
Building, step by step:
- Step 1. Choose one workflow, the owner, and the data each step reads.
- Step 2. Build the first slice with approvals and an evaluation set from the start.
- Step 3. Hand over the system with a runbook, and set a review cycle for model changes.
Buying, step by step:
- Step 1. Shortlist products against the workflow's requirements, including data location and approvals.
- Step 2. Run a pilot on the owner's own examples, and score the results against the same test set.
- Step 3. Configure, integrate, and agree who handles vendor changes and incidents.
What drives the effort
- How much of the workflow is standard, and how much is specific to you.
- Where the data must be hosted, and who may read it.
- How many approvals and actions the agent must support.
- Who will run the system after launch, and for how long.
This site does not publish prices. The engagements page describes what each shape includes.
A checklist before you choose
- Does the workflow match what a product already does, without custom logic?
- Must your data stay in a location that a vendor cannot commit to in writing?
- Can you name the person who runs the system after launch?
- Would switching later be affordable if the product stops fitting?
If the first two are no and the last two are yes, buying is the usual start. If the first is no or the second is yes, a build is more likely to fit.
What people get wrong
- They pick a platform because it demos well, without testing their own data.
- They build something a standard product does better, then struggle to maintain it.
- They forget the upkeep. Model changes and approval rules need an owner in both cases.
A hybrid that often works
Buy a platform for the standard parts, such as the model access and the logging, and build the parts that carry your policy: the approvals, the data access and the evaluation. This keeps the upkeep with the vendor and the control with you.
Common questions
Is building always more expensive?
Not always. A build can cost less when the workflow is unusual and a product would need heavy customisation. Compare the total cost of running each option, not only the first delivery.
What should a vendor evaluation test?
Your own examples, scored against an agreed set. Include data location, approval handling and what happens during a model update.
Can I switch later?
Yes, if the agent's tools and data access are defined in your own terms. A tool contract written in your own terms makes a change easier.
Who should decide?
The business owner and the technical owner together, with the risk team consulted on data location and approvals.