Jensen Huang on Open Agent Systems: 10 Insights Every Enterprise Needs

NVIDIA CEO Jensen Huang sat down with LangChain founder Harrison Chase in July 2026 for a 26-minute conversation. No prepared remarks. No product announcement. No carefully workshopped talking points fed through a comms team. Just two people who have been living inside the AI industry for years, comparing notes on what they're seeing.

I've gone through this conversation three times. The first pass I was just pulling quotes. The second time, I started noticing connections — things Huang said in minute four that Chase circled back to in minute nineteen, threads that ran through the whole discussion even when the topic seemed to shift. By the third viewing, it was obvious this wasn't another "AI is transforming everything" conversation. Huang and Chase were laying out an actual blueprint. Not for what AI might do someday. For how enterprises should be building with it right now.

Every one of the ten points below comes directly from the conversation. The analysis and the action items are mine — informed by watching how enterprises are actually deploying AI agents in production, which is usually messier and more interesting than the conference talks suggest.

1. AI crossed the usefulness line. Most companies haven't noticed yet.

Huang put it plainly: "The last 15 years we've been working in AI, but the last 6 months have changed everything."

This isn't hype. It's an observation about a specific convergence. Three things happened at roughly the same time, and their combined effect is bigger than any one of them alone.

Language models hit a threshold where they stopped being "impressive for a machine" and started being genuinely useful. Not in the sense of passing benchmarks — in the sense of completing real work that a human would otherwise have to do. The difference between a model that can write a plausible paragraph and a model that can read a support ticket, look up the customer's account history, check the return policy, and draft a response that actually resolves the issue. That gap was a lot wider than most people outside the field realize, and it closed fast.

Compute scaled to the point where running these models stopped requiring a supercomputer budget. The cost curve for inference has been steep and steady, and we've crossed into territory where deploying AI agents at scale is a line item you can budget for, not a moonshot you need board approval to attempt.

Multimodal capabilities broke through. Models can now see, hear, and reason across formats in a single system. This sounds like a feature. It's actually a category change. When a model can look at a screenshot of a dashboard, read the numbers, and explain what changed — that's not "text generation plus image recognition." That's a fundamentally different kind of tool.

The shift in adoption psychology is the part most companies are missing. When AI was a technology looking for a problem, adoption was curiosity-driven. Engineers tinkered. Executives commissioned proof-of-concept projects. Most of those pilots produced impressive demos and then died quietly because nobody could figure out how to get them from "works in a notebook" to "works in production without burning the building down."

Now the motivation has flipped. "When AI is useful," Huang said, "every company in the world wants to get their hands on it." It's no longer about exploring possibilities. It's about the competitive risk of not deploying what already works. And that changes everything about how organizations should be structured, funded, and measured.

2. The open ecosystem argument is about money, not philosophy.

There's a lazy way to frame the open-vs-closed AI debate that you see in a lot of coverage. Open-source evangelists on one side, waving flags about freedom and democratization. Proprietary platform defenders on the other, arguing that centralized development produces safer, more reliable systems. Both sides have talking points. Neither side describes what's actually happening in enterprise procurement decisions.

Huang doesn't buy either framing. His position is coldly practical, and he laid it out in three parts.

First, foundational AI technology has to be ubiquitous for the economics to work. You can't capture value from something that only operates inside your walled garden. NVIDIA's entire business model depends on AI being deployed absolutely everywhere — in every industry, every geography, every scale of company. That only happens if the underlying technology is widely accessible. A closed ecosystem that serves a few hundred enterprise customers is fine if you're selling per-seat SaaS. It's a rounding error if you're building the hardware that runs the entire AI industry.

Second, specialization kills the one-size-fits-all argument permanently. A biology lab running genomic analysis and a manufacturing floor running quality control inspection have fundamentally different requirements. Different tools. Different safety constraints. Different data formats. Different regulatory environments. The idea that one closed-source general model — no matter how capable — can serve both equally well is not a serious engineering proposition. Huang was explicit: Anthropic, OpenAI, and Google are doing brilliant work, but "people also need to build specialized, domain-specific, proprietary AI." The market is too fragmented for any single provider to cover.

Third, there's a flywheel effect that only works at scale. AI systems improve through use. More use generates more data. More data produces smarter models. Smarter models attract more use. That cycle spins fastest when the ecosystem is open, because every deployment anywhere feeds back into collective improvement. A closed system can run its own flywheel, but it's smaller and slower.

Chase reinforced this from the builder's perspective. LangChain's entire platform exists because developers need tools to build with a variety of models, not just one. The demand for flexibility isn't ideological — it's what actual engineering teams ask for when they're trying to ship.

3. "Harness engineering" is going to replace workflow as the organizing principle of enterprise software.

This is the most quietly radical claim in the entire conversation, and it's the one I've seen the fewest people discuss.

Huang said: "Most companies today are built on business processes. Most companies in the future will be built on Harnesses."

Let me define the term, because it's new and it's important. A Harness is everything wrapped around a large language model that makes it production-ready. Not the model itself. The scaffolding. Prompt templates. Tool descriptions. Memory management. Context handling. Task decomposition. Retry logic. Evaluation criteria. Access control. Monitoring. The model does the reasoning. The Harness organizes that reasoning into work that can be shipped, measured, and improved.

For decades, enterprise software has been organized around workflows — defined sequences of steps that people or systems execute in order. You map the process. You optimize for efficiency. You measure throughput. You hire people who are good at designing workflows and managing the exceptions.

A Harness-based organization works differently. Instead of defining the sequence of steps an agent should follow, you define what the agent can know, what tools it can use, how it should decompose complex tasks, and what "done" looks like. The agent figures out the sequence.

This sounds like a small shift in terminology. It's not. It changes where the engineering effort goes. In a workflow model, you spend most of your time on the happy path — what happens when everything goes right — and handle exceptions as edge cases. In a Harness model, the happy path is emergent. The engineering work is in defining the boundaries clearly enough that the agent stays inside them, and building evaluation systems that catch drift before it reaches production.

The most valuable people in a Harness-native organization aren't the ones who can write the most elegant code. They're the ones who can describe a tool precisely enough for an agent to use it without misunderstanding. Who can write evaluation criteria that catch subtle failures. Who understand which tasks should be decomposed and which should be handled whole.

4. The model matters less than you think. The Harness matters more than you think.

LangChain ran an experiment that should change how every engineering team allocates headcount and budget.

They took their Deep Agents evaluation framework — a benchmark for measuring how well AI agents perform complex, multi-step tasks — and used Nemotron 3 Ultra, an open-weight model from NVIDIA. They did not retrain the model. They didn't fine-tune it. They didn't run reinforcement learning or do anything clever with the weights. They worked exclusively on the Harness layer. Prompt design. Tool descriptions. Memory architecture. Task decomposition strategy. Evaluation logic. Everything around the model.

The result: a score of 0.86.

The best closed-source frontier model on the same benchmark scored 0.87.

That's a difference of 0.01. Statistically within the noise floor of most evaluation frameworks.

The cost difference? $4.48 per evaluation run for the Harness-engineered open-weight model versus $43.48 for the best closed-source option. They captured 99% of the performance at roughly ten percent of the cost, exclusively by improving everything that wasn't the model.

Huang's summary was characteristically direct: "Open-weight models are approaching frontier model performance, but at one-tenth the cost." His strategy recommendation: "Start with the most capable frontier model to find the capability ceiling, then use open models plus Harness engineering to achieve economical deployment."

The engineering implication here is uncomfortable for a lot of teams. The old instinct — "the agent isn't performing well enough, let's try a bigger model" — has become an expensive habit. Most teams are running agents on the most capable model they can afford without having done the basic Harness engineering that would let a cheaper model match or exceed that performance. It's the equivalent of buying a faster server because your database queries are unoptimized.

5. Open-weight models at 1/10 the cost redraw the entire application map.

The cost observation from the LangChain experiment has a second-order effect that's easy to miss if you're focused on the headline number.

It's not just that you save money on the inference you're already doing. It's that entire categories of AI applications suddenly cross the line from "technically possible but economically insane" to "let's ship it."

Long-running agent tasks — the kind that require hundreds of sequential inference calls to research a complex topic, analyze multiple documents, or work through a multi-stage reasoning problem — were previously too expensive to deploy at any meaningful scale. When each inference call costs a meaningful fraction of a cent and your agent needs to make 200 of them to complete one task, the unit economics don't close for most use cases. At a tenth of the cost, they do.

The same math applies to always-on monitoring agents that watch real-time data streams for anomalies, quality assurance systems that run thousands of parallel evaluations against every change, and agents embedded in consumer-facing products where the margin on a single inference has to be measured in fractions of a cent.

This isn't speculation about future cost curves. We're already there. The open-weight models available today are good enough and cheap enough to make these use cases viable. The bottleneck isn't model capability or inference cost. It's that most organizations haven't updated their internal project evaluation criteria to reflect the new economics.

Huang framed this as a supply chain decision, not a technology preference. "Use the most capable frontier model to find the ceiling, then deploy with open models." That's how you'd think about any component in a manufacturing process. Prototype with the premium option to understand the upper bound of what's possible. Switch to the cost-effective option for production. The fact that this sounds novel in AI says more about how immature the industry's procurement practices are than about the technology.

6. Your company's core intelligence cannot be a service you subscribe to.

Huang was most emphatic here, and his language left no room for diplomatic hedging.

"A company is essentially a collection of proprietary, important workflows," he said. "Your proprietary super-agent will become the core asset of your enterprise."

Then the hard line: "It makes no sense at all for a company to outsource its core intelligence to a third party."

Chase backed him up from the builder's side: "Your Agent Harness is your memory. Once you choose closed-source, the data is no longer yours."

The logic chain is clean and ruthless. A company's competitive advantage increasingly lives in the proprietary intelligence embedded in its operations. How it qualifies sales leads. How it handles edge cases in customer support. How it routes decisions through layers of approval. How it spots operational anomalies that competitors miss. How it prices dynamically based on signals nobody else is tracking. If that intelligence runs on a closed platform, the platform owner controls your upgrade path, your cost structure, and — most critically — your data.

Huang sees this as structural, not temporary. It's not about whether today's closed-source models are better or worse than open-weight alternatives. It's not about current pricing. It's about the fact that intelligence that differentiates your business is a core asset. Core assets need to be under your control. That's not a technology opinion. That's basic corporate governance.

The implication is that every enterprise needs an internal AI capability — not necessarily building foundation models from scratch, but building the Harness layer, the evaluation systems, the tool integrations, and the domain-specific knowledge that turns a general model into a company-specific super-agent. That capability becomes as fundamental as having an internal legal team or an internal finance function. You can outsource pieces of it. You can't outsource the whole thing without giving away what makes your company your company.

7. Your engineers are about to stop "writing code" the way you think of it.

"NVIDIA engineers today prefer building Agents over writing Python," Huang said.

This isn't a prediction about Python dying. It's a description of how the engineering job is changing in real time, inside one of the most technically sophisticated companies on the planet.

Writing code used to mean defining functions, services, and data flows. You designed a system by specifying what it should do and how it should do it, down to the level of individual operations. The deliverable was a function with a contract: these inputs produce these outputs, with these side effects, within these performance bounds.

Building an agent is different. The deliverable is a role description, not a function signature. "You handle customer refund requests." A tool set: "You can query the order database, check the return policy, and issue Stripe refunds." Evaluation criteria: "Refunds are processed correctly. Customer satisfaction is maintained or improved. Edge cases that don't fit the policy are escalated to a human." Exit conditions: "If you can't resolve the request within three exchanges, hand off with a summary of what you've done and what you need."

The mechanical part of software engineering — translating requirements into syntax, wiring up APIs, handling error cases — gets automated. This is already happening. The design part — deciding what an agent should know, what it should be able to touch, how we'll measure whether it's working, and where the handoff points are between agents and humans — that's where the valuable engineering work moves.

Huang's prediction on headcount is worth paying attention to, because it runs counter to the "AI will replace developers" narrative that's been circulating for years. He expects AI won't reduce demand for software engineers. It will redefine what they do. And the new definition is harder, not easier. Designing good evaluation criteria for an open-ended agent is more intellectually demanding than writing a unit test for a deterministic function. Defining tool boundaries that are permissive enough to be useful but restrictive enough to be safe requires judgment that no model currently has.

Think about it this way: typing was once a specialized professional skill. Now everyone types, and the value moved to what you type about and how well you think. Coding is on the same curve. The people who thrive won't be the fastest typists. They'll be the ones who can decompose a business problem into agent-shaped pieces.

8. The most capable AI won't be a single model. It will be a team.

Harrison Chase introduced the concept of "Composite Agents" — systems that combine multiple models to produce intelligence that exceeds what any single component could deliver alone.

The architecture is conceptually simple. One powerful foundation model serves as the general-purpose reasoning engine — broad awareness, good judgment across domains, keeps the overall task moving forward. Multiple fine-tuned specialist models handle narrow, high-stakes subtasks where domain expertise matters more than general reasoning ability. A Harness layer coordinates the collaboration, routing the right subproblem to the right model at the right time.

The sports analogy is almost too tidy but it works. The foundation model is the team captain — sees the whole field, makes the high-level calls, keeps everyone coordinated. The specialist models are position players — one handles legal compliance review, another crunches financial model outputs, a third manages customer sentiment analysis. The Harness is the coaching system that decides who's on the field for each play and how they communicate.

This matters for how organizations think about model procurement. The dominant mental model right now is that you pick a model and stick with it. Maybe you change models when a new release comes out, but at any given time, you're running one model. Composite Agents break that assumption. You don't wait for one model to be good at everything. You build a roster. Some might be open-weight and cheap. Some might be proprietary and expensive but uniquely good at one thing. The Harness manages the composition, and the composition is what delivers the result.

The economic implication is significant. Most organizations are currently overpaying for generality they don't need. They're running every task through the most capable model they can access, because that's the simplest way to deploy. But if 70% of your agent's workload is routine classification, summarization, or extraction tasks that a smaller specialist model handles perfectly, you're burning money on inference for capability you're not using.

9. AI is a vacuum cleaner. Treat it like one.

Huang said something that's going to make a lot of AI product teams uncomfortable, and I think that's the point.

"It's electrons, not atoms. It's not biological. It has no consciousness. It's a tool — kind of like my vacuum cleaner."

He wasn't being glib. He was making a deliberate, precise argument about the mental model you should use when you design products and systems around AI, and the argument has direct engineering consequences.

When you treat AI as a digital employee, you design for a relationship. You give it vague instructions and expect it to fill in the gaps. You get frustrated when it doesn't "understand" what you meant. You spend cycles on prompt refinement that should have been spent on clearer instruction design. You build interfaces that look like chat windows because that's how you talk to colleagues. You add personality and "warmth" because that's what you'd want in a teammate.

When you treat AI as a smart tool, you design for a capability. You give it explicit instructions, a clearly defined tool set, and verifiable acceptance criteria. You get reliable, measurable results. And — this is the part that stings — you stop asking it to do things it's not designed for, the same way you don't ask your vacuum cleaner to wash the dishes.

The mental model shift is engineering pragmatism, not AI skepticism. Huang's point isn't that AI isn't impressive. It obviously is. His point is that personifying it leads to bad engineering decisions. You don't ask your vacuum cleaner to figure out which rooms need cleaning based on its "understanding" of your household. You tell it which rooms, what time, what to skip. AI agents work best the same way. Explicit inputs. Defined tools. Measurable outputs. The power isn't in the vagueness. It's in the precision.

There's a deeper implication here for how teams should be managed. If you treat AI as a digital employee, you'll hire prompt engineers and measure them on "quality" — a subjective assessment that changes depending on who's evaluating. If you treat AI as a tool, you'll hire systems engineers who design evaluation frameworks with quantitative metrics, and you'll measure them on whether the system hits its targets. These are different people with different skills. Hiring for the wrong mental model is expensive.

10. You don't have to wait for the perfect model. You probably never will.

"We will always have frontier models and specialized agents coexisting," Huang said. "Many jobs will never need a model swap."

This is the permission slip a surprising number of engineering teams are waiting for, often without realizing they're waiting.

There's a persistent anxiety in enterprise AI that you should wait. Wait for the next model release. Wait for the benchmarks to tick up another few points. Wait until the technology "matures" — a word that in practice means "until I feel certain enough that I can't be blamed if something goes wrong." This anxiety is understandable. Enterprise AI deployment is full of stories about demos that worked and production systems that didn't. Nobody wants to be the person who shipped the thing that hallucinated in front of a customer.

But Huang's message cuts through that anxiety with a simpler truth. The models are good enough now for an enormous range of real tasks. Not good enough for everything, and not good enough to deploy without guardrails and evaluation systems. But good enough to start. And the gap between "good enough to start" and "good enough to be comfortable" is something you can only close by deploying, measuring, and iterating.

"The biggest cost is waiting," Huang said. "The best way to learn is to do it."

This is not a motivational poster. It's an observation about the specific nature of agent systems. These systems get better through use. Every production deployment generates data about what works and what breaks. Companies that start now accumulate operational knowledge — which prompt patterns hold up under load, which architectures degrade gracefully, which edge cases recur and need explicit handling — that late starters can't shortcut their way past. The competitive moat around enterprise AI isn't access to the best model. It's everything you learn by running agents in production for six months before your competitors do.

The practical advice embedded in this insight is deceptively simple. Pick a narrow, high-value use case. Something specific enough that you can define success and failure clearly. Deploy it. Not as a proof of concept behind a feature flag that nobody checks. As a real deployment that real users interact with, producing real metrics that you track over time. The learning curve is steepest at the very beginning. Get through it.

The shape of things

Twenty-six minutes. Two people. No slides, no demos, no product announcements. That conversation is the closest thing to a strategy document the AI industry has produced this year, and it happened in a format most corporate strategy teams would consider too casual to take seriously.

The ten points form a coherent position, and the coherence is what makes it powerful. Open agent systems aren't the ideological choice — they're the pragmatic one, selected by a company whose business depends on choosing technologies that actually work at scale. Harness engineering is the new core competency, replacing workflow design as the organizing principle of enterprise software. Models are trending toward commodity status faster than most teams' budgeting cycles can adapt. Data sovereignty is a structural requirement, not a negotiation point. Engineers need new job descriptions, and the companies that write them first will attract the talent that figures out how to make this work. The clock is running — not because AI will replace your business, but because the companies that build production Harness engineering capability six months before you do will have six months of operational data and institutional knowledge you can't shortcut your way past.

Huang ended one exchange with a line that should probably be printed somewhere every engineering team can see it: "This is the most exciting time. Don't wait."

He's right. "Don't wait" means start building. Pick one thing. Deploy it this month. Learn from it. Repeat. The competitive advantage doesn't come from choosing the right model. It comes from having run more experiments, accumulated more production data, and internalized more hard-won lessons than anyone else in your market.

The conversation took 26 minutes. The strategy will take years. Start now.

Sources: Jensen Huang and Harrison Chase conversation on open agent systems, July 2026 (YouTube). Analysis incorporates NVIDIA GTC 2026 public data and LangChain Deep Agents benchmark results. All direct quotations attributed to Huang and Chase are from the original conversation transcript.