How Enterprises Build Their Own AI Intelligence Production Line: Sequoia's Sovereign AI Deconstructed

Trajectory: Why Agents Act Like First-Day Employees

Continuous learning infrastructure company Trajectory identifies an "Experience Gap": models grow smarter, yet an AI agent entering an enterprise environment often behaves like a new hire. It may know general legal, financial, or software knowledge but lacks awareness of why the company rejected a specific proposal, which tool calls frequently fail, what format passes approval, or where experts corrected its answers.

A real task leaves a complete work trail:

User proposes task
→ Agent formulates plan
→ Calls tools
→ Reads tool results
→ Delegates to sub-agent
→ Generates result
→ User modifies, retries, or rejects
→ Final adopted version obtained

This entire process is the Production Trace . Traditional enterprise AI data (PDFs, knowledge bases, databases) tells the AI "what the enterprise knows." Production traces add a layer: how the enterprise actually completes work, where errors occur, and which results humans ultimately accept.

If traces and feedback don't feed back into evaluation after a task, the agent restarts from a similar starting point next time.

Trajectory broadens Continual Learning beyond model weight updates. After observing an error, teams must first locate the problematic layer:

Outdated facts → update search, tools, context, or memory.

Tool calling, task orchestration, or failure recovery issues → adjust the agent runtime framework (Harness).

Stable capability gaps → consider post-training or reinforcement learning.

Continual learning addresses the system composed of model, context, memory, tools, and runtime framework. A model weight version is merely a periodic artifact. The more valuable asset may be the ability to feed production experience back into evaluation and improvement so the same error recurs less often.

LangChain: How the Agent Runtime Framework Shapes Actual Performance

With production traces, teams need to decide which system component to change. LangChain co-founder Harrison Chase simplifies an agent into three parts: model, context, and Agent Runtime Framework (Harness) .

Harness is the agent's work environment and execution mechanism. It decides when to pass which context to the model, how tools are exposed and invoked, how files are read/written, when memory is retrieved, how sub-agents collaborate, how to compress overflowing context, and how to resume long-running tasks after interruption. After each model step, Harness organizes what the next step can see, call, and how tool results re-enter the loop.

Therefore, the same base model in different Harnesses can exhibit different stability and task performance. However, this doesn't require every enterprise to build a custom framework from scratch.

Chase advises restraint: use mature general-purpose Harnesses for generic tasks. Customization becomes important only when tasks increasingly deviate from the model's familiar distribution and depend heavily on internal processes, proprietary tools, industry rules, and long-horizon collaboration.

Example: file editing is a task models know well; but how a legal due-diligence task is split, which materials to read first, and which conclusions require lawyer review may need industry-specific control logic.

Production traces again play a role. Teams can diagnose from failure records whether the issue is insufficient context, flawed tool interface design, unreasonable task flow, or genuine model capability limits. After changes, they verify with the same business evaluation.

The precise relationship: the model determines part of the capability ceiling; Harness affects whether those capabilities can be stably released in specific business. It goes beyond "engineering glue" but cannot replace the model itself.

Mercor: What Counts as Completing an Enterprise Task

Once the system knows what can be changed, a key condition remains: how to judge that it actually improved.

Suppose an agent assists a customer renewal. It must read CRM, search historical emails, analyze contract terms, update system state, draft a renewal proposal, and initiate internal approval. Generating plausible text completes only a small part. The enterprise must specify which information must be verified, which systems must be updated, and what deliverables pass approval.

Training data and RL environment company Mercor describes such complete tasks using a Reinforcement Learning Environment (RL Environment) , split into three parts:

Business Worlds : emails, documents, spreadsheets, contracts, customer records, and historical business state.

Applications (Apps) : Salesforce, ServiceNow, Microsoft 365, or internal CRM and approval systems.

Tasks : work requirements plus verifiers or expert rubrics that judge completion.

Together, these give the agent a task resembling real work, not an isolated prompt. Enterprises must therefore articulate "what counts as done well."

This standard first enables evaluation: compare different models, Harnesses, or prompts to see which fits real business better. A step further, the same tasks and scoring can become reward signals for reinforcement learning.

Past discussions of enterprise AI data moats focused on internal documents and private data. Mercor's view reminds us that competitors with similar documents still may not know how the role actually works or what standards experts use to judge results.

Future hard-to-copy enterprise AI assets may extend from "what the enterprise knows" to how real tasks unfold, which systems the agent operates in, and what results count as success.

Mercor itself sells training data and RL environments, so "RL Environment becomes an AI moat" carries a clear business stance. This article treats it as a direction worth watching, not an industry-proven conclusion.

Legal AI Company Harvey: Plugging Evaluation into Product R&D

Trajectory covers experience, LangChain covers system, Mercor covers tasks and judging standards — three engineering pieces are in place. Legal AI company Harvey provides a product-R&D-level integration case.

Harvey serves professional legal work, characterized as long-horizon, material-intensive, and emphasizing client data sensitivity.

It first built a Legal Agent Benchmark containing near-real legal tasks, relevant materials, and domain-expert-authored rubrics. Model selection and training came after.

With its own benchmark, the team could answer basic questions: Does a new model truly do legal work better? Does a modified Harness make long tasks more stable? Does a post-training run improve legal ability or just overfit a test suite?

Harvey then fed these evaluation signals into research. It collaborated with external research and infrastructure teams to put the legal agent's Harness, open-weight models, and legal-task-specific post-training into the same experiment suite.

This path starts from real legal tasks, proceeds through defining evaluation, constructing environments, adjusting Harness, training models, and returns to product validation. Whether Harvey owns a particular model is just one link.

Harvey still uses frontier closed-source models, open-weight models, external training platforms, inference infrastructure, and domain expert networks. Building an application company's research capability does not require replicating a frontier model lab.

Harvey states its post-training uses public, synthetic, and expert data — no customer data. Its published performance gains are early research results from Harvey and partners, not yet independently validated across the industry.

This R&D sequence matters for application companies because of Private Eval : without evaluation built to their own business standards, swapping models, tweaking prompts, adjusting Harness, or post-training only yields "looks smarter," not "real business improved."

Four Talks Map to a Single Intelligence Production Line

Real enterprise work
→ Production traces
→ Private evaluation
→ RL environment & expert rubrics
→ Locate failure layer
├─ Context & memory
├─ Agent runtime framework
└─ Model
→ Improve & re-enter production
→ Generate new experience
→ Continuous learning

This is the author's view of a new application-layer AI research team ( Neo-Lab ): not an internal model fine-tuning team, but a production line that continuously converts real work experience into proprietary intelligence ( Intelligence Production Line ).

Frontier model labs typically start by improving general model capabilities, then release capabilities to the market to find problems. Application-layer teams start opposite: observe why an agent fails on a real customer task, then reverse-build evaluation, environment, Harness, and only then train models if needed.

The two routes are not mutually exclusive. Harvey's practice shows application companies still need frontier models, open models, and external infrastructure. "Ownership" here means controlling the key loop that decides how the system accumulates, evaluates, and improves.

Three Questions to Judge Whether a Learning Loop Exists

Returning to the opening question: why don't enterprises' daily real work experiences naturally become better AI next time?

Because experience only enters the learning loop when it is recorded as production traces, evaluated by the enterprise's own standards, localized to a specific system layer, modified, verified, and returned to production.

Past enterprise digitization turned business processes into software, then software behaviors into data. Sequoia's early-stage practices go a step further: extracting evaluatable learning signals from already-digitized work.

Different enterprises need not complete every link, and can defer the decision to train their own models. A more realistic starting point is to answer three questions: What are the real tasks? What counts as done well? Where does failure occur? If these three questions are unclear, the enterprise cannot yet claim to own its intelligence.