You are a head of technology or a business function lead. Your team has been running experiments with agentic AI. The customer service chatbot pilot looks promising. Finance is testing an agent to accelerate month-end closing. The question is no longer should we use agents? It is where should our agents come from?
Build everything from scratch? Buy ready-made solutions from vendors? Partner with an external firm? Borrow open-source components to move fast?
This looks like a technology decision. It is not. It is a portfolio decision about control, speed, and differentiation. Get it wrong, and you either hand your competitive advantage to a vendor or spend years building infrastructure that never delivers business value.
The diagram makes visible what prose cannot: how sourcing decisions map to trade-offs, architecture layers, and portfolio management. Study it once, and the pattern becomes clear.
The Three Traps That Swallow Most Teams
Without a clear framework, organizations fall into three predictable traps.
Premature vendor lock-in. Agent solutions promise fast time-to-value. But when you hand over process logic, context data, and oversight to a single vendor, the exit cost becomes punishing. This is especially dangerous for workflows that become core to how your company operates.
Fragmented agent ecosystems. Every business function buys or builds its own agents. The result: inconsistent agent identities, overlapping tool integrations, different evaluation standards, and no unified governance. You do not get an agent-driven enterprise. You get agent chaos.
Endless build cycles. The opposite mistake. Obsession with building everything in-house keeps teams stuck in foundation mode. They build frameworks and platforms, but business use cases never reach production. In a fast-moving market, this is as dangerous as vendor dependency.
The solution is to treat agent sourcing as a portfolio decision. The question is not which option is best? It is which capability truly differentiates us? How sensitive is the data? How fast do we need value? How much control do we need long-term?
Build: When Control Is Your Competitive Advantage
Build makes sense when the agent touches a capability that is core to your competitive advantage, deeply tied to proprietary data, or requires full control over behavior and lifecycle.
Three areas where build is the right call:
Core business differentiation. If the agent runs logic that defines how you compete, buying it off the shelf is unwise. Think underwriting logic in insurance, proprietary pricing engines in distribution, or domain-specific operational intelligence in supply chains. The value is not in the AI interface. It is in the combination of internal data, decision rules, workflow exceptions, and operational learning that is unique to your company.
Sensitive data or critical controls. Build when the agent touches risk decisions, highly protected customer data, financial control logic, or operational intelligence that must not leave your boundaries. An agent that orchestrates material exception handling, combining internal policy, controller judgment, and audit history, is safer built on your own platform and governance.
Deep observability and policy control. Some workflows demand detailed explainability: what context did the agent use? What tools did it call? What decisions did it make? Why did it escalate? If auditability and runtime control are paramount, build gives you the freedom to embed policy engines, approval workflows, evaluation harnesses, and lifecycle management that meet your standards.
But build is not automatically the most strategic choice. It requires strong engineering, a clear agent platform pattern, healthy API integrations, mature data governance, model risk review, and an operating model for ownership and continuous improvement. Without these, build produces prototypes that never become operational.
Buy: Speed Comes with Strings Attached
Buy is right for capabilities that are relatively common, mature in the SaaS or enterprise platform market, and not a source of differentiation. Service desk assistants, CRM sales agents, employee self-service agents, and knowledge assistants often fit here.
The advantage is obvious: faster time-to-value. Basic integration, user interfaces, and some guardrails come built-in. For organizations that need to move quickly, this is compelling.
But speed comes with compromises. Control is limited. You may not be able to deeply customize reasoning, memory management, observability, or runtime policy enforcement beyond what the vendor offers. Many vendors promise configurability, but few genuinely support complex enterprise workflows with all their exceptions.
Auditability and data boundaries demand serious scrutiny before buying. What data leaves your environment? Where is context processed? How are logs stored? Can agent decisions be explained? How is access control applied? For regulated domains, these questions cannot wait until after the contract is signed.
Exit strategy must be clear. If a bought agent becomes critical to your workflow, can you export interaction data? Can configurations and prompts be migrated? Do tool integrations depend on proprietary formats? What happens if the vendor changes roadmap or pricing? Without an exit strategy, buy becomes structural dependency.
Partner and Borrow: The Realistic Middle Ground
Between build and buy lie two approaches that are often the most realistic for large enterprises.
Partner works when you know the value pool you want to pursue but lack mature implementation patterns or operational readiness. Partners can help build blueprints and reference architectures, co-develop the first agents, operate managed services for specific domains, or accelerate industrialization through delivery capability.
This is relevant for shared services, global capability centers, or functions that want to move quickly from pilot to operations. A GCC aiming to transform finance operations into an agentic model may not need to build everything from scratch. Partnering with a service provider can help design the operating model, build agents for AP exceptions and closing support, set up governance and observability, then transfer capability gradually to the internal team.
But partner does not mean handing over accountability. Contracts must be clear on IP ownership, data usage, operating model, SLAs, audit rights, and knowledge transfer plans. Otherwise, you are just moving dependency from a software vendor to a services vendor.
Borrow means leveraging open-source frameworks, reference architectures, starter kits, or community components to learn fast before formal platform decisions are made. Borrow is invaluable in early phases when you want to test orchestration patterns, understand tool calling needs, try context layers, or prove use cases without waiting for enterprise platform decisions.
A procurement team might want to test an intake agent that reads requests, checks policy, calls contract data, and prepares approval paths. To prove this pattern, the team can borrow open-source components and internal accelerators. If the results are promising, the capability can be migrated to the formal platform with stronger controls.
Borrow gives learning speed, but it has clear limits. Component quality and security vary. Long-term ownership is often unclear. Open-source dependencies can become hard to manage. Teams can get stuck on prototypes that never get hardened. Treat borrow as an exploration path, not a reason to delay standardization.
The Hybrid Reality: Managing a Mixed Agent Supply Chain
In practice, every large enterprise will end up with a hybrid agent supply chain. Some agents built in-house, some bought from SaaS, some co-developed with partners, some borrowed for experiments. This is not a problem. What is dangerous is when this mix grows without shared architecture and governance.
To manage a hybrid model, you need four things:
An agent registry. A catalog that records what agents exist, who owns them (business and technical), where they came from, what data and tools they use, their risk level, and their lifecycle status. Without a registry, you cannot manage your agent portfolio.
Interoperability standards. Agents from different sources must live in the same ecosystem. That means standards for identity, tool calling, events, logging, observability, and handoffs between agents or to humans. Without these, every agent becomes an island.
Risk-based classification. Not all agents need the same controls. A knowledge assistant is different from an agent that can trigger actions in your ERP. Classify agents by risk and business impact, then apply proportional controls.
Shared governance. Whatever the source, every agent entering operations must submit to the same governance: security review, data permissioning, evaluation, approval thresholds, observability, incident management, and decommissioning processes. Sourcing can differ. Enterprise standards cannot.
A Healthier Way to Think: Source by Layer
One use case does not have to use one sourcing strategy. Often the best decision differs by layer. Buy the capability embedded in your CRM. Build the orchestration and policy layer. Partner for initial implementation. Borrow for experimenting with specific context components.
The mature sourcing question is not which option? It is which layer is our differentiation? Which layer is already a commodity? Which layer needs acceleration? Which layer is still worth exploring?
In the end, a good agent sourcing strategy is not about picking one camp. It is about placing control, speed, and differentiation where they belong. Mature companies will not build everything themselves. But they will not blindly buy their future either. They will manage agents like a portfolio of enterprise capabilities, with the same architectural discipline, governance rigor, and accountability that any critical business capability deserves.
What this means in practice
For your next agent initiative, do not start with "should we build or buy?" Start with a quick portfolio analysis:
- Map the agent's workflow to architecture layers (orchestration, policy, tool integration, context, model).
- For each layer, ask: is this differentiating, commodity, or experimental?
- Source each layer accordingly—build the differentiating parts, buy the commodities, partner for acceleration, borrow for exploration.
- Register the agent in your catalog, classify its risk, and enforce governance regardless of source.
This layered approach prevents the all-or-nothing trap. You can buy a CRM agent while building the orchestration layer that enforces your company's unique approval policies. You can borrow an open-source context retriever while partnering with a service firm to industrialize deployment.
The architecture stays coherent because the governance layer is shared. The portfolio stays manageable because you know exactly what each agent does and who owns it.
This article was originally published on ariefwara.github.io.
Top comments (0)