Product & Strategy
MDX
Build vs Buy for Agent Platforms
Decide what to own across models, orchestration, tools, memory, evaluation, observability, and governance.
Editorial review: clarity, operational relevance, safety boundaries, and source quality.
Own the differentiating workflow
Your task definitions, domain tools, data contracts, evaluations, and user experience often contain the real product advantage. Keep them portable even when infrastructure comes from a vendor.
Keep domain advantage in portable assets: task contracts, tool interfaces, policy checks, evaluation cases, traces, and user experience. A vendor can run models or queues without owning the meaning of a valid customer action. This boundary preserves leverage and makes quality comparable across platforms.
Buy commodity infrastructure
Managed model access, tracing, queues, and storage can accelerate an early product. Evaluate operational maturity, export paths, security controls, and pricing under multi-step workloads.
Evaluate managed platforms using representative multi-step workloads, not feature lists. Test identity and access, regional data handling, trace export, retention, model choice, queue durability, human approvals, incident controls, latency, and total task cost. Verify how the platform behaves when tools time out or writes are uncertain.
Plan for change
Models and frameworks evolve quickly. Use clear internal interfaces so a provider or orchestration layer can change without rewriting the product's core logic.
Build abstraction only around dependencies you expect to change. A thin internal interface for model calls, tool registration, and trace export is usually enough; a universal agent framework can become its own maintenance burden. Plan migration by testing whether prompts, tool schemas, and histories export in usable form.
Practical example
A pragmatic split
A team buys hosted model access, tracing, and durable execution, but owns its claims tools, authorization service, evaluation suite, and task-state schema. It runs the same golden set against a second provider quarterly. When pricing changes, the team can move selected model steps without redesigning approval or claims logic because vendor boundaries are explicit.
Field checklist
Apply it in practice
- Identify which layers contain domain differentiation.
- Benchmark vendors on complete, failure-prone tasks.
- Verify data, trace, prompt, and schema export paths.
- Keep internal abstractions thin and evaluation-backed.
Decision framework
Questions to answer before you build
Buy commodity infrastructure when it accelerates delivery, but retain ownership of task contracts, domain tools, policy enforcement, evaluations, and the user experience that differentiates the product.
Which layer creates advantage?
Separate model hosting, queues, and tracing from domain actions, data contracts, quality standards, and workflow design.
Has the vendor been tested on real trajectories?
Benchmark failures, retries, data controls, exportability, observability, latency, and completed-task price—not feature checklists.
What is the exit path?
Keep thin internal interfaces and confirm prompts, schemas, traces, histories, and artifacts can be exported in usable form.
Common failure signals
Watch for these warning signs
- Building a universal internal platform before one task works well.
- Letting vendor-specific abstractions leak into every domain tool.
- Comparing per-token prices instead of multi-step production workloads.
Selected primary references
Continue with the source material
These sources inform the wider editorial perspective for this topic. They are not presented as line-by-line citations for every statement.