The Rise of Enterprise Learning Sovereignty

From API calls to agent architecture

The first phase of enterprise artificial intelligence (AI) was built around a straightforward proposition. A company could take the most capable model available, call it through an application programming interface, add instructions and context, and quickly put a useful product in front of customers. That architecture was not a mistake. It lowered the cost of experimentation, gave small teams access to capabilities that once required a large machine-learning organization and allowed companies such as OpenAI and Anthropic to turn frontier intelligence into something close to a utility.

But the architecture that is best for starting an AI product is not necessarily the architecture that creates a lasting advantage. As companies move from chat interfaces to agents, the important question is becoming less about which model produces the best answer on a benchmark and more about who controls the system that improves each time the work is performed. An agent does not simply write text. It searches, chooses tools, reads documents, calls software, updates records, writes code and, in some cases, takes actions with financial or operational consequences. Once that happens, the model is no longer the entire product. It is one component inside a larger system.

This does not mean that enterprises will stop using OpenAI, Anthropic or other frontier laboratories. Those models will remain important, particularly for prototyping, difficult edge cases and tasks that benefit from the broadest available reasoning capabilities. They will also increasingly serve as teachers, evaluators and generators of synthetic training data. What is likely to change is the assumption that a closed model endpoint should remain the permanent home of a company’s differentiated intelligence.

The agent harness is the real product

In many enterprise applications, the durable advantage will come from the system around the model. That system includes instructions, internal and external data, retrieval, memory, tool access, credentials, execution environments, routing logic, evaluators, audit trails and rules governing when a human must intervene. Together, these components are often described as the agent harness. The harness determines what a model can see, what it is allowed to do, how it responds when a tool fails and how the company decides whether the result was acceptable. In practice, these decisions can matter as much as the difference between two leading foundation models.

That is an important reversal from the chatbot era. In an early generative-AI application, the model often appeared to be the product and everything around it looked like implementation detail. In an agentic system, the surrounding software increasingly defines the product. The model may be upgraded, replaced, routed around or trained for a narrower purpose. The harness, by contrast, contains the company’s understanding of the workflow.

How agents turn work into a learning signal

Every time an agent performs a task, it also creates a record of how the task was performed. That record may include the original request, the material retrieved, the sources accepted or rejected, the tools called, the permissions requested, the errors encountered, the corrections supplied by a human and the eventual business outcome. A customer-service agent can be judged by whether the issue was resolved. A coding agent can be judged by whether its tests passed and its changes survived production. A research agent can be judged by whether its claims were supported, its sources were appropriate and its conclusions matched an organization’s standards.

These records are more than application logs. They are experience data. They capture the way work is performed inside a particular organization. With the appropriate consent, controls and data-governance policies, they can become evaluation sets, supervised demonstrations, preference data, synthetic examples, reward signals and training environments. They can also reveal that the problem is not the model at all, but a retrieval failure, a badly described tool, a missing permission or an incorrect business rule.

How experience data compounds from logs to learning

This is where enterprise AI begins to compound. A company that consistently captures and evaluates its agents’ trajectories can build systems that reflect its own standards, terminology, operating procedures and tolerance for risk. A competitor may be able to purchase access to the same general-purpose model. It cannot easily purchase the accumulated history of how another company’s work is performed, corrected and improved.

The enterprise moat, in other words, is unlikely to be the mere use of an advanced model. It will be the combination of a proprietary environment, a reliable feedback system, a fast improvement cycle and the trust required to operate inside meaningful workflows. Model quality remains important, but it is multiplied by those other factors rather than substituting for them.

Sovereign control without building a lab

Owning more of this system does not mean that every enterprise must become a frontier laboratory. It does not require hundreds of researchers or a company-operated fleet of graphics processors. A more realistic model is one of sovereign control with managed complexity. The enterprise owns or controls its production traces, evaluation sets, training data, model adapters or checkpoints, security policies and deployment configuration, while specialized vendors help operate the machinery.

A cloud provider can run the clusters. A post-training company can design a reinforcement-learning program. An environment company can create realistic simulations. A data company can recruit domain experts. An inference platform can optimize serving. A security company can manage credentials, permissions and auditability. The distinction is not between doing everything internally and outsourcing everything. It is between using specialists to operate the enterprise’s intelligence and permanently locating that intelligence inside a black-box service controlled by someone else.

This resembles earlier changes in enterprise infrastructure. Companies did not need to write their own operating systems or databases to benefit from open-source software. They did, however, value the ability to inspect, modify, move and operate critical systems, often with commercial support. Artificial intelligence is moving toward a related model, though the requirements for compute, data, evaluation and security are considerably more demanding.

Open-weight vs. open-source: what enterprises actually control

The terminology requires some care. Many models described as open source are more accurately called open-weight models. Their parameters may be available, while their training data, complete source code or commercial rights remain restricted. Enterprises therefore need to examine licenses and deployment rights rather than treating “open” as a single category. The strategic value lies not in a label but in the degree of control the company retains over the model, its modifications, its deployment and the data used to improve it.

A hybrid architecture: closed models as teachers, open models in production

The resulting architecture will probably be hybrid rather than ideological. A company may begin with a closed frontier model because it is the fastest way to understand a new workflow. It can instrument the agent, collect failures and build an evaluation set. It can use one or several frontier models to produce demonstrations, critique responses or generate additional training examples. Once the task is understood, the company can fine-tune or distill an open model for the recurring production workload.

The open model can then handle the high-volume and well-understood cases. Difficult, unusual or high-risk requests can still be routed to a stronger general-purpose model or to a human expert. Production outcomes can be fed back into evaluation and post-training. In this arrangement, closed models do not disappear. Their role changes. They become teachers, judges and premium fallback capacity, while open models become the controlled production layer for tasks that are repetitive, sensitive, expensive or strategically important.

Choosing the right post-training method for the task

The distinction among post-training methods is also important. Supervised fine-tuning is useful when a company can provide examples of the desired behavior. It can teach a model to follow a format, use domain language, call a tool correctly or imitate a successful procedure. Distillation transfers capabilities from a larger teacher into a smaller student, which can reduce cost and latency or make private deployment easier. Preference optimization is useful when several answers may be technically valid but differ in usefulness, tone or risk. Reinforcement learning becomes more relevant when the model must act in an environment, receive feedback and improve against an outcome rather than simply imitate an example.

Not every enterprise task requires reinforcement learning. A document classifier, structured extractor or narrow tool-calling system may be improved effectively with synthetic data and supervised fine-tuning. A long-running agent that must navigate several systems, recover from errors and satisfy multiple constraints is more likely to benefit from a realistic environment and a carefully designed reward signal. The appropriate method should follow from the work itself: what outcome matters, whether that outcome can be verified, which failures are costly and whether the goal is imitation, compression or the discovery of a better strategy.

What NVIDIA's Nemotron shows about the emerging stack

NVIDIA’s recent work on Nemotron 3 Ultra illustrates what this emerging stack can look like. The company describes a 550-billion-parameter mixture-of-experts model with 55 billion active parameters, trained on 20 trillion tokens and extended to a context window of one million tokens. More significant than the size of the model is the post-training process. NVIDIA combined supervised fine-tuning, reinforcement learning and a method it calls Multi-teacher On-Policy Distillation. It also released base, post-trained and quantized checkpoints, along with training data, recipes and reinforcement-learning environments.

NVIDIA trained more than 10 specialist teacher models across areas including software engineering, search, terminal use, office work, safety, factuality, science and conversational tool use. It then consolidated those capabilities into a student model through supervision applied to trajectories generated by the student itself. The approach is notable because it does not assume that a single generic model should learn every behavior in the same way. It treats specialization, environments and distillation as parts of one system.

Tavily appears in several parts of that work. NVIDIA used Tavily in search-oriented training trajectories and in science-reasoning examples generated with a teacher model that had access to web search and, in some cases, a Python execution environment. Tavily also served as the search and browsing provider in NVIDIA’s BrowseComp evaluation harness and supplied web-search capability for a finance-agent benchmark.

Search and the harness as post-training problems

This is a useful illustration of the changing role of search in agent systems. Search is not merely a retrieval call added at the end of a model’s reasoning process. It can be part of the runtime system, part of the curriculum used to teach the model and part of the evaluation system used to determine whether the model can conduct research effectively. The search layer influences what the agent sees, how it verifies a claim and whether its work can be reproduced.

The report also treats the harness itself as part of the post-training problem. NVIDIA trained models across multiple execution frameworks, including OpenHands, OpenCode, Terminus, Droid and internal systems. The purpose was to reduce the risk that a model would perform well only inside one prompt format, one tool schema or one agent framework. A model that succeeds only in a particular wrapper may have learned the wrapper rather than the underlying task. Enterprises should therefore test their models across changes in retrieval systems, tool descriptions, context management, permissions and failure conditions.

The startup opportunity: a new supply chain for enterprise AI

A new supply chain is forming around this work. One group of companies is building post-training infrastructure and training APIs. Another is creating reinforcement-learning environments and simulations. A third is offering enterprise reinforcement learning as a managed service. A fourth is extending data-labeling, evaluation and alignment businesses into agent training.

Training infrastructure and open stacks

Thinking Machines Lab’s Tinker is one example of the training-infrastructure model. It allows developers to control data, environments, losses and algorithms while the platform handles distributed training. Prime Intellect is building an open stack around training and environments; its verifiers framework defines tasks, harnesses and scoring functions that can be used for evaluation, synthetic-data generation and reinforcement learning. Unsloth focuses on efficiency and accessibility, making fine-tuning and reinforcement-learning workflows practical with less hardware and across a range of open models. These companies are separating control over the training logic from the operational burden of running the infrastructure.

Synthetic data, distillation, and managed services

Other companies are concentrating on synthetic data and distillation. Bespoke Labs has worked on data curation, reasoning datasets and distillation, emphasizing the value of carefully selected examples rather than indiscriminate scale. Distil Labs turns production traces or a small seed set into teacher-rewritten and validated training data, then fine-tunes a smaller student for deployment. Its documented approach is primarily supervised distillation, not reinforcement learning. That distinction matters because many high-volume enterprise workloads may be specialized without constructing a full environment or reward model.

Applied Compute represents a more service-intensive approach. It describes its work in terms of “specific intelligence”: models and agents trained for a particular company’s tasks, standards and data. Its work spans training, custom harnesses, evaluators, deployment and continued improvement. Adaptive ML built an RLOps platform around reinforcement learning, synthetic data, evaluation and production feedback. Datadog’s acquisition of Adaptive in June 2026 suggests that the boundary between observing a model and improving it is beginning to narrow. An observability system can do more than report that an agent failed. It can help classify the failure, generate a regression test and determine whether the next improvement belongs in the model, the harness or the underlying workflow.

Environments, verifiers, and the data layer

Environment and data companies are moving into the same territory. Snorkel AI is developing enterprise environments that simulate workflows in insurance, finance, legal services, manufacturing and sales. These environments contain tools, policies, databases, state and simulated users rather than simple question-and-answer pairs. Toloka combines expert trajectories, evaluation, red-teaming and virtual environments, including controlled credentials, audit logging and privacy safeguards. This points to one of the central technical problems in the field: an agent can improve systematically only when its performance can be verified reliably.

The verifier is therefore likely to become as important as the model. A weak verifier may fail to improve an agent, but it can also do something worse: reward the wrong behavior. A model may learn to exploit a measurement rather than complete the intended task. The challenge is particularly serious in long-running enterprise processes, where the final outcome may depend on policy compliance, side effects, cost, latency and the sequence of actions taken along the way.

Why Tavily and Nebius work so well together: search, training, and a closed loop

This shift also helps explain the combination of Tavily and Nebius. The simplest description is that Tavily provides agents with access to current external information, while Nebius provides infrastructure for training and operating models at scale. But the more consequential relationship is not a conventional bundling of search and compute. It is the possibility of placing retrieval, post-training, evaluation and deployment inside one controlled improvement cycle.

Nebius is useful to Tavily because it provides infrastructure across the model lifecycle. Its Token Factory product supports open-model inference, fine-tuning, distillation and dedicated deployment. That gives Tavily a path to participate not only in the moment when an agent performs a search, but also in the systems used to evaluate search behavior and improve search-capable models. A customer could, under its own policies and control, use approved trajectories to teach a model which sources to trust, when to corroborate a claim and when to abstain.

Tavily is useful to Nebius because models operating in production require contact with information that changes after training. A capable model may still produce an incorrect result if its knowledge is stale, incomplete or unsupported. Tavily can serve as a sensor layer that searches, extracts and structures information for agents, while Nebius provides the reasoning, training and deployment infrastructure around it.

What the Tavily-Nebius combination produces for enterprises

The larger opportunity is a loop in which the agent observes the world, reasons over the available evidence, takes an action, receives an evaluation and learns from the outcome. Tavily contributes to observation and grounding. The harness governs reasoning and action. The environment and verifier measure what happened. Post-training converts approved experience into changes in the model. Nebius provides the infrastructure on which the resulting system is trained and deployed.

For an enterprise, this can produce something more valuable than a generic model with search access. It can produce a research system that reflects the company’s own standards. Such a system can learn which sources are acceptable, which claims require multiple forms of confirmation, how uncertainty should be presented, when external information should be reconciled with internal records and what evidence is required before an agent is allowed to act.

What enterprises should build next, and what startups should offer

The movement toward owned learning systems will also create a broad opening for startups. Closed model providers have historically bundled many difficult functions behind a single endpoint, including data collection, synthetic-data generation, evaluation, safety training, inference optimization and monitoring. As enterprises adopt open models and more controlled post-training systems, those functions are becoming independent markets.

Agent environments, verifiers, and reward systems

Agent environments are likely to become a substantial software category. A coding agent needs repositories, tests, terminals and realistic failure states. A financial agent needs filings, spreadsheets, market data, internal policies and audit rules. A customer-service agent needs customer histories, simulated users, escalation procedures and access to the same tools used by employees. Building these environments is difficult, and keeping them synchronized with changing enterprise systems is harder still. Some startups will provide horizontal environment infrastructure. Others will build proprietary environments for a particular industry or business function.

Verification and reward systems are another likely category. For many enterprise tasks, success cannot be determined by matching a reference answer. The evaluator may need to inspect the final result, the sequence of tool calls, compliance with policy, factual support, cost, side effects and eventual business outcome. A company that can define and measure acceptable behavior occupies a powerful position because it influences both deployment decisions and the training process.

Trajectory infrastructure, model efficiency, and vertical agents

Trajectory infrastructure may become a new form of data infrastructure. Existing observability systems were designed for deterministic software, where logs, metrics and traces are relatively structured. Agent trajectories contain natural-language decisions, retrieved documents, changing context, probabilistic outputs, tool actions and human interventions. Enterprises will need systems that can capture these trajectories safely, remove sensitive information, preserve provenance, replay executions, label failures, compare model and harness versions and select approved examples for training.

Model efficiency will become a discipline in its own right. The model that produces a training example does not need to be the model that serves the final request. A frontier model may teach a smaller model to inspect contracts, call a specific API, classify a document or correct a known class of software error. Startups will build systems that determine which tasks can be distilled, which student model is appropriate, how much quality is lost, when a request should be escalated and how frequently the student should be retrained.

The strongest vertical-agent companies may use these capabilities to challenge established software categories. Their advantage will not come from placing a chat interface on top of an incumbent workflow. It will come from owning a faster cycle of performing the task, measuring the result, collecting expert correction and improving both the model and the harness. An incumbent may have more historical data. A startup may still gain ground if it has a better system for converting new experience into improved performance.

Security is access: why trust unlocks the most valuable work

Security will determine which of these startups gain access to meaningful work. An agent that only generates text has a limited range of possible harm. An agent that can read email, modify code, access customer records, browse the web or operate financial systems has a very different risk profile. External content cannot be assumed to be trustworthy. A web page, document, email or tool response can contain instructions designed to manipulate the agent.

The threat landscape: hijacking, injection, and cascading failures

NIST describes this class of problem as agent hijacking, or indirect prompt injection. In a large red-teaming competition involving more than 250,000 attack attempts against 13 frontier models, participants found at least one successful attack against every target model. OWASP identifies related risks such as tool abuse, privilege escalation, data exfiltration, memory poisoning, excessive autonomy, high-impact actions without validation and cascading failures among multiple agents.

The central security principle is that intelligence must not be confused with authorization. A model may conclude that an action is useful. That does not mean the model should have permission to perform it. Enterprise agents need least-privilege tools, narrowly scoped and short-lived credentials, separation between reading and writing, isolated execution environments, controls on network access, source provenance, human approval for consequential actions, complete audit trails, adversarial testing and a reliable way to roll back changes.

Open models provide greater control over deployment and inspection, but they do not create security automatically. Operating a model directly introduces responsibilities for artifact integrity, dependencies, access control, patching, evaluation and protection against poisoned training data. The issue becomes more complicated when production trajectories are reused for post-training. A malicious document that compromises one execution is dangerous. A malicious pattern that is incorrectly classified as a successful example can affect many future executions.

Why security is a source of distribution, not just compliance

For startups, security should not be understood only as a cost of entering the enterprise. It can also be a source of distribution. A company that cannot demonstrate isolation, auditability and controlled permissions will remain outside the most important workflows. It may receive sanitized prompts or public information, but it will not see how the work is actually performed. A startup that earns trust can gain governed access to real tasks, real tools, real errors, expert corrections and measurable outcomes.

That creates a reinforcing cycle. Trust leads to access. Access produces trajectories. Trajectories enable specialization. Better performance can then justify broader access. Over time, the startup becomes difficult to replace not because it has trapped the customer’s data, but because it has built a strong system for learning how the customer’s work should be performed.

How the landscape will shift: model portfolios, upstream frontiers, converging observability

Several consequences follow. Enterprises are likely to manage portfolios of models rather than commit to a single provider. Production systems will route among frontier closed models, general-purpose open models, fine-tuned enterprise models, small distilled models and deterministic software. The routing policy itself may become proprietary because it reflects the company’s understanding of cost, risk and task difficulty.

Evaluations and environments will also become protected intellectual property. An evaluation set encodes how a company defines quality. An environment encodes how the company operates. In some cases, those assets may reveal more about the organization than the final model weights. Companies will need to version them, protect them and treat them as part of the production system rather than as temporary testing material.

Frontier models may move upstream in the value chain. They may generate a smaller share of the final production tokens for mature, high-volume workloads while producing a larger share of the supervision. They will create demonstrations, identify failures, generate synthetic cases and teach smaller models. This would not make the frontier laboratories less important. It would change where their value is captured.

Observability and post-training are also likely to converge. The purpose of observing an agent should not be limited to producing a dashboard. The system should help determine what needs to improve. It should identify whether a failure arose from the model, the retrieval layer, a tool, a permission rule or an incorrect evaluator. It should then generate a regression test or route an approved example into a post-training workflow. The acquisition of Adaptive ML by Datadog is an early sign of this convergence.

A practical roadmap for enterprises starting today

Enterprises do not need to replace their existing model providers immediately to prepare for this shift. They should begin by selecting workflows with meaningful volume, measurable outcomes and enough repetition to create a learning signal. They should define the evaluation before fine-tuning the model and capture the complete trajectory rather than only the final response. They should compare frontier models, open models and smaller specialists instead of assuming that one model should handle every request.

They should also choose the least complex post-training method that solves the problem. Supervised fine-tuning is appropriate when good demonstrations exist. Distillation is appropriate when a smaller student can meet the required quality at a lower cost or inside a more controlled deployment. Reinforcement learning is appropriate when the task involves interaction and can be scored with sufficient reliability. A company should not construct an elaborate reinforcement-learning program for a problem that a carefully curated supervised dataset can solve.

The model and the harness should be versioned together. A model version says little without the prompts, retrieval settings, tool schemas, permissions and execution environment in which it was tested. Security boundaries should be established before autonomy is increased, with read-only access and narrow tools preceding any ability to make irreversible changes. Contracts should also make clear who owns the checkpoints, adapters, evaluation sets, environments, synthetic data, production traces and other derived artifacts.

The durable advantage is the learning cycle, not the model

The model race will continue. OpenAI, Anthropic, Google, NVIDIA, Meta, Alibaba, DeepSeek and other companies will keep moving the frontier. But enterprises will not build durable advantages merely by selecting the best-performing model at one moment. They will do so by building systems that can absorb the next model, learn from their own work and improve more quickly than their competitors.

That is the case for open models, controlled post-training and self-maintained agent harnesses supported by specialized companies. Open models give enterprises a place to accumulate improvements. The harness turns general model capability into governed action. Environments and verifiers turn experience into a usable signal. Distillation turns expensive general intelligence into efficient task-specific intelligence. Security gives these systems permission to enter the workflows where the most valuable experience is created.

It is also the strategic logic behind Tavily and Nebius. Tavily connects agents to current information. Nebius provides infrastructure for training, operating and improving the models that use that information. Together, those pieces can support a system that moves from observation to reasoning, action, evaluation and learning while leaving control of the resulting intelligence with the enterprise.

When we started Tavily, the mission was to help bring the next generation of agents onto the web. The larger opportunity now is to help those agents become part of systems that enterprises can operate responsibly: systems that are grounded, secure, portable, observable and capable of improving with experience. The first phase of enterprise AI was largely about renting access to intelligence. The next is likely to be about controlling the process by which intelligence improves.