Outsourcing Development of Your Agentic Architecture

Posted
By

A talent and knowledge gap in the AI space means many organizations are outsourcing the development and management of their agentic architecture.1

The structure of these engagements is as follows: Company A partners with Company B to use Company B’s skills, talent and know-how to create and manage a technological tool or set of tools, with varying degrees of customization and capability. Company B may sweeten the deal with their own unique methodology, platforms or proprietary pieces of the software stack. Company B may go away once the tools are developed, or they may be retained for managed services or lifecycle management and support. As a result of the transaction, Company A has a production-deployed tool poised to do a specific task or to function broadly throughout their IT environment.

The engagements they enter with third parties to do so take many forms, from software development or managed services agreements, collaboration partnerships, to a phrase coined by Palantir (and more recently proliferated by other foundation model providers): a “forward deployed engineering” effort. Call it what you want, but this looks pretty darn close to a plain vanilla outsourcing of the development and lifecycle management of IT architecture. And yet, as these engagements become more common, everyone is treating them like a magical new unicorn.

Is there a case for treating these deals differently than other outsourcing engagements? Perhaps. It certainly is true that agentic AI poses new and interesting challenges as compared to other types of SaaS products and generative AI tools. But even so, there are effective practices of software development outsourcing that we shouldn’t lose sight of.

The Argument for Special Treatment

The Technology Is New
While companies have been experimenting with large language models (LLMs) for a few years, agentic AI only started to feel broadly deployable once MCP connections and similar connector frameworks made it easier for models to interface with the rest of the enterprise software stack.

Because the technology is novel, projects to develop custom tools or complicated connections require highly specialized, qualified talent to bridge the customer’s unique business needs with the technology’s unique capabilities. But those embarking on these projects are faced with a paucity of available resources. ManpowerGroup’s 2026 survey of 39,063 employers across 41 countries found that AI skills are now the hardest to find globally, with 72% of employers reporting hiring difficulty, and ranking AI application development and AI literacy among the hardest-to-fill skills.

Development Requires Upfront Discovery
The parties may know the desired business outcome of these engagements but not yet know the technical path to get there. In some cases, the parties may even lack certainty that the outcome is achievable. Even if a tool is built, standard criteria (e.g., uptime, latency, etc.) may not be the right metrics to define success.

As a result, the contract may contain a thin or no scope description, broad aspirational objectives and a large price tag. Traditional outsourcing agreements work best when the parties define scope and success criteria with some precision. But with agentic architecture development, a certain degree of discovery and preplanning is required in order to assess feasibility or determine scope.

Pressure to Deploy Is High
The business pressure around these tools is unusually intense. Boards are asking about AI strategy. CEOs want to show that the company is moving quickly. Business teams are hearing that competitors are already testing agents. Vendors are offering “take it now” (without negotiation) or “leave it” (for your competitor to use instead) terms. In some cases, the press release, executive announcement or board approval happens before the contract is signed or before the scope is meaningfully understood. The immense pressure can compress the procurement, legal/governance, security and technology review processes.

The Architecture May Rely On and Create Proprietary Elements
“I own what I bring, you own what you bring, we co-own whatever we jointly develop”—said every naively optimistic stakeholder that hasn’t spoken to their IP attorney yet. That model rarely works, and it especially doesn’t work for development of agentic architecture.

Providers frequently suggest embedding their own proprietary tools in the customer’s environment, such as platforms, connectors, templates, agent frameworks or evaluation tools. They may be what allows the provider to move quickly. They may also be what makes the resulting architecture difficult to separate from the provider. And, if the provider is the creator of foundation model, the customer may be told that the build has limited or no portability to other models.

The relationship may also create new materials for which ownership is hard to classify. The parties will need to decide who owns prompts, system instructions, tool configurations, agent workflows, evaluation methods and results, logs, usage data, feedback data, fine-tuning data, model customizations, test cases, reports, unique outputs, and more. Some of these may reflect the customer’s confidential business processes. Some may be improvements to the provider’s services. Some may blend both.

In a forward deployed engineering model, knowledge often concentrates in the engineers embedded with the customer. If they rotate off the project without a structured handoff, the customer may technically own the deliverables but still be unable to operate them independently.

Specialization as a Differentiator
We know that industry- or customer-specific data and customization is what makes AI tools function the best. Inherent in creation of “the best” agentic architecture is deep knowledge and understanding of a customer’s IT architecture, or special way of doing business.

That specialization can be highly sensitive. Consider a tax advisory firm that hires a provider to build an AI tax agent. The tool would, in theory, support the firm’s specialized way of giving tax advice: how it spots issues, frames risks, weighs authorities, structures deliverables, communicates uncertainty and applies judgment. If the provider’s engineers help codify that method, the customer will not want those same engineers to turn around and build a similar tool for the advisory firm across the street using the same playbook. The result is a cross-functional risk to competitive use, residual knowledge and personnel. In agentic architecture engagements, the line between general know-how and customer-specific competitive advantage can be difficult to draw.

No Market-Standard Risk Allocation
Agentic AI can take actions across environments in a way that a standard LLM could not. Those actions are driven by a model that, at times, can be unpredictable. The logic and decision-making are opaque, at best. That makes these tools different from a traditional application that generally does only what it was coded to do.

The combination of autonomy, unpredictability and lack of transparency creates a different risk profile for which the market has not yet settled on a standard way to allocate the risk across the parties. Provider paper varies wildly: Some disclaim all responsibility for agent actions, some accept liability only for the orchestration layer, and a few will stand behind defined outcomes at a price. There is no equivalent of the mature allocation patterns that exist for SaaS availability or data breach. For now, each deal writes its own rules.

Outsourcing Best Practices, Adapted for Agentic AI Outsourcing
As evidenced, these engagements do present novel problems. The technology is new, the scope is fuzzy, the timeline is compressed, and the ownership questions are messy. But many of the problems are not without precedent; they are versions of issues that software development and outsourcing agreements have been solving for years.

Talent Management
Because the success of these engagements often hinges on whether the provider can retain and manage the right team, the contract should address talent management directly. The agreement can borrow familiar outsourcing tools here. These include:

    • Commitments to minimum skill levels, requirements for ongoing education and training, and obligations to staff the project with personnel who have relevant experience with the customer’s industry, use case or technological infrastructure.
    • For critical roles, requiring named key resources, retention commitments, notice obligations before reassignment, and approval rights over replacements.
    • Knowledge transfer as an ongoing obligation. Documentation should be created throughout the engagement. Replacements should be trained before outgoing personnel depart, at no additional cost to the customer and without material impact on the timeline.

Phased Deployment and Milestone-Based Payment
In many cases, the most valuable work at the beginning of the engagement is figuring out what should be built. That does not mean the contract should be vague about what is to come. Undefined scope is one of the oldest solved problems in IT outsourcing. The industry answer was structural: Separate discovery from build, and incentivize progress via the payment structure.

The contract should provide for a paid discovery or assessment phase that produces the scope as a deliverable. That phase should result in a detailed project plan, technical architecture, customer dependencies, assumptions, acceptance criteria, timeline, and even a pricing model.

If the result of discovery is finding that the proposed build is not feasible, not commercially reasonable, or not aligned with the customer’s objectives, the customer should be able to cut their losses. The provider should be fairly paid for the discovery work, but the customer should not be beholden to a large build commitment before the parties understand what they are building.

The fee model should reinforce that structure. Capped time-and-materials pricing may be defensible during discovery, where the effort is genuinely uncertain. It is harder to justify during build, after the provider has enough information to prepare its own plan. Once the provider has completed discovery, the commercial model should shift to milestone-, deliverable- or outcome-based pricing tied to completion and acceptance. A provider unwilling to price against its own project plan is telling the customer something (not good) about the plan.

Stopping the Clock
There is not much a contract can do to eliminate market pressure. But we have seen this movie before. Cloud transformation created pressure not to be the last company stuck on legacy infrastructure. Crypto and blockchain projects created pressure not to miss the next platform shift. In both cases, some companies moved thoughtfully, with disciplined contracting and governance. Others treated speed as paramount and later discovered that they contracted for bad outcomes. Agentic AI is not exempt from that pattern. Rushing the diligence process moves the hard issues (like security, privacy, intellectual property, service levels, liability or exit process) to a worse point in the lifecycle, after the customer has lost the leverage either from sunk cost, or if the business has started to depend on the tool.

The old adage still applies: fast, cheap, good—you can only pick two. Customers should decide, deliberately, whether cutting a deal quickly is worth sacrificing a cost-effective, or even a successful, outcome.

Match the Contracting Model with the Ownership Model
There are many ways to allocate ownership of the assets created in these engagements. There is not necessarily one “right” one. But the contracting model should match the ownership model the customer actually wants.

A collaboration agreement suggests mutual benefit. That may support joint ownership, ownership by one party with a broad license to the other, or some other shared commercialization model. A pilot agreement often suggests provider benefit, especially where the customer receives discounted or free services in exchange for data, feedback, product learning or market access. A services relationship usually supports customer ownership of deliverables. A staff augmentation model implies that the provider is supplying people, not any committed outcome. It works best if the right pathway is agreed upon in advance, rather than surprising one party or the other when a lengthy IP provision does not measure up to expectations.

In addition to clear ownership allocation, the Agreement should also address use rights. A customer that owns a workflow but cannot use the provider’s orchestration layer may not have received a portable asset. A provider that owns a framework but cannot use any learning from the engagement may have accepted more restriction than it intended.

The agreement should also tighten the residual knowledge clause. Providers often want the right to use learnings retained in unaided memory. That concept is common in technology agreements, but it can become dangerous in agentic architecture engagements if drafted too broadly. The clause should preserve legitimate general know-how while making clear that it does not permit use or disclosure of the customer’s confidential information, trade secrets, data, workflows, competitive strategies, or customer-specific implementation details. Further, residual knowledge clauses were written for humans, not models. In these engagements, “residual knowledge” may also mean what the provider’s models learned from the customer’s data.

In FDE-style engagements, knowledge concentration is also an exit risk. The engineer learns the customer’s business from the inside. That learning lives partly in the documentation, partly in the code, and partly in the engineer. The customer should therefore connect its ownership position to operational rights: documentation, transition assistance, access to source materials, license rights, portability commitments, disengagement support, and post-termination cooperation.

Enforceable Competitive Restrictions
The specialization that makes an agentic architecture valuable may also make it sensitive. In some cases, that knowledge gained from the engagement may be more valuable than the code itself.

Customers should therefore consider competitive protections that fit the engagement. A broad non-compete may be difficult to negotiate—and in some jurisdictions difficult or impossible to enforce—but that does not mean the customer has no tools. The agreement can include targeted restrictions on using customer materials, customer data, customer-specific workflows, prompts, configurations, evaluation sets, documentation and other protected materials for the benefit of competitors. It can also restrict the provider from reusing deliverables or derivative materials that embody the customer’s confidential business processes.

Personnel-based protections may also be appropriate. The customer may want restrictions on assigning the same provider personnel to a direct competitor for a defined time period, particularly where those personnel have had deep exposure to the customer’s sensitive workflows or strategy.

Align Risk and Control
Traditional outsourcing agreements often allocate risk based on control. The party that controls the decision usually bears the consequences of failures. That same principle can help structure agentic architecture agreements.

If the provider controls the model, platform, or managed service, the provider should stand behind failures in those areas. If the customer controls the various elements, the customer should expect to retain responsibility for those areas. Shared control often ends in finger-pointing, and should be avoided.  For example, if the architecture runs in the customer’s environment, the provider may not be able to take full responsibility for availability service levels tied to the customer’s infrastructure. But if the provider manages operation of the agent, the provider should not disclaim responsibility for service failures caused by its own operational decisions.

The agreement should also connect risk allocation to governance. If the customer must approve certain actions before the agent can take them, the contract should say so. If the provider must maintain human-in-the-loop review for defined workflows, the contract should say so. If the customer assumes the risk of expanding the tool to new use cases without provider validation, the contract should say so.

“Outcome-based pricing” is often used as a commercial risk allocation tool in these engagements. Outcome-based pricing is when the provider is paid per successful completion of the agreed task.  The trouble with this pricing model is that it makes the provider’s compensation contingent on the customer’s environment and business controls, which may divorce commercial risk from operational control. Take a company that hires a developer to build an agent for its internal IT help desk. If the developer is paid per ticket the agent resolves, the developer’s revenue now depends on variables the customer controls such as the quality of the knowledge base the agent draws on. That inverts the principle that risk should follow control. Outcome-based pricing may work, if the agreement supports that the provider controls the inputs, the metric is measurable, customer dependencies are carved out, and gaming risk is addressed.

Conclusion
Building agentic architecture is decidedly complex. But outsourcing that build to a third party is still, at its core, a sophisticated outsourcing arrangement involving emerging technology and evolving risk. In these engagements, the deployment of familiar contractual principles can ensure a more durable business outcome.

Customers can move quickly and still negotiate with discipline. They can embrace experimentation without buying a black box. They can give providers room to innovate without letting them own the learning or disclaim all of the risk. In fact, the companies most likely to capture value from agentic architecture deployment strategy will be the ones that use the contract as part of the strategy itself.

1 For the purposes of this article, “agentic architecture” means infrastructure that allows a customized AI agent, developed for a particular business process, use case or workflow, to operate in a customer’s technology environment. Agentic architecture can include both the deployed agent and the environment-specific framework required to make that agent function (e.g., data lakes, connectors, APIs, etc.).

RELATED ARTICLES

MCP Toolkit: Practical Questions You Should Ask Before Enabling an MCP Connection

MCP Connectors: Mitigating the Risks of AI Agents in a Connected Architecture

Model Context Protocol (MCP) and Connectors: A Primer