Build or buy AI agents? A decision guide for platforms, low-code and custom.

Not two options but three

The build-or-buy question is decades old, but AI agents have changed the middle of it. Between the classic buy (a product that does the job) and the classic build (software written for you), a broad low-code layer has appeared, and the platforms you already own now ship their own agent builders. In practice you are choosing between three options, and often between combinations of them.

Option 1: Agents inside platforms you already own

Microsoft Copilot Studio, Salesforce Agentforce, SAP Joule, ServiceNow and HubSpot all offer ways to build agents that live inside their applications, with access to the data and workflows already there. The appeal is obvious: no new vendor, users are already in the tool, identity and permissions are inherited, and the first agent can be live in days. The catch is equally clear: the agent is good with the platform's own data and mediocre outside it, the model choices and evaluation tooling are the vendor's, and costs arrive as new licence tiers or consumption fees you do not fully control.

Option 2: Low-code orchestration

n8n, Make, Power Automate and Zapier let a technically minded team connect a language model to hundreds of SaaS tools through visual workflows. This is the fastest way from an idea to something that runs, and it is ideal for the long tail of small automations that would never justify a development project. The limits show as soon as the logic gets complex: branching, retries, evaluation and access control become hard to see and harder to test, and a workflow that grew over a year is rarely something you would call governed.

Option 3: Custom agents on your infrastructure

Frameworks such as LangGraph, CrewAI, the OpenAI Agents SDK and the Claude Agent SDK give a development team full control over the agent's logic, tools, memory and evaluation, running wherever you decide, including EU-hosted or on-premise infrastructure. This is where differentiating workflows belong: the processes that make your company what it is, where you want to own the data flow and the quality metrics. The price is engineering time, people who can operate what they built, and the temptation to rebuild what a platform already does well.

The comparison

When each option wins

The platform wins when the workflow already lives there

If the process runs inside Salesforce, SAP or ServiceNow, the users are already there, the records are there, and the vendor's agent can read and write them with inherited permissions. A sales assistant that summarises accounts and drafts follow-ups in the CRM, or a service agent that resolves standard requests inside the ticketing tool, rarely justifies a custom build. Standard process, standard data, standard agent.

Low-code wins for the long tail and for speed

Dozens of small automations across marketing, operations and administration, each saving an hour a week, are exactly what low-code is for. It also wins when you need to test whether an idea works at all before committing to a build, and when the team that owns the process is technical enough to maintain the flow. Keep these flows small, and keep the ones that grew up on a list for migration.

Custom wins where you differentiate, or where control is not negotiable

The workflows that define your business, complex multi-step reasoning across several systems, high volumes where consumption costs per case matter, strict requirements on where data is processed, and the need for real evaluation and observability all point to a custom agent. The same is true when the platform simply does not have the tools: an agent that has to read supplier PDFs, check them against a contract database and post to a legacy ERP will not come out of a platform builder. Our AI agent development service is built for this case.

Total cost of ownership: five dimensions

Licence prices are the smallest part of the difference. Compare the options on all five dimensions before you decide, and be suspicious of any option that scores well on only the first.

• Licences and consumption. Platform tiers, subscriptions, per-message or per-token fees. The platform option looks cheap at low volume and expensive at high volume; custom is the reverse.
• Integration. Connecting the agent to your systems. Free inside a platform, moderate in low-code, a real work package in custom, but reusable across agents when done through a standard such as the Model Context Protocol.
• Evaluation and quality. Test sets, quality metrics, regression testing. Rarely included in platforms and low-code tools, which means you either build it anyway or fly blind.
• Operations. Monitoring, incident handling, model updates, prompt changes, access reviews. Every option needs this; only the custom option makes you plan for it explicitly. Managed AI operations can cover it for any of the three.
• Change. Training, process redesign, works council involvement, documentation. Identical across options and usually underestimated by a factor that surprises everyone.

The hybrid architecture we usually recommend

In most companies the right answer is layered. The platform hosts the agent where the workflow, the users and the records already live: the CRM assistant stays in the CRM. Custom agents handle the differentiating work: the reasoning over your documents, your rules and your legacy systems, built and evaluated by you, running where your data policy says. Low-code covers the long tail of small automations and the glue between the two.

What makes this work is a standard way for the parts to talk to each other. The Model Context Protocol lets you expose your systems and your custom agents as tools that platform agents, low-code flows and other agents can call, so you build a connector once and use it everywhere. The agentic workflow engagements we run usually look exactly like this: a platform front end, custom reasoning in the middle, MCP connectors underneath.

A decision checklist

1. Does the workflow already live in a platform we own, with the users and the data there? If yes, start with the platform's agent.
2. Is this process something we differentiate on, or a standard process everyone runs the same way?
3. Where must the data be processed, and who may see the prompts and outputs? Does the option meet that requirement without exceptions?
4. How many cases per month, and what does the per-case cost look like at three times that volume?
5. Can we evaluate the agent's quality ourselves with this option, or would we be trusting the vendor's word?
6. Who will operate this in twelve months, and do those people exist in our company?
7. What does leaving look like? Can we export the logic, the prompts and the data?
8. What is the smallest version that proves the value, and which option gets us there fastest without painting us into a corner?

If you cannot answer the third and the sixth question, do not decide yet. Both are cheaper to answer in an AI readiness assessment than after a licence agreement.