Build, buy, or integrate? How to choose the AI agent platform

A company wants to respond to customer inquiries more quickly. They already have email, a customer relationship management (CRM) system, and a product catalog. A demo with an AI agent can summarize the message and draft an offer in a few minutes. But in production, the tough questions arise: can it see only the right customers? Who approves the discount? What happens if sending fails? Where is the proof kept? And who fixes the integration when the CRM’s API changes?

That’s why choosing an AI agent platform doesn’t start with the list of models or the flashiest interface. It starts with the specific process, the systems it needs to access, and responsibility for the final outcome. Depending on the answer, we can buy a ready-made feature, configure a visual platform, use a managed cloud service, or develop an agent within your own application. These options can be combined.

This article provides a decision framework for SMEs. It explains exactly what you are buying in each scenario, how to compare actual costs, which tests are worth requesting from the provider, and when a regular automation flow is enough.

Verified on September 27, 2026. The platform examples reflect the documentation available at this date; features, regions, and contracts may change. The figures in the calculation below are assumptions for a pilot, not market statistics.

The short answer

• If the activity is well-defined and the product you use already offers the necessary function, start by testing that feature. Check permissions, limits, and data export.
• If the process spans a few applications and the rules can be explicitly outlined, an automation flow with limited AI steps is often the easiest to control.
• If you need multiple tools, state between steps, approvals, and integration with your existing cloud infrastructure, consider a managed platform or a development framework.
• If your product is differentiated by its process logic, the rules are unique, and you have a team able to operate the software, building your own solution may be worth the investment.
• Regardless of the option, keep action authorization within auditable systems, test on your company’s scenarios, and calculate the total cost, including oversight and error correction.

This is a rule of thumb, not a universal product recommendation.

What do we actually mean by “agent platform”?

An AI agent combines a model that interprets a request with tools that read data or execute actions. A flow predefines the order of steps. In practice, many products mix the two: the model picks from several tools, and a deterministic flow limits when and how they can be used.

It’s worth separating five layers:

1. Model: the component that interprets and generates content. Its selection has its own criteria, discussed in the guide to choosing a large language model (LLM).
2. Orchestration: the rules that decide the steps, keep track of task state, resume execution, and send complex cases to a human.
3. Tools and data: connections to CRM, email, documents, databases, and APIs. Model Context Protocol (MCP) may standardize the exposure of some tools, but does not replace authentication, authorization, and business rules.
4. Controls: permissions, approvals, isolation, volume limits, logs, and incident response. These aspects are detailed in the article on permissions and audit.
5. Operation: hosting, updates, monitoring, backup, support, versions, and costs.

A code library can handle orchestration without providing you a complete admin application. A hosting service can run the code but cannot define your company’s commercial policy. A software product delivered as a service (SaaS) might offer an excellent interface, but allow few changes to the workflow. When comparing options, you need to ask explicitly which of these layers are included.

First filter: do you need an agent?

If you need to extract a field from a stable form and save it to a system, a standard rule can be cheaper and more predictable. For classifying various messages, summarizing documents, or suggesting a reply, a model can add value. But for actually sending the response or changing the price, keep a deterministic validation step and, where needed, human approval.

A simple test: if you can fully describe all steps and branches as stable rules, start with a workflow. If your input data is highly varied and the next step depends on their interpretation, add AI where the flexibility is worth the cost and risk.

Four implementation paths

Integration is not an exclusive fifth category. A company may buy a work interface, integrate workflows into an existing system, and develop only the tools that protect sensitive operations. Most of the time, wise decisions are about what we keep under our own control, not what we build entirely.

Aside from the four paths, decide where each component runs: the orchestration, model, document storage, and logs. An on-premise solution can still call an external model, while a hybrid setup could combine internal workflows with cloud services. Map the data flow and check costs, latency, access, and contractual obligations separately for each component.

We buy an existing function

Example: the team already uses a customer support product that can suggest answers from help articles. The potential advantage is integration with your existing users and tickets. However, check if the product respects each agent's permissions, whether it references response sources, how it handles attachments, and if you can export relevant history. Don’t pay for a separate platform before testing the function on your real-world cases.

We set up a visual workflow

Tools like n8n and Dify allows composing AI workflows and applications. n8n describes itself as fair-code: the code can be inspected, but its license restricts certain commercial uses. Check the licensing terms for your use case—do not assume it’s a permissive open-source license. Dify also documents installation via Docker Compose, which provides a self-hosting option. However, self-hosting means you’re responsible for updates, dependencies, and backups. If the workflow calls an external model, data sent to that model won’t necessarily stay within your local infrastructure.

These products can shorten the path to a pilot. For sensitive operations, check where credentials are stored, how action approval works, what part of the execution history can be exported, and what happens if an execution is resumed.

We use a managed service

At the time of review, Microsoft Foundry documents agent hosting, tools, observability, and evaluations; Gemini Enterprise Agent Platform brings together Google services for developing and running agents, including the components previously known as Vertex AI Agent Builder; Amazon Bedrock AgentCore documents components for the agent runtime environment, tools, identity, policies, and observability. These are service families, not identical offerings. Check the region, feature maturity, limits, required add-ons, and costs in your own contract.

One current note: AWS documentation states that Bedrock Agents Classic is no longer open to new customers. A guide or tutorial on the Classic variant may still be technically useful, but shouldn’t be treated as a procurement path for a new client.

Developing with a software framework

LangGraph offers mechanisms for stateful flows, interruptions, and resumption; OpenAI Agents SDK documents orchestration in your own application, tools, and approvals. These are developer components—not automatic guarantees for process security. Storage, access policies, testing, user interface, and operation may remain the team’s responsibility.

A framework is suitable when you already have your own applications and want the agent to work through narrow, testable APIs. Flexibility comes with the obligation to maintain the code, dependencies, and connector compatibility.

Three processes, three starting points

Support for an online shop. The system receives questions about delivery and returns. If your current support platform can already search the updated policy and suggest a response with source, test that feature. The agent can draft replies, but a human should review and send them in the first weeks. Track unresolved questions and cases where the return policy doesn’t cover the situation. Building a fully custom project is hard to justify until the limitations of the existing product are demonstrated.

Offers to other companies (B2B) from email, management (ERP), and CRM systems. Emails come in various formats, but prices, inventory, and discounts are found within your own systems. A graphical workflow or a small in-app agent can extract data, request completions, call APIs, and create a draft. Price calculation should remain in the ERP or in a service with explicit rules, and any external sending must have the proper approval. The main cost may be correct integration, not the model subscription.

SaaS product that provides automation to its clients. Here, each client’s identity, data isolation, and product experience are part of the commercial offering. An integrated software framework or a managed cloud runtime may fit better than a separate graphical workflow, since the team needs to control the interface, versions, and organizational access. Even so, they might buy components for hosting, evaluation, or observability, and only build the product-specific logic themselves.

These are design scenarios, not guaranteed outcomes. Volume, data quality, and existing infrastructure can change the choice.

How to choose based on process, not commercial promise

Write a one-page brief for the pilot process:

• Objective: what measurable result needs to be produced? For example, a correct draft offer—not “a smart assistant.”
• Inputs: what types of emails and documents do you see? In which languages? How often is data missing?
• Systems: what are the official sources for price, stock, contract, and client identity?
• Actions: what can the agent read, propose, modify, publish, send, or delete?
• Exceptions: what happens in case of conflicting data, response time expiry, duplicates, or accounts without permissions?
• Liability: who approves, who receives the alert, and who can stop the workflow?
• Volume and result: how many cases are there per month and how is quality measured?

If two teams describe the same commercial rule differently, acquiring the platform does not resolve the ambiguity. First stabilize the process and the source of truth.

Criterion 1: data and access rights

Ask whether the platform can query documents respecting each user's rights, whether it can separate clients or projects, and whether it can delete data from indexes, logs, and backups according to the applicable policies. A knowledge base or a retrieval-augmented generation (RAG) system must take authorization into account when reading, not just when uploading documents.

Check the data flow: from browser to platform, from platform to model provider, to the monitoring system, and to any subcontractors. “EU region,” “local installation,” and “data is not used for training” are distinct claims. Request the documents and settings that back each statement.

Criterion 2: tools and action control

A CRM connector is not enough. It should allow you to “read client X” without enabling “export all clients,” must validate the price before the offer, and require approval before sending. For a tool accessed via MCP or API, effective control must be enforced before the operation and confirmed by the destination system. OWASP Agentic Top 10 2026 provides a starting point for threat assessment.

Concrete tests to require: Is an unauthorized action refused? Does an expired approval no longer work? Can the agent change the recipient after approval? Does a malfunctioning tool halt the operation instead of producing incomplete results?

Criterion 3: flow reliability

A ten-minute demo won’t show how tasks resume after an error. Ask for proof of state retention, resumption, time limits, queues, a unique operation identifier (idempotency key) and a rollback path. The identifier helps the system recognize repeated executions of the same operation. An idempotent operation does not, for example, create two orders or two payments if the same request is resent. Without this safeguard, automatic retries can double the effects.

The τ-bench research tests agents in interactions with users, domain rules, and tools, and even measures consistency under repeated attempts. The results of that benchmark do not predict the performance of your implementation. They justify repeated testing of your own process, verifying the final state in the applications—not just the model’s formulated response.

Criterion 4: transparency and operation

Can you see, for a request, which data was accessed, which tools were invoked, what policy was applied, who approved, and what actually changed? Are there alerts for errors, abnormal costs, and denied access? Are test and production environments separated? Can you export traces without unnecessarily copying personal data?

Technical observability is not automatically a business audit. A model call trace does not prove the price was approved. The responsible person must be able to reconstruct the request path up to its impact in the destination system.

Criterion 5: team skills and time

A product can be configured in a day, but who will fix a connector in six months? An in-house solution may be flexible but depends on documentation, tests, and the people who know the code. Write down the hours available for design, operation, and support. A vendor with support and clear conditions may be cheaper than a poorly maintained in-house solution; in another scenario, internal code control may justify the investment.

Criterion 6: exit cost

Ask what can be exported: data, documents and metadata, flow definitions, prompts, rules, logs, configurations, and tests. Importing into another platform may require work even if there is a JSON export. A common protocol for tools reduces some of the repetition in integration, but does not guarantee portability of agent state, policies, or interface.

A good test is to ask the provider to export the pilot and document the steps for rebuilding it in a new environment.

What to specify in the contract and operating plan

Document who owns each connector and who is notified when it stops working. Set the response time and incident procedure for components managed by the provider, as well as who backs up and who tests restore. Request a description of price changes, usage limits, and how breaking API changes are communicated. If the provider only offers agent infrastructure, your team remains responsible for process logic and proprietary connectors.

An availability requirement expressed through a Service Level Agreement (SLA) should be read along with exclusions and dependencies. An agent can run on an available service but not complete the task if the ERP or the called model does not respond. Define behavior in case of degradation: delayed response, draft for operator, or fallback to manual process. Test this behavior before launch.

Confidentiality and compliance: contract questions

Before uploading real data, identify categories of personal data, processing purposes, roles of the parties, subcontractors, retention periods, access control, and deletion. Check the data processor agreement, where applicable, and map out international transfer paths. The European Commission explains the mechanisms and safeguards applicable to transfers outside the European Economic Area. A report drafted by external experts for the EDPB program proposes a methodology for privacy risks in systems with language models; the report does not necessarily reflect the official position of the EDPB.

Avoid the conclusion that a platform is compliant just because it is hosted in the EU. Execution traces, support services, the model provider, and connected tools may have different paths. Legal assessment depends on the actual data and process; this article does not determine the legal status of any product.

Calculate the total cost, not just the subscription

The meaningful calculation is implementation cost + monthly operating cost + cost of interventions and errors + platform switching cost. Include at least:

• flow and connector configuration, data migration, and authentication integration;
• license or subscription, hosting, storage, and backups;
• model calls, preparing documents for search (indexing), searching and reranking results by relevance, external tools;
• monitoring, logging, regression tests, and security review;
• time for approval, result review and correction, and exception handling support;
• incidents, updates, and the cost of replacing a provider.

Not all of these items are billed separately. A managed platform may include hosting but charge separately for the model or storage. A self-hosted solution can remove a subscription but still incur significant administration costs. Make comparisons on the same basis: total cost per correctly resolved request, at the same volume and level of control.

A rough estimate, with explicit assumptions

Suppose 1,000 requests per month, with five minutes of manual work for each. The initial volume is about 83 hours. In a hypothetical pilot, the agent prepares 700 cases for verification; the remaining 300 are done entirely by humans. If all 700 cases are correct but still need two minutes each for review, the time saved is about 35 hours, before accounting for support, exceptions, and maintenance: 700 × (5 - 2) minutes / 60.

This calculation does not show a positive yield. Platform, API call, and implementation costs are missing, and the quality of the 700 results must be measured. If evaluation finds 20 errors, each requiring 15 minutes to fix, that's another five hours lost. If review takes four minutes, the gross benefit drops to under 12 hours before errors. That’s why an impressive demo is no substitute for real measurement.

A selection matrix that doesn’t hide risk

Start with must-have conditions, then compare the remaining solutions. Possible conditions: an acceptable contract for the data used, sufficient permissions, ability to stop, export, maximum budget, mandatory systems integration, and availability in the required region. If a solution fails a necessary condition, don’t save it just because it scored well on interface.

For the rest, you can use this guidance matrix. The weights are working examples, add up to 100% and should be adjusted for your own process:

Give each criterion a score from 0 to 5 and multiply by its weight. For example, a 4/5 score on a criterion weighted at 20% contributes 0.8 points to a maximum total of 5. Don’t treat the score as an objective truth: two solutions can get the same total with very different risk profiles. Note down evidence, assumptions, and unverified concerns. For an agent that can pay invoices, security and action control will likely carry more weight than for an assistant that only prepares drafts.

The four-week pilot

Week 1: lay the groundwork

Choose a single process and describe the current state: working time, error rate, cost, and service level. Prepare a set of real, anonymized or synthetic cases, including rare scenarios: incomplete message, duplicate customer, expired price, wrong attachment, user without permission. Decide who determines if a result is correct, acceptance thresholds, and when the pilot should be stopped.

Week 2: build the useful minimum

Connect only the strictly necessary data and tools. Limit the agent to read/write or to a test environment. Place authorization rules inside the tool or control service, not just in the prompt. Define the max budget and the minimum required log.

Week 3: repeated and adversarial testing

Run the same set of cases multiple times. Measure the response and final state in CRM or the target system. Test documents and messages containing hostile instructions for the agent, following the risk model studied in AgentDojo. Don’t use real sensitive data in uncontrolled tests.

Week 4: decide based on the data

Compare two viable options on the same set, at equal volume. Check resolution rate, impactful errors, review time, latency, cost per resolved case, log quality, and recovery time after failure. Suspend the test if there’s unauthorized access, duplicate actions, or data leaks and fix the root cause before restarting. The process owner and, as needed, IT, security, and data protection teams validate the launch. Decide to launch with approvals, remain in proposal mode, or return to a non-autonomous workflow.

An acceptance threshold must be set before the test, for the specific process. There is no universal success rate that makes an agent safe for any company.

Questions worth asking in a commercial demo

1. Can you demonstrate—with a user who has no rights—that the agent can’t access a customer from another team?
2. Where do the request content, attachments, conversation, and logs end up? What can be deleted?
3. How do we approve a specific action, and how is approval invalidated if the data changes?
4. What happens when the CRM API responds after a timeout and the platform retries?
5. Can we inspect the version of the model, the instructions, the tool, and the rule involved in an incident?
6. Can we use a different model or provider without rebuilding all the tools? With what limitations?
7. How do we export flow definitions and test evidence, not just generated responses?
8. What is the cost at our volume, with all supporting services included?
9. Which functions are currently available in our region and plan, what is in preview, and what requires separate integration?
10. Who is contractually responsible for support, incidents, and API changes?

Request that these answers be demonstrated in the pilot. A features list in a presentation can show what's possible, but does not prove behavior in your process.

Frequent mistakes

Choosing based on the number of models or connectors. It matters whether that connector respects permissions and if it can perform the exact requested operation, with errors handled correctly.

Building an agent for a process that is still not well defined. The model will interpret misunderstandings between teams, making outcome evaluation impossible.

Considering self-hosting synonymous with strictly local data. Models, telemetry, connectors, and support must each be inventoried separately.

Allowing the agent to use an administrator account. A system instruction does not reduce the rights of an overly powerful token.

Counting only the time saved on drafting. Revision, errors, integration, and support can completely change the financial outcome.

Confusing a protocol with an exit strategy. MCP enables some connections, but migrating state, policies, and approvals remains a separate project.

What is stable now and what is still unresolved

By 2026, there are already documented options for visual flows, development frameworks, and managed cloud services. Principles such as least privilege, approval before sensitive actions, observability, and case-by-case evaluation are well documented. NIST AI RMF and the profile for generative AI provide a voluntary risk management framework without prescribing a specific provider.

However, variables remain: feature availability by region and plan, interoperability between platforms, agent quality for long-running processes, and the real cost of oversight. Research into tool interactions and attack scenarios shows important limitations, but cannot give a universal ranking for your company. Data from your pilot is more valuable than a general promise of autonomy.

Scenarios for 2027, not predictions

It’s plausible that providers will offer more standard components for agent identity, policy enforcement at the tool level, continuous evaluation, and trace export. It’s possible that some of the flows now built manually will be taken over by products already used by companies. Just as possible, though, is that differences in state, approval, and log formats will keep migration costs high. Plan contracts and architectures that support change, without budgeting based on a feature promised for next year.

Key sources and useful reading

Documentation and standards: NIST AI 600-1, OWASP Top 10 for Agentic Applications 2026, European Commission on international data transfers, external expert report from the EDPB program, MCP, specification from July 28, 2026 and OpenTelemetry conventions for generative AI.

Research: τ-bench on evaluating tool interaction and domain-specific rules, and AgentDojo on evaluating attacks through untrusted data.

Product documentation referenced, checked as of September 27, 2026: n8n, Dify, LangGraph, OpenAI Agents SDK, Microsoft Foundry, Gemini Enterprise Agent Platform and naming history, Amazon Bedrock AgentCore and AWS note regarding Bedrock Agents Classic.

Conclusion

The right platform is the one that solves a well-defined process at a justified cost, with controlled access and a capable team to operate it. For an SME, a good first decision might be to buy an existing function, to integrate two applications through a clear workflow, and to develop only the part where your own rules demand special control. Another company might need an agent built within its own application. Testing with real data, permissions, and results makes the difference.