AI Agents & Orchestration

43 MIN READ

Enterprise AI Agent Framework Selection: How to Choose the Right One

AI Agent Framework Selection is a quarterly decision, not a multi-year bet: price the exit across four lock-in vectors before you sign anything.

AI Agent Framework Selection sounds like an architecture decision you make once and defend for years. It isn’t. Enterprises now re-open the choice every quarter, because the orchestration layer they picked to future-proof their agents keeps getting absorbed, feature by feature, into the platforms they were trying to avoid.

Where this article sits

Journey stage 2 of 7: Use Cases

readiness → use-cases → roi → pilots → kpis → operationalize → scale

this articlelinkedjourney stagepillar

Your trail so far

The articles you visit light up on this map.

What AI Agent Framework Selection Decides, and Why the Horizon Is a Quarter, Not Years

AI agent framework selection is the choice of the orchestration layer, the reasoning loop, tool calling, memory, and multi-agent coordination, that an enterprise’s agents run on, a decision made separately from choosing the foundation model underneath them. Treat that choice as a multi-year architectural commitment and the enterprise gets it wrong twice: once by locking in an orchestration layer before the market has settled, and again by refusing to revisit it once the market moves anyway. The KPMG AI Pulse Survey recorded the share of organizations favoring a blended build-and-buy approach rise from 51 percent to 57 percent in a single quarter of 2026: the kind of shift a three-year roadmap has no mechanism to absorb.

That reframing changes what a decision memo, the document that carries the selection decision to whoever signs off on the budget, has to accomplish. It has to name which layer of the stack to buy, which gap is worth building over, how the exit is priced before a contract is signed, and on what schedule the whole scorecard gets re-run. Kai Waehner’s Trusted Agentic AI Landscape, refreshed for the third quarter of 2026, works as a reference for exactly this reason: it never claims to be permanent, so a memo that cites it is citing a snapshot, not a verdict, and the memo’s author is expected to update the citation next quarter.

Most comparisons blur the model-versus-framework distinction further by scoring both on the same three metrics, accuracy, latency, and cost, the dimensions Amazon Web Services documents as the default, and incomplete, starting point for foundation model evaluation. Framework selection asks a different question than model selection does: which orchestration layer survives contact with a workflow that gets rewritten every quarter, regardless of how well the underlying model reasons. An agent, in the sense this decision covers, is more than a chatbot wrapped in a system prompt: it needs memory to carry state across steps, tools to act on external systems, and routing logic that decides what happens next, the same distinction between a fixed workflow and a model that plans its own path that shows up throughout the practitioner literature on framework choice.

The Four Decisions a Framework Selection Memo Must Answer

A framework selection memo earns its name only when it commits to four separate answers, not one: which layer of the stack to buy, which gap is worth building over, how the exit gets priced, and on what schedule the whole decision gets re-run. Naming only the first, which vendor or open-source project to adopt, is the mistake that produces the shelf-life problem this guide exists to fix, because a vendor choice made in isolation ignores the fact that the vendor’s own roadmap will change what “buy” means within two or three quarters.

The second decision, which gap is worth building over, only makes sense once the first is settled: an enterprise that has bought a managed orchestration layer still has to decide whether a specific workflow, say, cross-session handover for a long-running agent, is missing from that platform today, and whether building it in-house is worth the maintenance bill that follows. The third decision, pricing the exit, has to happen before signing, not after a migration is already underway, because contract terms around data export and API access are far easier to negotiate before the ink dries. The fourth decision, the re-run schedule, is what turns the first three into a process instead of a one-time judgment call: a quarterly cadence, tied to the same reporting rhythm that produces board updates, keeps the answer current without requiring a crisis to trigger a review.

Quarterly Reassessment as the Operating Cadence

The KPMG shift from 51 to 57 percent in a single quarter is the clearest available evidence that the market itself, not just vendor roadmaps, moves on a quarterly clock. A six-point swing in preferred sourcing strategy inside three months means that any enterprise still running an annual technology review is working from data that is, on average, five and a half months stale by the time it acts on it.

Quarterly reassessment does not mean re-litigating the whole decision every ninety days from a blank page. It means running the same scoring model, the one built later in this guide, against updated inputs: new pricing from the vendor, a new capability shipped by a competitor, a new regulatory requirement from the compliance team. Most of the time, the re-score confirms the existing choice and the exercise takes an afternoon. The value is in catching the quarter where it doesn’t confirm the choice, before the gap between the current platform and the best available option has grown large enough that switching costs more than staying was ever worth.

The 2026 Framework Landscape: Open-Source Orchestration Against Managed Agent Platforms, Layer by Layer

The 2026 agent framework landscape resolves into four layers, foundation model, orchestration framework, agent runtime, and observability, and each layer carries its own lock-in profile, so comparing frameworks as a flat list of logos misses the decision that actually matters at every layer. Kellton’s 2026 layer table treats the foundation model as commodity, bought via API with model transparency and cost-per-token as the deciding factors, and treats the orchestration layer as the point where lock-in risk peaks, because that is where task decomposition, tool routing, multi-agent coordination, and state management all live behind one vendor’s or one project’s interfaces.

Open-Source Orchestration Frameworks: LangChain, LangGraph and AutoGen

LangChain, LangGraph, and AutoGen occupy the open-source end of the orchestration layer, and each answers a different version of the coordination problem rather than competing on the same feature list. LangGraph represents multi-agent workflows as a graph, with each agent as a node and the connections between them as edges, so control flow and state are explicit and inspectable rather than buried inside a single monolithic prompt loop; this graph representation is why LangGraph is often paired with a state-machine mental model rather than a simple pipeline. AutoGen takes a conversational approach instead: agents that are customizable and conversable, able to operate in modes that combine large language models, human input, and tools, with flexible interaction patterns defined in natural language or code: the framework that, at over 2,500 citations, is the most-cited paper in the multi-agent orchestration literature.

The reference architecture both frameworks implement traces back to the same three components Anthropic and independent researchers converged on separately: planning, memory, and tool use. Anthropic’s own multi-agent research system uses a lead agent that plans a research process and spins up parallel subagents to search simultaneously, exploiting the fact that subagents operating with their own context windows can compress a vast corpus faster than a single agent working sequentially. Lilian Weng’s widely cited breakdown of LLM-powered autonomous agents names the same three building blocks, planning with task decomposition and self-reflection, short- and long-term memory, and tool use through external API calls, as the components every framework in this category is, in effect, re-implementing behind a different interface.

LangChain and LangGraph in Production Multi-Agent Systems

LangGraph in production differs from LangGraph in a demo mainly in how much of the graph is dedicated to failure handling rather than the happy path: retry edges around flaky tool calls, human-in-the-loop nodes for approval gates, and checkpointing so a long-running agent can resume after a crash without replaying every prior step. Coordination and memory management sit at the center of what makes the framework production-viable, because a graph that cannot persist state across a multi-hour or multi-day workflow is not meaningfully different from a stateless chatbot with extra steps.

The practical consequence for a selection memo is that “LangGraph” as a line item hides a wide range of operational maturity depending on how much of that production hardening the adopting team has built themselves. An enterprise evaluating LangGraph is really evaluating two things at once: the open-source project’s own maturity, and its own team’s capacity to build the retry logic, checkpointing, and observability hooks that turn a graph definition into a system that survives a bad afternoon in production.

AutoGen’s Multi-Agent Conversation Model

AutoGen frames multi-agent coordination as a conversation between customizable, conversable agents rather than as a graph traversal, and that framing changes what a team builds first: message-passing protocols and turn-taking rules, rather than nodes and edges. Agents can be configured to operate autonomously, to defer to human input at defined points, or to blend both, and developers can program flexible interaction patterns using either natural language instructions or code, which lowers the barrier for teams whose engineers are not primarily systems programmers.

The conversation model earns its citation count because it maps cleanly onto how organizations already think about delegation among people, a manager agent assigning subtasks to specialist agents mirrors how a human team lead assigns work, which makes AutoGen a common first choice for teams prototyping multi-agent patterns before committing to a production architecture. That same familiarity is also the risk: a conversation-shaped abstraction can hide coordination bugs that a more explicit graph representation would surface immediately, so teams moving AutoGen prototypes into production tend to add the same explicit state tracking that LangGraph provides natively.

Managed Agent Platforms from the Hyperscalers and SaaS Vendors

Every major cloud vendor now ships a managed alternative to the open-source orchestration layer, and each one trades customization for velocity in a slightly different place. Amazon Web Services ties orchestration to the AWS ecosystem and its model catalog; on Google Cloud, Vertex AI’s Agent Development Kit and Agent Engine provide an open-source-flavored building framework paired with a fully managed runtime for deployment, testing, and release, and that runtime now sits underneath the broader Gemini Enterprise Agent Platform, which bundles model access to more than 200 models through its Model Garden with integration, DevOps, and governance tooling in one destination. Microsoft Copilot Studio and Salesforce’s managed agent runtime follow the same pattern on their respective platforms, and OpenAI’s answer sits at the API layer: its multi-agent capability lets a root agent spin up and coordinate subagents in parallel, synthesizing their work into a single response without the calling application having to implement its own orchestration logic.

The pattern across every managed option is the same trade: a root agent or platform console handles delegation, state, and synthesis, and the adopting team gets faster time-to-value in exchange for accepting that agent behavior, memory format, and tool-calling conventions all live inside the vendor’s interface rather than the team’s own code. OpenAI’s portfolio-collaboration reference implementation, where specialist agents covering macro, fundamental, and quantitative analysis are each called as a tool by a central portfolio-manager agent, is a clean illustration of the “agents as a tool” pattern that most managed platforms implement in some form; and also of how thoroughly that pattern couples an implementation to one vendor’s SDK, since every specialist agent in the example is invoked through OpenAI’s own tool-calling interface rather than a portable standard.

Amazon Bedrock Agents and Vertex AI Agent Builder

Amazon Bedrock Agents and Vertex AI Agent Builder both promise a managed orchestration layer sitting on top of a hyperscaler’s model catalog, but the depth of that management differs in a way that matters at evaluation time. Bedrock’s agent orchestration is tightly bound to Bedrock’s own model access patterns and account structure, so an enterprise adopting it is implicitly choosing AWS as the account boundary for every agent workflow it builds. Vertex AI’s Agent Development Kit is positioned as more open, the same framework underlies Google’s own Agentspace and Customer Engagement Suite agents, and sample agents are distributed through an open Agent Garden, while Agent Engine still provides the managed, secure runtime that handles testing and release.

For a selection memo, the practical question to ask is which platform an enterprise can walk away from tomorrow, regardless of which one has more features today. Bedrock’s binding to an AWS account and region is explicit and easy to price into an exit plan; Vertex AI’s openness at the framework layer reduces that specific risk while leaving the managed runtime itself, Agent Engine, just as tied to Google Cloud as Bedrock’s runtime is to AWS. Neither platform removes the lock-in question: each just moves where in the stack it lives.

Microsoft Copilot Studio, OpenAI Responses API and Salesforce Runtimes

Microsoft Copilot Studio, the OpenAI Responses API, and Salesforce’s managed agent runtime round out the managed side of the orchestration layer, and each binds the adopting enterprise to a different surface than Bedrock or Vertex AI do. Copilot Studio ties orchestration to the Microsoft 365 and Azure ecosystem, which suits an enterprise already standardized on that stack but adds a second, distinct lock-in surface for any organization running a multi-cloud strategy. The OpenAI Responses API takes the leanest approach of the three, exposing multi-agent coordination as an API primitive, a root agent creates subagents, waits for results, and synthesizes a final answer, without a surrounding console or account structure of its own, which lowers the switching cost specifically around vendor tooling while leaving the underlying model dependency untouched.

Salesforce’s managed runtime, by contrast, is built to sit inside an existing Salesforce deployment and inherits that platform’s data model and permissions structure directly, which accelerates adoption for a CRM-centric use case and raises the switching cost for any workflow that later needs to operate outside Salesforce’s data boundary. None of the three eliminates the lock-in question the layer table raises; each one answers it by naming a different account, ecosystem, or data boundary as the thing the enterprise is agreeing to depend on.

The Layer Table: A Default Verdict for Model, Orchestration, Runtime and Observability

A layer table gives a selection memo a single page that states, for each of the four layers in the stack, whether the default recommendation is to buy, build, or take a hybrid position: a structure that resists the temptation to answer the whole framework question with one verdict.

Layer	What It Covers	Default Verdict	Where Lock-In Concentrates
Foundation model	Reasoning quality, context window, cost per token	Buy via API	Low, most workloads tolerate model swaps with prompt adjustment
Orchestration	Task decomposition, tool routing, multi-agent coordination, state	Hybrid: open-source core + managed configuration	Highest, coordination logic and memory formats are hardest to port
Agent runtime	Deployment, testing, release, scaling	Managed where available	Moderate, tied to the vendor’s deployment and account model
Observability	Tracing, logging, cost tracking, evaluation	Buy, cross-model where possible	Low if the tooling is model-agnostic; high if it is vendor-bundled

A concrete illustration of what the orchestration layer saves when it is bought rather than built comes from a fraud-detection use case, where an agent monitors transactions, calls a scoring tool, evaluates the result against business rules, escalates flagged cases to a human reviewer, and logs every decision: built from scratch, that reasoning loop, tool calling, and memory management represent weeks of coordination code, while on a framework they are largely configuration, freeing the team to focus on the fraud-specific logic rather than the plumbing underneath it.

one question · 10 seconds

Quick one while the layer table is still in front of you: what is actually stopping you from putting any of these on a shortlist?

Exit Cost as the First Selection Criterion: The Four Lock-In Vectors and What Migration Really Rebuilds

Exit cost should be the first criterion in a framework selection decision, not an afterthought raised during contract review, because a choice that gets re-made every quarter is priced by what it costs to leave, not by what it costs to arrive. The Clarion Analytics CXO Decision Framework decomposes that exit cost into four measurable vectors, data residency, API dependency, model portability, and contract structure, and mapping a candidate framework against all four turns a vague worry about lock-in into a number a procurement lead can actually negotiate against.

The Four Lock-In Vectors: Data Residency, API Dependency, Model Portability, Contract Structure

Each of the four lock-in vectors maps to a specific artefact that has to move if the enterprise ever switches vendors, and the size of that artefact is what determines how expensive the move turns out to be. Data residency governs where the enterprise’s transaction logs, embeddings, and fine-tuned training data physically live and under whose jurisdiction; API dependency governs how tightly the calling application’s code is written against one vendor’s specific request and response format; model portability governs whether the prompts and evaluation harnesses built for one foundation model transfer to another without a full rewrite; and contract structure governs whether the commercial terms themselves, minimum commitments, data export rights, notice periods, make an otherwise technically feasible exit commercially painful.

Lock-In Vector	What Has to Move	Typical Exit Cost Driver
Data residency	Transaction logs, embeddings, fine-tuned weights	Data export tooling, cross-jurisdiction transfer rules
API dependency	Application code calling the vendor’s SDK	Rewriting integration and tool-calling code
Model portability	Prompts, few-shot examples, evaluation harnesses	Re-tuning prompts and re-running evaluation suites per model
Contract structure	Minimum commitments, notice periods, export rights	Negotiated exit fees, contractual lock-in periods

Indicative figures on switching cost as a share of annual contract value put model-behavior re-tuning at roughly 45 percent of the total, integration rebuild at around 35 percent, workflow and retraining at about 22 percent, data extraction and reload near 12 percent, and contractual exit fees at roughly 6 percent: a distribution that puts the two heaviest costs (model re-tuning and integration rebuild) squarely inside the API-dependency and model-portability vectors, not the data or contract vectors most lock-in guides focus on first (Progressive Robot, 2026). Advisori’s enterprise guide to AI vendor lock-in states the rule of thumb plainly: the longer an enterprise integrates without an abstraction layer in place, the higher the eventual cost of exit climbs, because every month without one adds more vendor-specific code that later has to be rewritten.

Data and Prompt Portability

Data portability asks a narrow question: can the enterprise pull its transaction history, embeddings, and fine-tuned model weights out of the current vendor’s environment in a format usable somewhere else, and how much of that data is trapped in a proprietary representation. Prompt portability asks a related but distinct question, since prompts tuned for one foundation model’s quirks, its preferred formatting, its tolerance for ambiguity, its specific failure modes, frequently underperform when pointed at a different model without retesting.

Both forms of portability matter because they compound: an enterprise that has both proprietary data formats and model-specific prompt tuning locked into one vendor faces a migration that has to solve two separate problems simultaneously, not one. Atlan’s analysis of single-stack versus neutral context layers notes that migration costs rarely reduce to a single price tag; they include migration labor, integration rewrites, parallel operation during cutover, retraining, and rebuilding the definitions, lineage, and policies that governed the old environment, all before the new environment produces a single production result.

Fine-Tuned Weights and Integration Code

Fine-tuned weights are the least portable artefact in most agent stacks, because a model fine-tuned on one vendor’s infrastructure using that vendor’s specific fine-tuning API frequently cannot be exported as a usable artefact at all: the enterprise owns the training data and the right to retrain, but not necessarily a portable copy of the resulting weights. Integration code is more portable in principle, since it is the enterprise’s own code, but in practice it accumulates vendor-specific assumptions, particular error codes, particular rate-limit behaviors, particular authentication flows, that make a rewrite for a new vendor closer to a second implementation than a find-and-replace exercise.

The practical takeaway for a selection memo is that fine-tuning depth and integration depth should both be treated as commitments with a price, not as free customization. Every additional fine-tuning cycle and every additional line of vendor-specific integration code raises the exit cost measured under the model-portability and API-dependency vectors, even when neither one shows up as a separate line item on the vendor’s invoice.

What a Migration Actually Rebuilds: Prompts, Classifiers and Approval Flows

A migration off an agent platform rebuilds far more than the platform itself; it rebuilds the institutional knowledge that got encoded into prompts, fine-tuned classifiers, and approval flows over the life of the deployment, and that knowledge does not transfer automatically just because the underlying infrastructure changes. Hidden-cost figures for the buy path put vendor lock-in exit costs at one to five million dollars for the migration itself, with an additional two hundred to eight hundred thousand dollars in connector and customization work needed to rebuild the integrations that connected the old platform to the rest of the enterprise’s systems.

The reason the bill runs that high is that a working agentic system is not just code: it is a record of every edge case the team debugged into the prompts, every escalation rule the compliance team negotiated into the approval flow, and every classifier threshold tuned against months of real production traffic. None of that lives in a format any vendor exports cleanly, which means a migration team has to reconstruct it from documentation, tribal knowledge, and re-testing rather than simply copying a configuration file. The Buy-or-Build Decision, Revisited argues that lock-in mechanisms deepen rather than shrink as vendors embed more AI features into their platforms, since each new AI-native capability adds its own proprietary data format and workflow dependency on top of the ones that already existed.

Pricing the Exit Before the Contract Is Signed

Pricing the exit before signing means running the four-vector assessment and the migration-rebuild estimate as inputs to the contract negotiation itself, not as a post-mortem exercise after a bad vendor relationship has already cost the enterprise a year of flexibility. A procurement lead who walks into a negotiation with a specific number, even a rough one, built from the vectors above, has leverage to negotiate data export rights, notice periods, and exit fees that a procurement lead negotiating from a feature checklist alone does not have.

The framing that makes this exercise sustainable, rather than an annual source of anxiety, treats dependency as a price accepted knowingly, at a level the enterprise chose, with a documented way out; eliminating lock-in entirely by building every capability in-house is slower, more expensive, and usually produces a worse result than buying would have. A quarterly reassessment model does not ask the enterprise to accept less dependency: it asks the enterprise to keep re-verifying that the dependency accepted last quarter is still the one it would choose today, at today’s price, against today’s alternatives.

Build Only What Covers a Gap the Platform Has Today: When Custom Orchestration Turns Into a Liability

Custom orchestration is justified only when it covers a gap the platform has today, and it stops being justified the moment the platform ships that capability natively: a rule that sounds obvious stated plainly but that most build-versus-buy guidance never states as a rule at all. The Buy-or-Build Decision, Revisited documents that AI-assisted development has lowered the cost floor for building software and compressed development timelines, without invalidating the underlying build vs buy frameworks grounded in transaction cost economics and the resource-based view: the two academic lenses that ask, respectively, whether the coordination costs of buying exceed the costs of making, and whether the capability being built is one the enterprise can defend as a genuine differentiator.

The consequence the paper itself does not draw out, but the field record supports, is that a lower make-cost floor produces more glue code without shrinking the underlying risk: when writing a custom orchestration layer takes a team two weeks instead of two months, more teams write one, and fewer of them treat the result as a long-term commitment requiring the same governance a two-month project would have earned.

Why a Lower Make Cost Floor Produces More Glue Code, Not Less Risk

A falling cost floor for custom software changes the economics of building, but it does not change the economics of maintaining what got built, and that gap is where the risk actually accumulates. Transaction cost economics predicts that as the cost of coordinating with an external vendor falls relative to the cost of building in-house, organizations should buy more; AI-assisted development inverts part of that equation by making the build side cheaper too, which is why the framework still applies even though the specific numbers have shifted.

What changes in practice is who decides to build. When the make-cost floor was high, only a formally justified project with a dedicated budget got approved to write custom orchestration code. When the floor drops low enough that an individual engineer can produce a working prototype in an afternoon, the decision to build stops going through the same governance process, and glue code accumulates from dozens of small, individually reasonable decisions rather than one large, reviewed one. Kai Waehner’s observation that most enterprise AI pilots still fail to scale, and that the constraint is rarely model capability, points at exactly this accumulation: the pilot works, but the orchestration code holding it together was never built to survive contact with production traffic, compliance review, or a second team trying to extend it.

That accumulation compounds once more than one custom-built agent starts interacting with the others, because coordination behavior that looked predictable in isolation can produce collective effects nobody designed for. Google DeepMind’s funding call for multi-agent safety research makes exactly this point at scale: as independent AI agents interact across shared environments, new collective behaviors can emerge suddenly, and most safety evaluation to date has analyzed models in isolation rather than the emergent effects of the group. A custom orchestration layer that hasn’t been evaluated for exactly that kind of interaction risk is a governance liability in addition to a maintenance one, and that additional risk belongs in the build decision, not just in the maintenance-burden estimate.

The Only Legitimate Build Target: A Gap the Platform Has Today

The only legitimate target for custom orchestration is a capability the platform demonstrably lacks right now, verified against the current state of the vendor’s roadmap rather than against a gap the team remembers from six months ago. Multi-agent orchestration maturity on vendor platforms remains a real gap as of mid-2026 according to Traversaal’s assessment, and that gap, not a generic preference for control, not a hypothetical future requirement, is the kind of finding that justifies a build decision today.

Framework maintenance burden is the cost that build decisions routinely underprice: hidden-cost estimates put ongoing maintenance for a borrowed or self-built orchestration path at 20 to 30 percent of total development time, a recurring bill that does not show up in the initial build estimate because it is paid continuously rather than once. A team that builds to cover a genuine platform gap should price that 20 to 30 percent ongoing cost into the decision from day one, and should revisit whether the gap still exists every time the vendor ships a release; because the moment it closes, the custom code stops being an asset and starts being a liability that someone still has to patch, test, and explain to new hires.

Designing Orchestration for Disposal and Retiring It on a Schedule

Custom orchestration should be designed for disposal from the moment it is written, with a narrow, well-documented interface that makes it easy to delete once the platform absorbs the capability it was built to provide, rather than allowed to sprawl into the surrounding codebase the way permanent infrastructure does. Designing for disposal means resisting the temptation to generalize the custom code beyond the specific gap it fills: a narrowly scoped module is a module someone can confidently delete in an afternoon; a generalized framework that other teams have started depending on is not.

The retirement trigger is platform absorption: the point at which the vendor or the underlying model lab ships the capability the custom code was built to provide, natively and at comparable quality. This site’s own record offers a concrete illustration; two in-house orchestration layers, one for cross-session handover and one for cross-family review coordination, were each retired within fifteen months of being built, each one right for the season it was built in, and each one became a liability once the platform it sat beside shipped an equivalent capability natively. The sunk cost in both cases was real; treating it as a reason to keep the custom layer running past its usefulness would have been the more expensive mistake.

How to Score Candidates: A Three-Year Total Cost Model With a Lock-In Tolerance Weight

A framework selection decision gets defensible the moment it is expressed as a scored total cost of ownership model rather than a narrative preference. The Sincllm Three-Year Scoring Model does this with ten scoring criteria over a three-year horizon, with vendor lock-in tolerance sitting as the sixth criterion and weighted so that a lower tolerance for lock-in raises the effective cost of exit across every candidate at once. Setting the horizon at three years follows Mohit Sewak’s total-cost-of-ownership comparison across build and buy paths, chosen because it is long enough to surface the maintenance and escalation costs that a one-year comparison hides, without stretching so far that the projection becomes speculative.

Setting the Horizon and the Ten Criteria

The scoring model’s first job is establishing the horizon and the criteria list before a single candidate gets scored, because a model built to fit a predetermined answer is worthless the first time market conditions shift. A three-year horizon captures one full cycle of the quarterly reassessment described earlier in this guide, roughly twelve re-scoring events, long enough to average out any single quarter’s noise while still being short enough that the underlying assumptions about vendor pricing and platform capability remain plausible.

The ten criteria in the Sincllm model span cost dimensions (initial cost, ongoing maintenance, usage-based scaling), risk dimensions (data residency, vendor lock-in tolerance, contract structure), and capability dimensions (time-to-value, model transparency, customization depth, and switchability), with vendor lock-in tolerance as criterion six carrying a configurable weight rather than a fixed one. That configurability is the model’s most useful property: an enterprise with a low tolerance for lock-in, a regulated bank, for instance, can raise the weight on that single criterion and watch every candidate’s total score shift accordingly, without having to rebuild the rest of the model from scratch.

Populating the Rows: Transparency, Residency, API-First, Pricing, Switchability

Populating the scoring rows means gathering evidence, not opinion, against each criterion for every candidate framework, and Technobrave’s five platform tests give the rows a concrete evidence bar: model transparency, data residency, API-first architecture, pricing predictability, and the practical ability to switch providers. Model transparency asks whether the vendor documents which underlying models power the platform and how substitutable they are; data residency asks where the enterprise’s data physically lives and under what jurisdiction; API-first architecture asks whether every platform capability is reachable through a documented API rather than locked behind a proprietary interface only the vendor’s own tooling can call.

Pricing predictability separates usage-based pricing, which scales with volume and can produce budget surprises as adoption grows, from seat-based pricing, which is easier to forecast but can penalize an enterprise that wants to scale agent usage without scaling headcount proportionally. Switchability is the row that ties the scoring model back to the lock-in vectors covered earlier: a candidate that scores well on data residency and API-first architecture but poorly on actual demonstrated switches by other customers should still be scored conservatively on this row, because documented intent to be switchable and proven switchability are not the same evidence.

Usage-Based Versus Seat-Based Pricing Lines

Usage-based pricing lines and seat-based pricing lines behave differently under growth, and a scoring model that treats them as interchangeable will systematically underprice the usage-based option for any enterprise planning to scale agent deployment aggressively. A usage-based line starts cheaper at low volume, which is why it wins early pilots, but it carries an annual escalation risk that a seat-based line does not, since seat-based pricing caps the enterprise’s exposure at the number of licensed users regardless of how many tasks those users’ agents complete.

The scoring implication is straightforward: an enterprise expecting agent usage to grow faster than headcount should weight the usage-based escalation risk heavily even if the current-quarter price looks attractive, while an enterprise with a stable, predictable agent footprint can treat seat-based and usage-based pricing as closer to equivalent. Getting this distinction wrong is one of the more common ways a total cost of ownership model produces a confident-sounding number that turns out to be wrong within a year.

Projecting Annual Usage Escalation

Annual usage cost escalation for the buy path runs 15 to 25 percent as volume grows, a projection line that belongs in the model explicitly rather than as a footnote appended after the headline total cost figure is presented. Entering it as a footnote is how total-cost comparisons quietly understate the buy path’s real three-year cost, since a 20 percent compounding annual increase applied against year-one usage produces a materially different year-three number than a flat projection does.

Against that escalation, the buy path’s time-to-value benefit, compressing deployment from roughly eighteen months down to a matter of weeks, has to be entered with its assumptions visible rather than presented as an unqualified win, because the eighteen-month baseline it is compared against assumes a from-scratch build with none of the accelerants a team might otherwise use. A scoring model that shows its assumptions on both sides of that comparison produces a number a skeptical CFO can actually interrogate, which is the entire point of scoring the decision rather than arguing it.

Scenario Analysis: Moving the Lock-In Tolerance Weight

Scenario analysis means re-running the same ten-criterion model multiple times with the lock-in tolerance weight set to different values, then reporting how the ranked order of candidates changes as that single weight moves: a five-minute exercise once the model exists, and the exercise that makes the model worth building in the first place. Move lock-in tolerance from medium to low and a managed platform that led the ranking under the original weighting can drop two places, because its convenience advantages get outweighed by an exit cost the low-tolerance scenario now treats as unacceptable.

The same workbook keeps every weight scenario as its own labeled column instead of overwriting the prior run, so a platform team can lay the low-tolerance ranking next to the original medium-tolerance ranking and see exactly which candidates moved, and by how many places, rather than only that the final answer changed. That side-by-side view is what lets a procurement lead answer a narrower question, would this recommendation still hold under a stricter lock-in posture, without re-deriving the ranking from the raw evidence rows each time the question comes up.

Enterprise Selection Criteria Beyond Developer Popularity: Isolation, SLAs, Interoperability and Regulated Workloads

Enterprise selection criteria for an AI agent framework have to go well beyond developer popularity and GitHub star counts, because procurement and security review weigh isolation guarantees, SLA-backed support, interoperability with existing systems, and fitness for regulated workloads instead. The criteria that separate a production-ready platform from a polished demo, multi-agent orchestration capability, observability and cost controls, data isolation guarantees, service level agreement commitments for agentic workloads, and customization depth without vendor dependency, are exactly the criteria a popularity ranking cannot measure. Databricks’ framing of orchestration platform selection makes the same point from the platform-engineering side: an orchestration platform that lacks state management, native support for multiple agent frameworks, built-in observability, or governance controls in any one of those areas creates a gap that the adopting team ends up building themselves, which quietly reintroduces the custom-orchestration liability covered earlier in this guide.

Five Criteria a Demo Cannot Fake

A framework that cannot show its decision log has not passed the first gate, regardless of how impressive its demo looked in a sales presentation, because the five criteria that separate production readiness from demo polish, orchestration capability under concurrent load, observability and cost controls, data isolation guarantees, SLA commitments specific to agentic workloads, and customization depth that does not require abandoning the platform’s own upgrade path, are all things a scripted demo is specifically designed not to exercise.

Data isolation guarantees matter because agentic workflows routinely touch data from multiple business units or multiple customers, and a platform that cannot demonstrate hard isolation boundaries between those workloads is not production-ready for a regulated enterprise no matter how capable its reasoning appears in a single-tenant test. Service level agreement commitments for agentic workloads specifically, rather than generic API uptime SLAs, matter because an agent’s failure mode is different from a simple API’s: a stuck agent loop or a runaway tool-calling sequence can consume budget and produce incorrect downstream actions in ways a simple request-timeout SLA was never designed to catch. Ferdinand Muscat’s 2026 analysis adds vendor stability and support quality as selection criteria that sit alongside pure capability weighting, on the reasoning that a technically excellent platform from a vendor unlikely to still be supporting it in three years scores worse, on a properly weighted total-cost basis, than a slightly less capable platform from a vendor with a demonstrated commitment to the space.

Interoperability as an Exit Guarantee: MCP and A2A Support

Interoperability standards function as an exit guarantee precisely because they are the mechanism that keeps a switch technically possible even after an enterprise has invested heavily in one platform, and the two standards that matter most for agent frameworks are the Model Context Protocol, which governs how an agent shares context and capabilities with external systems, and Agent-to-Agent communication, which governs how one agent delegates work to another regardless of which framework built each one. A systematic review of agentic AI frameworks and communication protocols places these alongside older coordination mechanisms, the Contract Net Protocol, the Agent Network Protocol, and Agora, as the layer of the stack where interoperability, not raw capability, determines whether agents built on different frameworks can actually work together.

Support for open interoperability standards is not a nice-to-have feature to check off during evaluation; it is the difference between a framework choice that keeps the exit door open and one that quietly welds it shut. Stanford’s research on conventions in multi-agent collaboration frames the underlying dynamic clearly: teams that interact repeatedly build shared conventions for coordination, and task-specific skills transfer across partners while partner-specific conventions do not; which is exactly the distinction that separates an open protocol like MCP or A2A, designed to work the same way regardless of which agent or vendor is on the other end, from a proprietary coordination pattern that only works because two systems happen to share the same vendor’s specific implementation quirks.

That distinction matters at the level of individual tool calls, not just at the level of protocol names. A practitioner breakdown of how agents execute actions separates UI-driven interaction from API-driven, function-calling interaction, and the framework choice determines which of the two an enterprise’s agents default to; an agent restricted to UI automation against a vendor’s own console is far harder to re-point at a new vendor than one whose actions all route through a documented, callable function interface, because the function interface is exactly what a standard like MCP or A2A is designed to sit on top of.

Regulated Workloads: Model Risk, Decision Logs and Human Escalation

Regulated enterprises need more from an agent framework than production readiness in the generic sense; they need auditable decision logs, defined human escalation points, and model-risk controls built into the orchestration layer itself, not bolted on afterward as a compliance patch. Academic work on agentic systems applied to financial services demonstrates what this looks like in practice: modeling and model-risk-management crews built around a judge agent working alongside a human-in-the-loop module, so that every automated modeling decision has both an automated check and a defined point where a human reviewer can intervene before the decision takes effect.

Research on enterprise-ready generalist agents similarly treats pre-deployment controls as a first-class requirement rather than an afterthought, arguing that the same iterative evaluation and refinement approach that improves an agent’s raw task performance also has to be applied to the controls that govern its behavior before it reaches production. Amazon’s own account of evaluating agentic systems at scale reinforces the same point from the operational side: evaluation has to function as a selection input, assessed before a framework is chosen and continuously afterward, rather than as a post-deployment activity run once and forgotten, because the emergent behaviors of a complete multi-agent system, the coherence of its multi-step reasoning, the accuracy of its tool-selection decisions, only become visible once evaluation runs against production-scale traffic, not against a curated demo dataset.

The Quarterly Portability Drill: Measuring Lock-In Exposure and Switching Readiness

A portability test run once, at procurement, is a memory of what switching would have cost on the day the vendor was chosen; run quarterly, the same test becomes a control that tells the enterprise whether switching still costs what it used to. Clarion Analytics’ 2026 recommendation is to test the ability to switch providers with a structured exercise before any agent goes live, and to architect for portability from the first line of code by building model-agnostic abstraction layers such as LiteLLM rather than calling a single vendor’s API directly: a discipline that turns portability from an aspiration into an engineering requirement enforced by the codebase itself.

From a One-Time Due Diligence Test to a Quarterly Drill

Formalizing a one-time due-diligence exercise into a recurring quarterly drill is the change that makes portability an operating control rather than a historical footnote from the procurement process. The due-diligence version of the test answers one question, could we have switched on day one, and that answer decays in value every month the production system evolves away from the state it was in when the test ran, as new integrations, new fine-tuning, and new team habits all quietly deepen the enterprise’s dependence on whichever platform it chose.

Running the same test every quarter, against the current state of the production system rather than the day-one state, catches that decay while it is still small and correctable. A drill that reveals switching cost has crept up thirty percent in a single quarter is actionable in a way that discovering the same thirty percent creep after two years of unmonitored drift is not, because the quarterly version identifies which specific change, a new integration, a new fine-tuning cycle, a new proprietary feature the team started relying on, drove the increase, while the two-year version leaves the team reconstructing a history nobody tracked.

Scoring Exposure Across Six Portability Dimensions

Lock-in exposure gets measured across six distinct dimensions, model, integration, data, orchestration, governance, and contract flexibility, each scored from one to five per production agent deployment, with the aggregate reported once per quarter as a single number the platform team can track over time. Scoring each dimension separately, rather than producing one blended lock-in score, matters because the dimensions do not move together: an enterprise can improve its model portability score by adopting an abstraction layer while its orchestration portability score stays flat because the underlying coordination logic is still written against one vendor’s specific graph or conversation format.

Portability Dimension	Score 1 (Low Exposure)	Score 5 (High Exposure)
Model	Abstraction layer routes to any model	Prompts hard-coded to one model’s quirks
Integration	Standard protocol (MCP/A2A) at every boundary	Vendor-proprietary calls throughout
Data	Exportable in open formats on demand	Proprietary formats, no bulk export path
Orchestration	Coordination logic documented and portable	Logic embedded in vendor’s graph/console
Governance	Policies enforced outside the platform	Policies only enforceable inside the platform
Contract flexibility	Short notice period, clear export rights	Long lock-in period, ambiguous export rights

Google Research’s controlled evaluation of 180 agent configurations found that multi-agent coordination dramatically improves performance on parallelizable tasks while degrading it on sequential ones, and identified a predictive model that picks the optimal architecture for 87 percent of unseen tasks; evidence that belongs directly in what a portability drill exercises, since a drill that only tests whether a workload can move to a different vendor, without also testing whether that workload’s task structure still fits the new vendor’s coordination model, will pass a test that a real migration would fail.

Model, Integration and Data Portability

Model portability, integration portability, and data portability form the technical half of the six-dimension score, and they share a common test: could the artefact in question, a prompt, an API call, a stored record, move to a different vendor’s environment today, with automated tooling, or does it require a person to manually reconstruct it. A model-portability score of one means the enterprise routes every model call through an abstraction layer that could redirect to a competing model with a configuration change; the drill assigns the 1-5 score by checking what share of this quarter’s model traffic still runs through that layer versus direct, vendor-specific calls, and logs the number next to the prior quarter’s reading so a slipping score shows up as movement rather than staying buried in a single point-in-time snapshot.

Integration and data portability follow the same logic applied to API calls and stored records respectively. The integration-portability check counts how many system boundaries adopted MCP or A2A since the prior quarter’s drill, scoring each boundary a plain yes or no and logging the running total next to the last several quarters’ counts so a boundary that reverts from yes back to no shows up as a visible dip rather than vanishing into a single point-in-time tally; the data-portability check is to actually attempt an export of transaction history and embeddings this quarter, not to confirm on paper that a path exists, and record whether the attempt succeeded, partially succeeded, or failed outright.

Orchestration, Governance and Contract Flexibility

Orchestration portability, governance portability, and contract flexibility form the second half of the score, and they capture risks that a purely technical audit of code and data formats would miss entirely. Orchestration portability asks whether the coordination logic itself, the graph definition, the conversation protocol, the state machine, is documented in a form a new team or a new vendor’s tooling could reconstruct, or whether it exists only as implicit behavior embedded in one platform’s console.

Governance portability asks whether the policies that constrain agent behavior, approval thresholds, escalation rules, audit requirements, are enforced by something the enterprise controls, such as a policy engine sitting outside the vendor’s platform, or whether they only exist because the current vendor’s console happens to support them. Contract flexibility closes the loop by scoring the commercial terms directly: the drill compares this quarter’s contract reading against the prior quarter’s and flags any move in the wrong direction, a notice period that lengthened, an export right that quietly disappeared in a renewal, treating that change, not the terms’ static favorability, as the score-relevant signal.

Owning the Routing and Observability Layer So Every Provider Is Replaceable

Owning the routing and observability layer, rather than delegating it to whichever vendor’s platform happens to sit underneath it, is the architectural pattern that makes every provider behind that layer replaceable, because the enterprise’s own code, not the vendor’s, is what decides which model or which agent handles a given request and what gets logged about the decision. This integration-first pattern inverts the usual adoption sequence: instead of building against a vendor’s SDK and adding an abstraction layer later if lock-in becomes a problem, the enterprise builds the routing and observability layer first and treats every vendor as a pluggable backend from day one.

Research on orchestrating agentic applications as function-as-a-service (FaaS) workflows offers a portable execution target that reinforces this pattern: framing agent execution as discrete, stateless functions invoked through a standard interface makes the underlying compute provider, whichever cloud or platform actually runs the function, swappable in a way that a monolithic, vendor-hosted agent runtime is not. The output of a properly run drill, under this pattern, is three concrete numbers: an exposure score per dimension, a measured time to switch, and a list of the specific artefacts that failed to move cleanly during the test: the list that tells the platform team exactly what to fix before the next quarter’s drill runs.

Buy the Runtime, Build the Judgement: The Hybrid Decision Rule and What Comes Next

The hybrid approach to AI agent framework selection is a rule, not a balance, and the rule is this: buy the runtime, build the judgement. Khired’s 2026 analysis quantifies what that split looks like in practice; roughly 80 percent of an enterprise’s agent workflows are commodity, best bought from a platform, while the remaining 20 percent are strategic differentiators worth the cost of building in-house. Bill Huber’s 2026 enterprise playbook on building, buying, and using open source for AI agents supplies the criteria that decide which side of that 80/20 split any given capability falls on: portability and lock-in exposure, weighed against how directly the capability contributes to what makes the enterprise’s product or process distinctive.

The Rule: Buy the Runtime, Build the Judgement

The judgement layer, the map of what the enterprise’s agent estate actually does, the ledger recording what is live in production, the rulings register that decides recurring edge cases, and the human sign-off point where accountability ultimately sits, is the asset no vendor can ship, because it encodes decisions specific to one organization’s risk tolerance, regulatory context, and operating history. The runtime, by contrast, is exactly what the labs and platform vendors compete hardest to commoditize: reasoning loops, tool-calling infrastructure, and multi-agent coordination primitives that get better and cheaper every quarter regardless of which enterprise is using them.

Andy Winskill’s framing of the build-buy-or-customize decision makes the rule actionable at the level of a single agent rather than the level of the whole estate: the decision gets made agent by agent, weighted across differentiation, product fit, internal capability, data sensitivity, and total cost over time, rather than settled once for every agent the enterprise will ever build. Ritu Agarwal’s academic work on strategic dependency and Amit Joshi’s work on enterprise AI operating models together supply the theoretical grounding for why the judgement layer resists commoditization even as the runtime does not: dependency on an external vendor for a commodity capability carries little strategic risk, but dependency for a capability that encodes the enterprise’s own accumulated judgment about its regulatory and operational context is a different kind of exposure entirely, one no amount of vendor reliability can substitute for.

Partner and Integrate as the Third and Fourth Options

Partnering and integrating sit between pure build and pure buy as two further options in what the build-buy-partner and build-buy-integrate frameworks treat as a four-way menu, one that a selection memo restricted to only the first two extremes misses entirely. Partnering means co-developing a capability with a vendor under a negotiated agreement that includes shared intellectual property rights, defined portability guarantees, and explicit exit rights: a structure suited to a capability important enough to warrant close vendor collaboration but not so core to the enterprise’s differentiation that full ownership is worth the cost. Integrating means owning the abstraction layer that sits above multiple providers, treating each individual vendor as a replaceable component behind an interface the enterprise itself controls: the same routing-and-observability pattern covered in the portability drill, applied here as a sourcing strategy rather than only as an operational control.

Widening the menu to four options, build, buy, partner, and integrate, gives Andy Winskill’s per-agent decision more room to land on the right answer for each specific case, since a capability that scores as “important but not core” under a two-option framework often gets force-fit into either a full build that overspends on differentiation the enterprise doesn’t need, or a full buy that surrenders more control than the risk actually requires. Andrew Ng’s guidance on sequencing enterprise AI adoption reinforces the ordering implied by the wider menu: buy first, by default, and reserve build, partner, or integrate for the specific cases where the default demonstrably falls short.

Google DeepMind’s Co-Scientist system is a useful illustration of what a well-drawn partner or integrate arrangement looks like in practice: the multi-agent runtime itself is the buy-side commodity, while the domain-specific judgement, knowing which drug-repurposing candidates were worth surfacing for a liver-fibrosis study, and which results warranted a researcher’s further attention, came from the specialist partnership layered on top. The runtime found the connections; the judgement about which connections mattered to a specific research program stayed with the humans and the domain-specific integration built around the tool, which is the same division of labor the buy-the-runtime, build-the-judgement rule prescribes at enterprise scale.

The rule gets re-applied every quarter, and the expected direction of travel is that the built share of the estate shrinks over time, not grows, as platforms absorb capability that used to require custom orchestration to provide. A CTO signing off on this quarter’s build-versus-buy split should expect to be asked, next quarter, why a capability that was worth building six months ago no longer is; and the honest answer, most of the time, will be that the platform caught up, which is exactly the platform-absorption dynamic that governs when custom orchestration gets retired.

What does not shrink, and what compounds instead, is the judgement layer: the topical map of what the estate does, the ledger of what is live, the rulings register, and the human gate all get more valuable with every quarter of accumulated decisions, because each one encodes a piece of institutional judgment that took real experience to earn and that no vendor’s roadmap update can simply hand over. The labs will keep shipping better runtimes. They will never ship an enterprise’s own judgement, and building the discipline to keep that judgement current, re-scored every quarter, re-verified against this quarter’s platform capabilities, is what turns framework selection from a one-time architectural gamble into a durable operating advantage.

Summary

Framework selection stops being a source of anxiety once it is treated as a scored, quarterly process rather than a one-time architectural bet, because every one of the mechanisms covered above, the layer table, the four lock-in vectors, the total cost model, the portability drill, exists to make the next quarter’s re-score cheaper than the last one.

The Rule That Replaces a Feature Comparison

The rule that replaces a feature-by-feature comparison is the buy-the-runtime, build-the-judgement split named above, closed out by the two disciplines this guide adds on top of it: price the exit before signing, and re-run the scorecard, the layer table, the lock-in vectors, the total cost model, the portability drill, on a fixed quarterly schedule rather than waiting for a crisis to force the question. Each piece of that rule depends on the others; pricing the exit without a total cost model produces a number nobody trusts, and a total cost model without a quarterly re-score is accurate on the day it is built and increasingly wrong every month afterward.

The mechanism that ties them together is the lock-in tolerance weight inside the total cost model: raising or lowering that single number, in response to a shift in regulatory posture or corporate strategy, mechanically re-ranks every candidate without requiring the enterprise to reopen the underlying debate about which framework is generally “best.” That is the practical payoff of scoring the decision instead of arguing it: the argument only has to happen once, over what the weight should be, not every time a new vendor claims to have solved the problem.

What Breaks When the Decision Is Treated as One-Time

What breaks, when an enterprise treats framework selection as a one-time decision, is not the initial choice; most vendors and open-source projects perform reasonably well against the criteria that matter at the moment of selection. What breaks is the enterprise’s ability to notice when the ground has shifted underneath that choice: when a platform absorbs a capability the team built in-house, when a vendor’s pricing model changes the total cost calculation, or when a regulatory requirement raises the effective weight the enterprise should be placing on lock-in tolerance.

A one-time decision also breaks the exit-cost math specifically, because every month spent integrating deeper into a platform without revisiting the four lock-in vectors adds cost to a migration nobody is actively planning for, until the eventual attempt to switch runs into a bill nobody budgeted. The fix in every case is the same fix this guide has returned to across every section: build the scoring model once, keep the inputs current, and let the quarterly cadence do the work that an annual review or a one-time selection memo never could.

Anonymous. Counted, not tracked.

Where is your organisation with this right now?

What is the hardest part where you are?

agility at scale