- Home
- AI agents
- Platforms and frameworks
- Build vs buy
Build · Platforms and frameworks
Build vs buy for AI agents: SaaS agents, platform-built or custom code?
Build vs buy for AI agents is a choice among three routes: buy an agent embedded in software you already run, build one on a cloud agent platform that supplies runtime, identity and policy as services, or write custom code on your own compute. The route depends on where the data lives, who maintains it and how you will leave.
In this guide: 83 pages
Key takeaways
- Buy when the agent acts inside one system of record you already license, such as Agentforce in Salesforce or ServiceNow AI Agents; the data, permissions and workflow are already there. Cross-system work needs a platform or a second product.
- Build on a platform when the agent needs your own data and identity across systems; Microsoft Foundry, Amazon Bedrock AgentCore and Gemini Enterprise Agent Platform supply isolation, identity, gateway, memory and evaluation so you do not. Lock-in moves to those managed parts.
- Write custom code on your own compute only when portability or control is worth building session isolation, identity, policy, observability and durable execution yourself.
- Total cost is driven by tokens and loops, platform meters, tool calls, hosting, evaluation and observability overhead, and the people who run it. The FinOps Foundation’s rule is to measure cost at the use-case level rather than per token.
- Plan the exit before the first agent ships: logic in framework code, MCP and A2A at the edges, exportable traces and evaluation sets, memory you can delete.
What are the three options, really?
The three options differ in who runs the building blocks: the SaaS vendor runs all of them inside its product, the cloud platform runs them as services you assemble, and with custom code you run them yourself. The table gives examples, strengths and watch-outs for each as of 2 Nov 2026.
Build vs buy: the three routes with examples, strengths and watch-outs.
| Route | Examples | Strengths | Watch-outs |
|---|---|---|---|
| Buy: embedded SaaS agents | Salesforce Agentforce, ServiceNow AI Agents, Microsoft 365 Copilot agents and Agent Builder, Copilot Studio for Microsoft 365 work | Data, permissions and workflow already live there; the least setup before users see it; the vendor runs the runtime, identity and audit | Scoped to that vendor’s system; consumption pricing (Flex Credits, Copilot Credits) is hard to forecast; cross-system tasks need A2A, MCP or a second platform |
| Build on a cloud agent platform | Microsoft Foundry Agent Service, Amazon Bedrock AgentCore, Gemini Enterprise Agent Platform, Claude Managed Agents (beta), OpenAI Agents API (public beta) | Managed isolation, identity, gateway, memory, evaluation; accepts open-source frameworks; enterprise networking and regions | Lock-in moves to the platform layer (identity, gateway, memory and registry APIs); preview features carry no SLA; region availability varies by component |
| Custom code on your own compute | LangGraph, Microsoft Agent Framework, Strands, Google ADK, CrewAI or the Claude Agent SDK on containers or Kubernetes, with Temporal, Durable Task or Step Functions for durability | Full control and portability; any model; no platform meter | You build session isolation, identity, policy, observability, evaluation and durable execution yourself, and you keep them patched |
Microsoft’s Cloud Adoption Framework frames the same decision as a tree: does a SaaS agent meet the functional requirements? If yes, adopt it; if not, build on Foundry or Copilot Studio or on custom infrastructure. The tree covers Microsoft options only, and the same logic holds on AWS and Google.
What drives the total cost?
Six things drive the cost of an agent, and the model tokens are only the first: tokens and loops, the platform meter, tool calls and gateways, hosting, evaluation and observability, and the people who run it. None of them is a fixed number, which is why vendor price lists mislead on their own.
- Tokens and loops. APIs are stateless, so every turn resends the history and session cost grows faster than the number of turns; the FinOps Foundation calls context window creep "the biggest hidden cost in most production AI applications". Agents make many model and tool calls per request, reasoning tokens are often billed as output, and Anthropic reports that multi-agent systems use about 15 times the tokens of a chat. Microsoft’s own Copilot Studio example shows one follow-up message costing 141 Copilot Credits with a warm cache and 461 when the same question starts a new conversation.
- The platform meter. Copilot Studio bills Copilot Credits per answer, action, grounding call and reasoning token, and blocks agents at 125% of prepaid capacity unless pay-as-you-go is attached. AgentCore bills Runtime per second of CPU and memory with CPU scaling to zero during I/O wait, Gateway per invocation, Policy per authorization request and Evaluations per token. Agentforce meters Flex Credits, per resolution or per user. OpenAI has billed hosted sandbox compute per active turn since 9 Oct 2026. Per-user control planes such as Agent 365 add a cost per seat.
- Tool calls and gateways. Every tool call is a gateway invocation, a policy check and often a downstream API charge. An agent that checks three systems before answering costs three times the gateway spend of one that checks one.
- Hosting and durability. Hosted agents pay for container compute; waiting for a human in a running container is paid time, which is why durable suspend (Lambda durable functions, the Agent Framework Durable Extension) exists. Provisioned capacity bills whether or not tokens flow.
- Evaluation and observability. Each evaluation run is itself model usage, and online evaluators sample production traffic. Trace storage and the protected telemetry tables add ingestion and retention charges. Budget them as a share of agent spend, because an agent without them cannot be released.
- People. Someone owns the registry record, the evaluation set, the policy rules and the monthly reconciliation. A platform reduces engineering, and it does not remove the operator.
Cloud budgets alert late and do not stop spend: Azure evaluates budgets every 24 hours, and AWS Budgets updates up to three times a day. Hard caps live in the gateway (Azure API Management token limits per key and period), in the platform (Copilot Studio monthly agent limits) and in code (step and loop caps). Report cost per successful outcome, as a distribution, before cost per token.
How do you limit lock-in and keep an exit?
You limit lock-in by keeping the agent’s logic, tests and evidence in formats you own and letting the platform supply only the managed parts. The 2026 retirements showed why: Bedrock Agents became "Classic" and closed to new customers on 30 Jul 2026, the OpenAI Assistants API shut down on 26 Aug 2026, Agent Builder shuts down on 30 Nov 2026, AutoGen was archived and Google ADK 2.0 changed its session schema.
- Keep orchestration in framework code (LangGraph, Agent Framework, Strands, ADK, the OpenAI Agents SDK) that more than one platform hosts, rather than in a vendor’s visual builder.
- Use open protocols at the edges: MCP for tools, A2A for agent-to-agent calls, OpenTelemetry for traces. A tool behind an MCP server moves; a tool wired into a proprietary action does not.
- Own the evaluation set and the acceptance criteria. They are the only objective test that a rebuilt agent behaves like the old one.
- Keep identity in your identity provider. Entra Agent ID, AgentCore Identity with your existing IdP, or Google Agent Identity bound to your IAM; never a shared service account that only one platform understands.
- Export memory and know how to delete it. Managed memory stores (AgentCore Memory, Foundry memory, Memory Bank) are the hardest part of a platform to leave and the part most likely to hold personal data.
- Keep a registry export. A record per agent with owner, identity, tools and approval state is what lets you rebuild an inventory on the next platform.
- Write the exit into the statement of work: data return, log export, deletion attestation and notice periods for feature retirements.
Which route fits which situation?
The route follows from four facts about the agent: where its data lives, who maintains it, whether it crosses systems and how much control the workload needs. The table sorts the common cases.
Decision table: situation, usual route and the condition that would change the answer.
| Situation | Usual route | What would change it |
|---|---|---|
| Customer service or sales agent acting on CRM records only | Buy (Agentforce or the CRM vendor’s agents) | It must also read documents or write to a system outside the CRM |
| IT or HR requests resolved inside ServiceNow | Buy (ServiceNow AI Agents) | The resolution needs actions in Microsoft 365 or an ERP as well |
| Employee-facing agent over SharePoint, Teams and Dataverse | Buy and configure (Copilot Studio or Agent Builder) | It needs a specific model, a virtual network or custom orchestration, which points to Foundry |
| Agent across ERP, documents and a line-of-business API in one cloud | Build on that cloud’s platform | The data sits in two clouds, which usually means two platforms and one registry per cloud |
| Long-running or multi-agent workflow with custom logic | Build on a platform with hosted code (Foundry hosted agents, AgentCore Runtime, Agent Runtime) | Portability or an air-gapped environment outweighs the managed parts, which points to custom code |
| Agent that must run on your own infrastructure or across clouds unchanged | Custom code with a framework and a durable execution engine | The team cannot staff isolation, identity, policy and observability, which points back to a platform |
| Pilot to test whether the workflow is worth automating | A low-cost route that reaches real users, with the exit tested | Never scale a pilot on a product that is closed to new customers or scheduled to shut down |
Whichever route you take, the controls are the same: one owner, one identity, a registry record, a policy point on tool calls, a trace of every run and an evaluation gate before release. The route changes who supplies them, and it does not change the list.
How do Microsoft, AWS and Google implement it?
Where each cloud sits on the buy-to-build range, as of 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Buy: embedded or no-code | Microsoft 365 Copilot agents and Agent Builder; Copilot Studio | Amazon Quick for business users (launch date unverified) | Gemini Enterprise with Agent Designer and prebuilt agents |
| Build on the platform | Foundry prompt agents (configuration) and hosted agents (your code) | AgentCore harness (configuration) and Runtime (your code, any framework) | Managed Agents API (preview) and ADK on Agent Runtime |
| Meter | Copilot Credits; per-call inference and tool use plus container compute on Foundry | Consumption per service: per second, per invocation, per authorization, per token | Agent Runtime and model usage; Provisioned Throughput as a fixed-term subscription |
| Hard cap | API Management token limits per key; Copilot Studio capacity block at 125% | AWS Budgets actions (data up to three times a day); step caps in code | Quotas and budgets; step caps in code |
Unit prices change often and are deliberately not quoted here; read each vendor’s pricing page on the day you model a workload.
Frequently asked questions
Is it cheaper to build an AI agent or to buy one?
Neither in general. Buying tends to cost less when the agent works entirely inside a system you already license, because the runtime, identity and audit come with it. Building adds engineering cost up front and replaces per-seat or per-resolution pricing with a usage meter, so the answer depends on the workload. Model cost per successful outcome for your workflow before you decide.
Does a cloud agent platform remove lock-in?
No, it moves it. The framework code is portable; the managed parts are not: memory stores, registry records, policy rules, identity bindings and the gateway configuration. Keep the logic, tests and traces in open formats and treat those managed parts as the migration cost.
Should we build our own agent platform on Kubernetes?
Only if portability or an isolated environment is worth building session isolation, identity, policy, observability, evaluation and durable execution yourselves, and staffing them. For most enterprises in 2026 that is a worse trade than using a cloud platform and keeping the agent logic in framework code.
How do we stop an agent from running up a bill?
With caps that act in real time, because cloud budgets alert hours to a day late. Put token quotas per key in the gateway, set per-agent limits in the platform, cap loops and steps in code, and alert on token metrics from traces. Then review cost per successful outcome monthly rather than cost per token.
More in Platforms and frameworks
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- What is Microsoft Foundry Agent Service?
- AI agents: Cloud Adoption Framework
- Copilot Studio billing rates and usage management
- LLM token limit policy (Azure API Management)
- Create and manage budgets (Microsoft Cost Management)
- Durable Extension for Microsoft Agent Framework
- What is Amazon Bedrock AgentCore?
- Amazon Bedrock AgentCore pricing
- Managing your costs with AWS Budgets
- Amazon Bedrock Agents Classic maintenance mode
- Build multi-step applications and AI workflows with AWS Lambda durable functions
- Provisioned Throughput overview
- Gemini Enterprise Agent Platform overview
- OpenAI API deprecations
- OpenAI API changelog
- Agentforce
- FinOps for AI overview
- GenAI FinOps: how token pricing really works
- How we built our multi-agent research system
- Google ADK v2.0.0 release notes
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner