Yangqing Jia Launches Intent Lab: Fleet Turns One-Line Prompts Into Production Systems

A little over a year after Lepton AI became part of NVIDIA, Yangqing Jia is starting again. His new company, Intent Lab, is not launching with a conventional chatbot, cloud market

发布于 2026年7月31日generalGEO 评分: 012 次阅读
The image is a promotional graphic for Intent Lab Fleet. The background is dark, featuring blurred elements such as the Intent Lab Fleet logo and a speedometer. The text 'Intent Lab Fleet' and 'GLM-5.2 6.3× Faster' is highlighted, with 'One-Shot Database · Verified File System' displayed below. In the bottom left corner are the Z.ai and GLM-5.2 logos, and in the bottom right is a folder icon containing a shield and a checkmark. This image relates to the content about Intent Lab Fleet in the document, visually showcasing its technical highlights.

Yangqing Jia Launches Intent Lab: Fleet Turns One-Line Prompts Into Production Systems

Introduction

A little over a year after Lepton AI became part of NVIDIA, Yangqing Jia is starting again.

His new company, Intent Lab, is not launching with a conventional chatbot, cloud marketplace, or developer IDE. Instead, the company is building Fleet, which it describes as an autonomous engineering team that turns a high-level intent into production-grade software.

Intent Lab's first public demonstration includes three very different systems:

  1. A GLM-5.2 inference engine optimized beyond stock TensorRT-LLM.
  2. A SQLite-compatible database built from a one-line requirement.
  3. A distributed file system for AI agents with formal verification and fault testing.

At first glance, the projects do not look like one product category.

That is the point.

Intent Lab says the actual product is the engineering system behind them. Fleet is intended to perform the work between a vague software request and a system that can be benchmarked, verified, operated, and evolved in production.

The early performance numbers in this article come from Intent Lab's own launch materials. They are promising demonstrations, not independent benchmark certifications. The company has not yet published enough reproducibility detail for outside teams to confirm every result under identical conditions.

Yangqing Jia Is Starting Another Infrastructure Company

Yangqing Jia's career has repeatedly returned to infrastructure.

He is best known for creating Caffe while at UC Berkeley and later working on major AI infrastructure efforts including PyTorch and ONNX.

After leaving Alibaba in 2023, Jia co-founded Lepton AI, a company focused on making GPU compute and model deployment easier for developers.

Lepton's original pitch combined a Python-native developer experience with infrastructure that could run AI workloads across multiple GPU providers.

The company was acquired by NVIDIA in 2025 in a deal publicly described at the time as worth hundreds of millions of dollars. Later industry reports placed the figure at roughly $700 million, although NVIDIA did not publish a final acquisition price.

Lepton's technology became part of NVIDIA DGX Cloud Lepton.

com/cms-assets/image/2026/07/32165d25-ec8e-45a4-8ec2-4b9895592d90-c88a130e-0f9f-4f13-a721-065d3cf997fc.png)

NVIDIA currently describes DGX Cloud Lepton as an active platform that unifies GPU compute across cloud providers and customer-owned infrastructure for development, training, and inference.

That current status is worth clarifying because commentary after Jia’s departure argued that the original startup-style Lepton product and its open-source ambitions did not survive the acquisition unchanged.

The public evidence supports a more careful description:

  • The standalone Lepton company was absorbed into NVIDIA.
  • Its brand and technology became part of DGX Cloud Lepton.
  • NVIDIA still operates and documents DGX Cloud Lepton today.
  • The public Python library and lep CLI remain available.
  • Some former expectations around open-sourcing deeper platform components were never realized in the form observers expected.

Jia later served as NVIDIA’s vice president of system software before leaving the company in 2026.

A Brief Stop at Hyperbolic

In July 2026, Hyperbolic announced that Jia had joined the GPU-infrastructure company as an advisor.

Hyperbolic described his background across Caffe, ONNX, PyTorch, Lepton AI, NVIDIA, Google, Facebook, and Alibaba Cloud as particularly relevant to its work on GPU access and infrastructure.

This image shows content related to Hyperbolic, with the Hyperbolic logo in the upper left corner. On the left side is a black-and-white portrait of Yangqing Jia, and on the right side is a statement from him indicating that Hyperbolic is working to help developers and enterprises access the computing power needed to train, deploy, and scale AI systems. As an advisor to Hyperbolic, he expresses support for the team's efforts to advance AI, with his identity noted as Hyperbolic Advisor and Lepton AI Co-founder, which aligns with the background information in this document about his joining Hyperbolic as an advisor.

That role turns out not to have been his main next move.

On July 29, Jia publicly introduced Intent Lab.

His framing was different from Lepton AI.

Lepton focused on giving developers easier access to compute.

Intent Lab is focused on giving an autonomous engineering system the ability to create and maintain the software that runs on that compute.

Jia summarized the shift by saying that his teams had spent their careers carefully building large systems one at a time. What interested them now was a system capable of producing many such systems.

This is a social media post published on July 29, 2026, by Yangqing Jia under the handle @jiayq. The content mentions that his team has always built large systems by hand, covering open source, cloud infrastructure, and other projects, with a focus on carefully architecting one system at a time. What interests them now is building the "source" that can generate thousands of such systems. The post relates to Jia's founding of Intent Lab as discussed in this document, corresponding to his core direction of shifting from building large systems one at a time to creating an autonomous engineering system capable of producing many systems at scale.

Fleet Is the Product Behind the Three Demos

Intent Lab calls its autonomous engineering system Fleet.

The company describes it as a team rather than a single coding agent.

The distinction matters.

A typical coding agent can edit files, run commands, fix tests, search a repository, and implement a feature.

Fleet is presented as a system that can coordinate a longer engineering process.

Intent Lab’s stated goal is to cover the work required to move from a high-level request to a production system with measurable

behavior, verification, and a path to continued improvement.

The first three demonstrations were chosen to test that claim across very different engineering domains.

Demo One: Optimizing GLM-5.2 Beyond Stock TensorRT-LLM

The most technically striking launch result is a GLM-5.2 inference engine.

The initial instruction was essentially one engineering objective:

Re-engineer TensorRT-LLM so GLM-5.2 runs efficiently on Grace Blackwell nodes,
identify optimization opportunities, implement them, and verify them autonomously.

TensorRT-LLM is already NVIDIA's production-focused inference stack for large language models.

NVIDIA documents features such as multi-GPU and multi-node serving, in-flight batching, paged KV caching, quantization, optimized kernels, and Python and C++ runtimes.

Improving performance on top of that stack is therefore a more demanding target than optimizing an unoptimized reference implementation.

Intent Lab Reports a 6.3× Output-Speed Increase

Intent Lab says Fleet began with stock TensorRT-LLM at approximately:

102 tokens/s

An optimized runtime reached:

161 tokens/s

After adding the company's optimized speculative-decoding path, the system reportedly reached:

647 tokens/s

That is approximately 6.3× the original output speed.

Image showing Intent Lab's optimization results for TensorRT-LLM. The goal was to run GLM 5.2 on Grace Blackwell nodes, identifying optimization categories and autonomously implementing and verifying them, achieving a 6.3× output speed improvement. Optimizations are divided into four categories: kernel, runtime, communication, and speculative decoding, with improvements of 24%, 16%, 18%, and 4.0× respectively. The image also shows output speed comparisons across different optimization stages, from 102 to 181 to 647, along with a performance gain breakdown chart, clearly illustrating the optimization effects.

Intent Lab says the benchmark used two Grace Blackwell nodes.

The company breaks the performance work into four categories.

Kernel Optimization: +24%

Fleet reportedly applied kernel fusion and generated low-level PTX/SASS paths for instruction-level control.

Runtime Optimization: +16%

Intent Lab says the runtime removed repeated host-to-device metadata copies from steady-state decoding through H2D batching and zero-copy techniques.

Communication Optimization: +18%

Fleet reportedly used a fused MNNVL all-reduce path that incorporates residual addition and RMSNorm into the collective operation.

Speculative Decoding: About 4×

The largest individual gain came from speculative decoding.

Intent Lab says an optimized DSpark drafter proposes several tokens and the main model verifies them in batches, increasing decode throughput significantly.

The company reports the complete end-to-end result as a 534% improvement over its stock baseline.

These figures are Intent Lab's own measurements. Hardware configuration, workload details, batch settings, output length, precision, concurrency, and software revisions can materially affect inference benchmarks.

Fleet's Optimization Loop Looks More Like a Team Than a Single Pass

Intent Lab says Fleet follows a repeated engineering loop:

  1. Roofline analysis
  2. Bottleneck identification
  3. Propose
  4. Verify
  5. Compound
  6. Return to the next bottleneck

If a proposed optimization

fails validation, the system goes back and tries again.

The “compound” step matters because performance engineering often fails when individually successful optimizations interfere with one another.

Fleet is designed to retain changes only after verifying that the combined system still works.

Why GLM-5.2 Is a Demanding Target

GLM-5.2 is Z.ai’s flagship model for long-horizon tasks.

Its official model card highlights a one-million-token context window, long-horizon coding and agent workloads, flexible reasoning effort, an improved sparse-attention architecture, and open weights under the MIT license.

Large models with long context and agentic workloads create difficult serving problems.

The fastest implementation depends on interactions among kernel design, memory bandwidth, KV-cache behavior, interconnect bandwidth, batch size, speculative decoding, quantization, host scheduling, and communication collectives.

That makes inference optimization a useful stress test for an autonomous engineering system.

Demo Two: A SQLite-Compatible Database From One Requirement

Fleet’s second public project moves away from GPU kernels entirely.

Intent Lab asked the system to build a SQL database engine that is compatible with SQLite.

The launch material shows a requirement equivalent to:

Build a SQL database engine that is compatible with SQLite,
in the sense that it can pass ALL sqllogictest test cases,
and performance must be comparable or better.

Intent Lab says Fleet did not start from SQLite’s source code or documentation.

Instead, it treated the existing system’s behavior and test corpus as the acceptance contract.

The image illustrates Fleet’s intent and process for building a SQLite-compatible SQL database engine. The intent is to build a SQL database engine compatible with SQLite based solely on behavior and a test corpus, without relying on existing code or documentation. The process includes iterative design and implementation, division of labor, and model-agnostic, cost-efficient approaches. It also presents an operation sequence diagram showing the activities of different roles in the project. The diagram is closely related to the context and visually presents Fleet’s intent and process for building the database engine as described in the text.

The company reports that the final system passed approximately six million SQLite compatibility tests.

That figure comes from Intent Lab and has not been independently reproduced for this article.

One Fleet, Multiple Engineering Roles

Intent Lab visualizes the database build as several roles working throughout the project:

  • Decision-making.
  • Architecture.
  • Coding.
  • Testing.
  • Review.
  • QA.

The roles do not simply operate in a linear handoff.

Architecture can change while implementation proceeds. Testing continues while features are added. Review and QA remain active as the codebase grows.

The Cost Depends Heavily on the Model

Intent Lab also published a cost comparison.

For the same database build, the company says a run using Opus 4.8 cost roughly $2,000**, while a run using open-source models cost approximately **$350.

The numbers are company-reported and depend on model prices, token consumption, agent orchestration, and infrastructure.

They nevertheless illustrate a major economic question for agentic engineering: what is the cost of a complete successful project rather than the price of one model call?

Demo Three: A Formally

Verified File System for Agents

The third demonstration is a distributed file system called AgentFS.

Intent Lab says it was designed specifically for agent workloads in cloud environments.

AI coding and research agents tend to create a distinctive storage pattern:

  • Many temporary sandboxes.
  • Large numbers of small files.
  • Frequent creation and deletion.
  • Shared cloud storage.
  • High metadata churn.
  • Short-lived repositories.

Intent Lab says it evaluated existing systems including Amazon EFS and S3FS, found limitations for this workload, and built a new file system instead.

The company claims significant speedups over the compared systems across metadata-heavy operations.

The image showcases the key features of the AgentFS distributed file system. The top title reads "10x Faster Distributed File System." The middle section compares the performance of AgentFS, EFS, and S3FS on Git repo operations such as git clone and git status, with AgentFS performing best. The bottom section describes AgentFS's purpose, continuous verification, fault detection and repair, and formal verification features, such as formal model checking across 1.8M states, to ensure a level of correctness that coding agents cannot achieve through simple testing.

Again, these are Intent Lab's launch benchmarks, not independent third-party results.

Formal Verification Found a Bug the Coding Agent Missed

The most important part of the file-system example is not the benchmark chart.

It is verification.

Intent Lab says Fleet formally modeled the core protocols and explored roughly 1.9 million states.

That process uncovered a bug in code produced by a coding agent.

The bug could lead to a transient corrupted state during distributed create/delete behavior.

Intent Lab says Fleet then fixed the implementation and re-ran the verification.

The company also reports approximately 300 integration tests, plus fault injection and fuzzing with injected crashes and replicas.

Formal verification is valuable here because file systems are particularly vulnerable to rare interleavings.

Traditional tests may show that the common path works. A model checker can systematically search combinations of states that ordinary test suites may never encounter.

This principle is well established outside Intent Lab. File-system researchers have used model checking for decades to expose crash-consistency and metadata bugs in mature systems.

The novel claim here is that an autonomous engineering system can incorporate this style of verification into its own build loop.

The Missing Layer Between "Code That Runs" and Production Software

Jia's central argument is broader than any of the three demos.

Modern models can write code quickly.

That does not mean the result is software a company should operate for years.

He argues that the remaining gap is not simply another jump in model coding ability.

It is an engineering layer around the model.

This is a tweet from Yangqing Jia, with a verified badge next to the account name, expressing his core point: current models write code quickly, but there remains a real gap between runnable code and production-grade software that companies need to operate for years. He argues this gap is not a limitation of model capabilities, but rather a missing layer. This tweet corresponds exactly to Yangqing Jia's core argument mentioned earlier, focusing on the missing engineering layer needed to build production systems around model-generated code.

A production system needs more than an implementation.

It needs requirements, architecture, interfaces,

trade-offs, coordination, testing, performance analysis, reliability work, verification, fault handling, maintenance, and feedback from production.

A coding model may participate in all of those activities.

Fleet’s thesis is that they need to be organized into one autonomous system.

Fleet Breaks Engineering Into Six Stages

Intent Lab describes its engineering process in six stages.

The image illustrates the six stages of the Fleet workflow. In the Understand stage, Fleet transforms vague intent into concrete outcomes, constraints, and acceptance criteria; in the Design stage, Fleet weighs trade-offs and defines interfaces, components, and long-term system structure; in the Coordinate stage, the system splits large projects into tasks, manages dependencies, and keeps implementation aligned with design; in the Build stage, implementation and architecture evolve together as new information emerges during development; in the Verify stage, Fleet validates work through methods including formal proofs, with issues surfacing as code changes; in the Evolve stage, the system reveals real-world behavior in production, Fleet observes performance, and feeds usage, reliability, and cost back into design for continuous software improvement.

1. Understand

Fleet is supposed to turn vague intent into a concrete outcome, constraints, acceptance criteria, and measurable definitions of success.

2. Design

Fleet weighs trade-offs and defines interfaces, components, and long-term system structure.

3. Coordinate

The system splits a large project into tasks, manages dependencies, and keeps implementation aligned with the overall design.

4. Build

Implementation and architecture evolve together as new information appears during development.

5. Verify

Verification can include unit tests, integration tests, benchmarks, formal proofs, model checking, fault injection, fuzzing, and runtime validation.

6. Evolve

Fleet is intended to observe production performance and feed information about usage, reliability, and cost back into the design.

This is the point where Intent Lab’s ambition extends beyond an autonomous coding agent.

The target is not only software generation.

It is autonomous software ownership.

“A Principled Engineering Team” Is the Product Metaphor

Intent Lab describes Fleet as operating like a principled engineering team.

That is a useful metaphor because no one member of a strong engineering organization is responsible for every concern.

One engineer may optimize kernels. Another may design a storage protocol. Someone else maintains benchmarks. Another person reviews reliability.

Fleet attempts to turn those responsibilities into coordinated agent roles.

The hard question is therefore not only whether an LLM can write high-quality code.

It is whether multiple autonomous processes can maintain a coherent system architecture while building, testing, optimizing, verifying, and revising the same project over a long horizon.

The Economic Argument: Software Can Become More Customized

Jia also makes an economic argument.

For decades, software development had a large fixed cost.

The rational strategy was to build one product, sell it to many users, and ask users with different needs to adapt to the same software.

If autonomous engineering reduces the fixed cost of building and maintaining a system, that equation changes.

The image shows a tweet by Yangqing Jia. The tweet reads: "If this works, the economics of computer engineering will change forever. For 50 years, the wise approach was to build one piece of software and sell it to as many people as possible, despite different needs. That can change now. The world will see much more customized software." The tweet was posted 8 hours ago, with "Edit" and "..." options in the top right corner. This image relates to Yangqing Jia's economic argument in the document and directly presents his thoughts on the changing economics of computer engineering.

oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/dce27f23-7161-488d-aa67-f2ccc932be13-bdea7efd-b790-4fe7-97f2-e828d77b2750.png)

A company might be able to justify software for a smaller group of users.

An internal team could build a system for a workflow that would previously remain on a backlog for years.

An infrastructure group could create a specialized engine instead of accepting the limitations of a generic product.

Intent Lab says it plans to work with outside organizations on this type of project: systems with substantial engineering value that companies have postponed because the required work is too large.

This Is Not the Same as "One Prompt Builds Any App"

The launch demos can easily be reduced to a viral headline:

One sentence created a database.

That framing misses most of the work Fleet claims to perform.

The database example starts with one requirement, but the system then carries out a long engineering process.

It must repeatedly make design decisions, generate code, run tests, diagnose failures, revise architecture, review behavior, and repeat.

The user provides a short intent.

The machine does not necessarily perform a short task.

A better evaluation asks how much human intervention was required, how much compute the run consumed, how many retries occurred, how well the result was verified, whether another team can reproduce it, and whether the system can be maintained after the demo.

What Remains Unproven

Intent Lab's first results are ambitious, but the public material leaves important questions open.

Independent Reproduction

The 6.3× inference result, SQLite test count, AgentFS performance, and formal-verification figures are company-reported.

Independent reproduction would make the claims substantially stronger.

Fleet Architecture

Intent Lab has not publicly documented enough detail to reconstruct Fleet itself.

It is not yet clear which base models are used for each role, how agents share state, how tasks are scheduled, how conflicts are resolved, how specifications are stored, or how much human supervision remains available.

Production Ownership

Building a benchmark-quality system is not identical to operating it for years.

The "Evolve" stage may be the hardest part of the thesis because a production owner must handle security patches, dependency changes, hardware shifts, incidents, cost changes, feature requests, and backward compatibility.

Economics

Autonomous engineering can be cheaper than a human team for some tasks while still consuming substantial inference and compute.

Intent Lab's own database example shows that model choice can change total project cost by several times.

A More Accurate Way to Think About Intent Lab

Intent Lab is not simply another coding-agent startup.

Its thesis is closer to autonomous systems engineering.

The target unit of work is not a code completion or a pull request.

It is a production system.

That is why the first three examples look unrelated.

An inference engine, a database, and a file system share little at the product level.

They share an engineering pattern:

Intent
→ specification
→ architecture
→

Coordinated implementation
→ measurement
→ verification
→ iteration
→ production evolution

Fleet is intended to automate that pattern.

Whether it can do so reliably across many real companies remains an open question.

But the ambition is clear.

FAQ

What is Intent Lab?

Intent Lab is a new AI infrastructure and autonomous engineering company co-founded by Yangqing Jia and other experienced systems engineers. Its first product, Fleet, is designed to turn high-level software intent into production-grade systems.

What is Fleet?

Fleet is Intent Lab's autonomous engineering system. The company describes it as a team of coordinated agents that can understand requirements, design architecture, build code, verify results, and continue evolving software after deployment.

Did Fleet really make GLM-5.2 inference 6.3× faster?

Intent Lab reports that its optimized GLM-5.2 engine increased output speed from 102 tokens/s on stock TensorRT-LLM to 647 tokens/s on two Grace Blackwell nodes. The number is a company-reported benchmark and has not yet been independently reproduced in the sources reviewed here.

Did Fleet build a database from one prompt?

Intent Lab says the initial database requirement was a single prompt asking for a SQLite-compatible SQL engine. Fleet then autonomously performed architecture, coding, testing, review, and QA until the company says the system passed roughly six million compatibility tests.

What is AgentFS?

AgentFS is a distributed file system created in Intent Lab's third launch demonstration. It is optimized for AI-agent workloads involving many sandboxes and small files, and Intent Lab says its core protocols were checked with formal model verification.

What is the difference between Fleet and a normal coding agent?

A normal coding agent typically works on code changes inside an existing project. Fleet is intended to coordinate a full systems-engineering lifecycle including requirement definition, architecture, implementation, performance work, formal verification, fault testing, and production evolution.

Is Fleet open source?

Intent Lab has publicly shared demonstrations and its product thesis, but the sources reviewed for this article do not show a public release of the complete Fleet orchestration system. Check Intent Lab's official site for the latest availability.

Is NVIDIA DGX Cloud Lepton still operating?

Yes. NVIDIA currently maintains product pages and documentation for DGX Cloud Lepton, including workloads, node groups, endpoints, Dev Pods, batch jobs, and bring-your-own-compute functionality. This is separate from debate over how closely the NVIDIA product preserved Lepton AI's original startup roadmap.

Related Tools

  • Intent Lab: The company building Fleet, an autonomous engineering system for turning intent into production software.
  • NVIDIA TensorRT-LLM: NVIDIA's production inference framework for optimizing and serving large language models on NVIDIA GPUs.
  • TensorRT-LLM on GitHub: The open-source repository for NVIDIA's LLM inference stack.

GLM-5.2: Z.ai's open-weight long-horizon model used in Intent Lab's inference-engine demonstration.

  • NVIDIA DGX Cloud Lepton: NVIDIA's platform for building and deploying AI workloads across a network of GPU compute providers.
  • SQLite: The database whose behavior and compatibility tests were used as the target for Fleet's database demonstration.

Related Links

Summary

Yangqing Jia's new company, Intent Lab, is building Fleet around a different unit of AI work: not code generation, but the complete production-system lifecycle.

Its first demonstrations span GLM-5.2 inference optimization, a SQLite-compatible database, and a formally verified distributed file system. Intent Lab reports a 6.3× inference speedup, roughly six million database compatibility tests, and model checking across about 1.9 million file-system states.

The common idea is a six-stage engineering loop—Understand, Design, Coordinate, Build, Verify, and Evolve—that tries to reproduce the responsibilities of a strong engineering organization with autonomous agents.

The results are still early and largely self-reported, so reproducibility and long-term production operation remain the real tests.

Fleet's most important claim is not that AI can write code from one sentence; it is that an autonomous system can take responsibility for the engineering work between a sentence and software worth running for years.