Decoding Claude Code and Understanding Agent Harness | A Conversation with Xinlu Lai

"Agent Harness" is just another way of saying "wrapper."

👦🏻 Podcast interview: Koji

🥷 Edited by: Crossing

🧑‍🎨 Layout: Zeoooo

🚥 Not long ago, Claude Code's source code leaked, giving us a complete view of many key Agent Harness modules — an excellent teaching specimen. And during a period of rapid technological change, proactively understanding new tech often yields substantial cognitive returns.

So this week, Crossing invited Xinlu Lai to talk about Agent Harness. Xinlu is the founder of the ShareAI open-source community. His tutorial, Learn Claude Code, which he writes and maintains, has earned over 50k stars on GitHub.

In this episode, we break Agent Harness down from a buzzword into engineering terms, introducing its three-layer framework: running (execution layer) → running long (state layer) → running stable (governance layer).

We also梳理 several mechanisms in Claude Code worth learning from: the "more context, less control" philosophy, the "zero-context management" approach, the relay-style handoff strategy for long-horizon tasks, and the "dreaming" memory maintenance and iteration mechanism that makes Agents smarter with use.

As a typical one-person company, Xinlu just closed a multi-million-dollar funding round. He also shares his unique perspective on OPC, even arguing that "in the future there will only be zero-person companies, not one-person companies" — a thought-provoking take.

Listen on WeChat:

Listen on Xiaoyuzhou:

🎬 The video podcast is also now live on Koji's WeChat Channels, Xiaohongshu, Bilibili, YouTube, and other platforms.

Rapid-Fire Q&A

👦🏻 Koji

Let's start with our usual rapid-fire round. Xinlu, how old are you?

👨🏻‍💻 Xinlu Lai

👦🏻 Koji

Where did you go to school?

👨🏻‍💻 Xinlu Lai

Henan University of Technology.

👦🏻 Koji

MBTI and zodiac sign?

👨🏻‍💻 Xinlu Lai

INTP. I don't really pay attention to zodiac signs.

👦🏻 Koji

In one sentence, describe your company and product.

👨🏻‍💻 Xinlu Lai

I'm currently building a KB-level Agent computer toolchain — an open-source toolchain for developers to build Agents.

👦🏻 Koji

And in one sentence, what is the Learn Claude Code tutorial?

👨🏻‍💻 Xinlu Lai

We believe Claude Code is the best Agent Harness. So we thought, if you want to learn Agent Harness, why not create a knowledge repository to analyze Claude Code's Agent design patterns?

👦🏻 Koji

Current team size?

👨🏻‍💻 Xinlu Lai

Very lean. I'm the main person, plus two interns.

👦🏻 Koji

Revenue and profit?

👨🏻‍💻 Xinlu Lai

New venture, just getting started — no revenue yet.

👦🏻 Koji

What were you doing before this?

👨🏻‍💻 Xinlu Lai

Working on AI infrastructure at some major tech companies and research institutes.

Everything Outside the Model Is Harness

Mecha, brain, robot, IQ of 120 — what exactly is Harness?

👦🏻 Koji

If you had to explain Harness in one sentence to someone who's never heard of it, what would you say?

👨🏻‍💻 Xinlu Lai

Everything outside the model is Harness. I tend to think of the model as a brilliant brain — but it has no body or limbs. It can think, but it can't act.

👦🏻 Koji

"The ceiling of an Agent comes from Harness design." Do you agree with that? Why isn't the ceiling determined by improvements in model intelligence?

👨🏻‍💻 Xinlu Lai

I agree with half of it. The upper limit of an Agent's intelligence definitely still comes from model-level development. An Agent is a model; the smarter the model, the better it is.

Most models today are intelligent enough. If we compare a model to a person, their IQ is between 120 and 170. But we can become more powerful through fitness, dance, martial arts — even by putting on a mecha suit.

👦🏻 Koji

That's an interesting metaphor. The mecha suit is Harness?

👨🏻‍💻 Xinlu Lai

It dramatically expands the model's capabilities.

How Did You Get 50k Stars on GitHub?

This Agent tutorial wasn't originally written just for others — it started as Xinlu's own notes on "how to build Agents."

👦🏻 Koji

Your tutorial, Learn Claude Code, has over 50,000 stars on GitHub. When did you start writing it?

👨🏻‍💻 Xinlu Lai

About nine months ago.

👦🏻 Koji

What motivated you at the time?

👨🏻‍💻 Xinlu Lai

Our thinking was: Claude Code is incredibly powerful. Just wrap a web UI around it and you get a strong Agent product. So we started building a toolchain for developers. But back then, developers were more familiar with approaches like LangGraph and LangChain — based on prompts and flows.

It was a bit like a factional dispute. Every time I explained our approach, many people felt it was too uncontrollable — at the time we didn't call it Harness, we called it an Agent framework or runtime.

They preferred adding lots of prompt nodes, controlling the flow themselves — lower cost, more controllable. I saw this as a debate over paradigms, so we created this knowledge repository and put it out there. It also served as our own guiding philosophy for building Agents.

👦🏻 Koji

So do you think frameworks like LangChain and LangGraph are completely obsolete?

👨🏻‍💻 Xinlu Lai

Methodologies like Prompt Flow, which rely on prompt nodes for routing and control, will likely become increasingly unsuitable for future Agent development.

The Agent Native philosophy based on Claude Code — "Agent is model, model is Agent" — including paradigms like "Bash is all you need," will become clearer and more widely adopted.

Bash is all you need

Now that Claude has launched Managed Agents, do people still need to build their own Harness?

👦🏻 Koji

A few days before we recorded this podcast, Claude launched Managed Agents, opening up their Agent Harness solution for everyone to use. So if you can just use Claude's service directly, is there still any point in building your own Harness, or even understanding the details?

👨🏻‍💻 Xinlu Lai

As an Agent development engineer, this is necessary. I believe if you don't understand it, the product you build will lack soul and room for iteration.

👦🏻 Koji

But this is like cloud servers — when they first came out, engineers said you needed to understand the underlying infrastructure too, but later it turned out 99% of projects didn't need that at all. Won't Agent Harness end up the same way?

👨🏻‍💻 Xinlu Lai

In the long run, there will definitely come a day like that. Just like today, when people develop full-stack applications with Node.js, most don't care about its underlying principles — they just want it to work out of the box. As Agent Harness iterates and converges, in two or three years it will likely reach that point too.

But in the meantime, we're in a technology cycle. Building startups and products is fundamentally about capturing the dividends of technological cycle shifts. You still need to embrace those shifts and understand what's actually changing under the hood.

👦🏻 Koji

Who's learning Agent Harness right now?

👨🏻‍💻 Xinlu Lai

It's mostly people who are building and developing Agent products themselves, whether that's teams inside major tech companies or startups on the outside.

👦🏻 Koji

Do you think product managers need to understand Agent Harness?

👨🏻‍💻 Xinlu Lai

I have a challenge for product managers today: the product manager of today is not the same species as in the past. We're in a period of technological change, and every product we build is about capturing the dividends of that change. If you don't understand the core of this technological shift, it's very hard to build a product that can capture those dividends.

In the past, product managers just needed to draw good UX and UI. But today it's fundamentally about how to apply the dividends of technological progress to a specific scenario. So you should understand both sides: one is the scenario's needs and pain points, and the other is what's actually changing technologically.

Three-Layer Harness Breakdown

Using two weeks and multi-Agent collaboration to write a C compiler from scratch — behind this classic case, what three layers did it go through?

👦🏻 Koji

When you talk about Agent Harness, how do you usually break it down?

👨🏻‍💻 Xinlu Lai

I tend to break it into three parts.

The first layer is the one that gives the model execution capability. Things like CLI, code writing, tool registration — including tools extended from MCP — these all uniformly provide action capability to the model.

The second layer I call context, or the state layer. For example, model work requires system prompt, skills, and memory. The model's context window is limited, and many tasks will exceed that window, so you need offload. In the next round, it looks like the same Agent is working, but it's actually a new model window that needs to load initialized context and pick up where the previous window left off. There are many context and state issues here, which I group into the context environment layer.

The third layer is the upper-level management of Agents. This splits into two aspects: one is how to organize and coordinate multiple Agents. If you're dealing with 100 Agents, it's like managing 100 employees — you need organizational structure and collaboration methods to solve complex problems. The other is governance of these 100 Agents, such as different roles' access permissions, information provisioning and isolation.

👦🏻 Koji

Let's walk through these three layers with an example. For a concrete Agent task, how do the three layers of Harness actually function behind the scenes?

👨🏻‍💻 Xinlu Lai

There was a well-known example before: coordinating a large number of Agents to build a C compiler from 0 to 1 in two weeks. This is a great case.

First, at the very bottom of the Agent is the model, like the brain and heart, driving the entire task. It needs action capability, so you at least need to give it tools for file CRUD operations, search, and so on. This is the first layer of Harness — only then can the model write code, create and modify files.

The second layer is context and state. The model needs to know what environment it's working in, what the paths are, what dependencies are installed, what the existing folder structure looks like, Git info, and so on. A C compiler is a huge engineering project — it can't be completed within one context window.

It needs a context offload strategy. After the window fills up, when the next Agent takes over, it needs to read the current environment info, code progress, then continue working, and at the end of its own lifecycle, write documentation and hand off the current state to the next Agent. This process requires context environment support.

The third layer is orchestration and governance. How do you guide the handoffs and delegation between these Agents? What's the relationship between the Agent writing code and the Agent doing testing? Are the task steps necessarily serial? Can't many modules be written in parallel, with multiple Agents working simultaneously? How do they coordinate? This involves orchestration.

Additionally, different Agents need permission governance. An Agent doing testing should only have access to testing environments and tools — it shouldn't be able to casually modify code during testing to "hack" the test results. There are many permission governance and upper-level coordination issues here.

👦🏻 Koji

So in the past, building Agents meant hand-rolling all three layers. Now which ones are well-encapsulated, and which still need hand-rolling?

👨🏻‍💻 Xinlu Lai

Of these three layers so far, I haven't felt that any are particularly well-encapsulated.

The paradigm is changing too fast. From ChatGPT's release at the end of 2022 to now, with these agentic models capable of completing long-horizon tasks appearing — that's really only been the last six months.

I've observed a lot in the open-source community and haven't seen anything that satisfies me, which is why we built it ourselves.

KB's K-Series Agent Toolchain

Their company is called Komputer Blue, codename KB, with the goal of building a complete open-source Infra that's By Agents & For Agents

👦🏻 Koji

Tell us about the project you're working on?

👨🏻‍💻 Xinlu Lai

We've built a complete toolchain around the three layers of Agent.

At the bottom is a toolchain called Komputer — Computer with the C replaced by K.

It's a Unix computer implemented at the data structure level, which you can understand as a virtual computer in memory. It provides an execution environment for next-generation proactive Agents like Xiaolongxia and Claude Code, letting them live and work inside it. We believe a Unix computer is the best environment for them.

At the upper layer there's something called Kruntime, an Agent runtime that provides a large number of interfaces and syntactic sugar encapsulations for developing Agent objects. Additionally, we have other orthogonal layers, like Kwatch, for observability.

You can see where Agents got stuck over the past half month, and from that determine whether it's a CLI design problem, whether skills weren't provided adequately, or whether the model itself is the issue. Based on the observability layer, we can also export data.

We have a toolchain called KRL. You can take the exported data and do reinforcement learning to train your own model. If you don't want to train models and just want to call standard APIs, we can also help you with memory, skills, and extraction and self-iteration of past experience at the context level — think of it as "reinforcement learning for the poor."

vs. AWS AgentCore, Alibaba Cloud AgentBay

Cloud service providers of course want to build this layer too

👦🏻 Koji

Cloud service providers are also building this layer, like AWS's Agent Core and Alibaba Cloud's AgentBase. As a startup, how are you different from them?

👨🏻‍💻 Xinlu Lai

First, our Agent development toolchain isn't designed just for cloud environments — we want it to run in any scenario that can run JS. Like web pages in browsers, WeChat mini programs.

Many scenarios can't fit a Linux — a WeChat mini program package might only be a few megabytes. We want to provide a toolchain framework, uniformly and without distinction, in all JS-capable scenarios — something like Vue or React from the last era, where you just import and use.

It has a unified, simple, elegant mental model, with极致 performance overhead — just a KB-sized Unix Komputer providing a living environment for the Agent. But an Agent like Xiaolongxia in this environment will think it's actually living on a Unix computer, with command line, file system, and network capabilities consistent with what it was trained on.

👦🏻 Koji

So your company is called 1KB?

👨🏻‍💻 Xinlu Lai

Right, though without that "1" in front — it's the expanded form of KB.

👦🏻 Koji

How did you pull this off?

👨🏻‍💻 Xinlu Lai

We reimplemented a purely virtual Unix using data structures as a living and working environment for the Agent. You can understand it as: we rewrote virtual bash, virtual disk file system, foreground and background process execution capabilities, virtual clock, local area network networking, shared resources like NAS mounting capabilities — we rewrote all of these at the virtual abstraction layer in the language.

And in scenarios that support WebAssembly, we'll replace some toolchain parts with Rust; if not supported, we fall back to the most basic JS.

👦🏻 Koji

Returning to Agent Harness, for the first layer of execution capability, what are the main tools right now?

👨🏻‍💻 Xinlu Lai

The main ones are first and foremost file system tools: CRUD operations, search. Most Agents, whether doing Coding or Deep Research, need these.

The second layer is Browser, giving it access to the user's internet world system.

The third layer is language interpreters, like Python, Node.

With these configured, you can basically satisfy 95% or more of tasks.

👦🏻 Koji

Are there any easy pitfalls when configuring the tools layer?

👨🏻‍💻 Xinlu Lai

This is closely tied to permissions and the Agent's role. For example, if an Agent is only responsible for exploring a codebase, I only give it side-effect-free tools — no write or modify commands. Some Agents shouldn't be allowed to operate a Browser, or need to be restricted to certain domains.

There are many trade-offs here. Toolchain design must be tightly bound to the Agent's role, limiting its ability to manipulate the underlying computer.

Schools of Memory

👦🏻 Koji

The second layer is context and state, where memory is crucial. What are the mainstream memory solutions right now?

👨🏻‍💻 Xinlu Lai

Memory is still in a very early stage. I roughly divide it into rule-based, semi-rule-based, and fully model-driven. Currently, the first two are more commonly used.

Fully rule-based approaches use knowledge graphs and vector search, abstracting information into nodes for association and retrieval. Personally, I'm not a fan of this approach.

I prefer semi-rule-based approaches. For example, using an underlying Unix file system with extensive Markdown storage — this is what Claude Code and Xiaolongxia (Crawfish) do. You can also organize information through spatial relationships, like maze layouts, which both humans and LLMs can easily understand.

Updates are also semi-rule-based: Agents run workflows rather than being fully rule-driven. For instance, Claude Code has a "dreaming" mechanism that runs periodically on recent conversations to extract information, update, and correct memories.

The open-source project memU also does this well, embracing the "Unix file system + Agent-driven" approach.

👦🏻 Koji

Y Combinator CEO Gary Tan also open-sourced his personal memory system.

👨🏻‍💻 Xinlu Lai

I think people are somewhat blurring the boundary between Memory and Skill. Claude Code was the earliest to do this. At the end of last year, it had a feature called Insights that could analyze your conversations over the past month, summarize mistakes, and then guide skill generation. The recently popular Harness Agent is more like iteration at the experience-based Memory level (because it's hard to share directly with others).

It's difficult to distinguish whether something is experience-based Memory or a standardized Skill SOP.

But broadly speaking, they all belong to the context layer.

👦🏻 Koji

This reminds me of a recent blog post from Generalist AI: don't define us with labels, define us with purpose. Labels don't just limit how the outside world imagines us — they can limit how our own team imagines ourselves. Maybe whether a practice counts as memory or skill isn't that important; what matters is how Agents self-learn and evolve.

👨🏻‍💻 Xinlu Lai

Right, labels aren't that important.

Consensus and Non-Consensus

👦🏻 Koji

Talking about Harness today, what's consensus and what's non-consensus?

👨🏻‍💻 Xinlu Lai

"Bash is all you need" is somewhat consensus — everyone is building CLI. Or rather, "CLI is all you need." Many people are developing their own CLI rather than MCP, because CLI works for all Agents and is more convenient.

But many open-source Agent frameworks, like LangGraph, aren't built around this philosophy. They still use Prompt Nodes to build state graphs and routing. Our k-series toolchain aims to provide the development tools needed for this new era under the consensus paradigm.

👦🏻 Koji

Are you facing the future?

👨🏻‍💻 Xinlu Lai

We're facing the ultimate.

Claude Code Source Code Leak: The Biggest Surprise

It showed everyone something: how much engineering work this company has done on "context management" that others haven't

👦🏻 Koji

The Claude Code source code leak — from a Harness perspective, what do you think is the most critical thing to learn?

👨🏻‍💻 Xinlu Lai

Its compression strategy is more multi-level than we thought. For example, when to delete tool output, what information to preserve and restore during compression. Agents pass the baton in a relay race — when the next Agent takes over, how to prepare the context, what to load, what to skip, what to check on demand. There are many trade-offs here.

It has done extensive work on context and memory, including Autodream. Many memory features aren't yet available to regular users. Claude Code's memory design is extremely sophisticated, following the same philosophy as its skills mechanism.

There are two most critical points.

First, the model is the Agent. The chain-style approach where users write prompts and assemble prompt flows doesn't make sense. Claude Code fully embodies this.

Second, Claude Code's essence is about equipping the model with appropriate tools for it to call. That is, giving the model action capabilities and full freedom to do as it pleases, rather than programmers planning every step for it.

👦🏻 Koji

More Context, less Control?

👨🏻‍💻 Xinlu Lai

More Context, more action capability, and Zero Control. At most, just restricting it from calling certain tools.

👦🏻 Koji

When Manus launched, it used a cloud sandbox called E2B. From a year ago until now, how has this sandbox evolved?

👨🏻‍💻 Xinlu Lai

We pay close attention to sandboxes. Many have emerged recently, but we feel there haven't been major advances in this area yet. Our own KB-level Unix Komputer might count as a significant development in this space.

👦🏻 Koji

What you built is somewhat similar to Daytona? But Daytona probably isn't as lightweight as yours.

👨🏻‍💻 Xinlu Lai

Ours is more extreme and lightweight. Essentially, it's no longer a sandbox — it's a data structure implemented at the language layer, about the size of a map.

Of course, we've made some trade-offs. You can't actually run a GCC compiler or browser on it. But we provide a minimal Unix file system and bash commands, plus local network communication capabilities.

And we believe that heavy things like browsers and compilers shouldn't be stuffed into every Agent's environment in the first place. They should be extracted as consolidated services.

👦🏻 Koji

Claude Code's "secret dreaming" memory mechanism — specifically, how does it help with memory?

👨🏻‍💻 Xinlu Lai

It has two memory update mechanisms.

First, after each interaction, it triggers a turn stop hook that forks an Agent with all the context (reusing KV Cache), judges what information needs to be saved, and updates it to corresponding Markdown files. These files have structured descriptions — the full text isn't loaded upfront.

Second, the auto-dream mechanism. Roughly every day, if there are more than 5 sessions, it initiates a deeper memory consolidation. It reviews recent sessions, extracts all information, corrects errors, and merges and organizes Memory.

Like a background Agent that periodically wakes up to replay recent conversations — just like how we dream.

👦🏻 Koji

We're talking about Harness, but it's actually quite similar to the Agent optimization engineering practices discussed over the past year?

👨🏻‍💻 Xinlu Lai

Right, Harness is the engineering practice layer above this generation of Agent models.

Just as CPUs led to assembly, and assembly led to higher-level languages like C, Python, and JS.

Now we have a new foundation — the model. We need to leverage its intelligence at the upper layers to create new engineering best practices.

If you approach this from the perspective of model training and inference, you'll find that many so-called best practices today are very natural, conforming to common sense and intuition.

Standards for Good Harness

👦🏻 Koji

How do you judge whether a Harness is well-built?

👨🏻‍💻 Xinlu Lai

Poor context management arbitrarily trims content, causing Prompt Caching to fail.

The best management is no management, because any management you do can invalidate the KV cache and require recalculation. Bad approaches are those that aren't self-consistent with how the model runs.

Good Harness design should be self-consistent with model execution and orthogonal to future capability improvements. Some Harness mechanisms are designed for weaker models (like Q&A-era models). As models improve, these mechanisms become constraints that must be dismantled.

Good Harness should align with the model's own operational logic, and as models get stronger, the entire Agent system becomes stronger too.

👦🏻 Koji

Different Agents completing the same task can perform better or worse. Even with identical performance, good Agents may consume different amounts of Tokens and take different amounts of time. Is this also a criterion for judging Harness quality?

👨🏻‍💻 Xinlu Lai

I think we're still in the early days of Agent model development. Anthropic only started training agent models early last year, and other vendors are actually half a year behind.

So we're still in the infancy of Agent models. Many things haven't converged yet, so it may be premature to discuss so-called Token efficiency.

Of course it's important, but for us as users, just tune the SOTA model and build Harness and products around it.

👦🏻 Koji

So SOTA is Anthropic, and which ones are SOTA in your view?

👨🏻‍💻 Xinlu Lai

SOTA is Anthropic. The next tier would be Moonshot AI, and the latest models from Minimax and Zhipu AI — they're all basically hugging SOTA.

👦🏻 Koji

If Agent models keep getting stronger, will differences in Harness quality still matter?

👨🏻‍💻 Xinlu Lai

In two or three years, theoretically there shouldn't be that many Harnesses.

A good Harness needs to be self-consistent with how the model operates, and orthogonal to the direction of model progress.

From those two angles, there won't be that many factions in structural design. We're building a Unix system — you can think of Linux as the strongest possible Harness for models.

If models ever evolve into ASI, they'll only get better at using Linux.

👦🏻 Koji

If you were building a good Agent today — composed of model, context, Harness, tools, and other parts — how would you rank them by importance?

👨🏻‍💻 Xinlu Lai

First is definitely the model, because the Agent is the model. The model is the Agent. If your Agent performs poorly, swapping in a stronger model will probably improve it a lot.

Second is context — a very open concept, covering what environment it works in, what tools it has access to, skills, memory, and handoffs between Agents. For us developers, there's more room to maneuver at the context layer.

Third is tools. Give it powerful tools and it can accomplish more.

On tools — I used GitHub's MCP before, then found GitHub CLI had higher call success rates, so I uninstalled the MCP.

I thought about why. Linux commands appear billions of times in pre-training, so they're extremely robust. MCP is a protocol proposed only in the last two years, probably less than 0.1% of pre-training corpus. Recently Lark launched a CLI too — its composability and task completion rate are higher than the previous plugin approach.

Everyone's moving away from MCP and back to the self-consistent philosophy of Unix, where training data is most abundant.

So I really love the phrase "Bash is all you need."

Three Startup Directions Xinlu Is Bullish On

👦🏻 Koji

Agent Harness has spawned lots of startup directions. Beyond what you're doing, what else do you like?

👨🏻‍💻 Xinlu Lai

I watch three major directions. We're doing Harness-layer infra and developer toolchains ourselves.

The other two: One is Agent networking. I'm concerned with underlying hardware resources — cloud servers, edge computers, routers, NAS, phones, etc. They don't necessarily have public IPs, so there's a hybrid networking problem.

I really like Tailscale — its networking approach is beautifully simple. But in the Agent era, we may need an entirely new, more Agent-native form of hybrid networking.

👦🏻 Koji

This is actually similar to Agent payments. Human payments don't need such high concurrency or such granular micropayments, but payments between Agents might be a few cents each, happening at extremely high frequency.

👨🏻‍💻 Xinlu Lai

There's another direction. I think: ten years from now, is everyone still calling the same base model ID? That'd be so boring. So solutions like Tinker could be crucial. It pools massive compute cards into high-speed interconnected clusters, enabling cheaper PEFT training.

This way, everyone can have their own personalized fine-tuned model. At inference time, you could also attach your own LoRA info to API requests, achieving low-cost personalized inference. I'll be watching this direction very closely.

👦🏻 Koji

Will many companies survive this wave of Agent Infra?

👨🏻‍💻 Xinlu Lai

It'll be a pretty intense race. We believe future Agent Harnesses don't need so-called horizontal differentiation, because they need to be self-consistent with how models run and where they're headed.

From these two angles, there won't be many factions in structural design. We're firmly in the Unix and Shell camp, providing a virtual Unix Komputer, pushing performance to the extreme.

There might be other factions — say, going the TypeScript route with strict structured control — but not many.

👦🏻 Koji

You sense this track is intense and might disappear in two years. Why still do it?

👨🏻‍💻 Xinlu Lai

We didn't just enter this track recently — we've been at it for a year. Now we're just evolving, building generation two, making things more self-consistent, thinking more from the end state.

Our company slogan is "Accelerate the world's upgrade." At this stage, is this the most effective acceleration we can give the world? Maybe the next stage is building better rockets, or better fusion.

But at this technological moment, what we see is how to fill the planet with Agents, make them social infrastructure, especially make Coding Agent a kind of Infra.

In the future there might be hundreds of times more Agents than humans on the planet. How do you serve them, support them in developing, creating, and forking Agents? That's a crazy world. We're thinking about and supporting exactly that.

Hot Takes on the Future of Agents

"I think a lot of companies in the future will be financial products — built by experienced human teams, or even directly generated by AI, then self-operating"

👦🏻 Koji

Any other predictions or hot takes on the future of Agents?

👨🏻‍💻 Xinlu Lai

I think the future shape of Agents is already very clear. The field is still early — this model phase might last about 3 years.

Right now it's mostly single Agents; next is swarm-style cluster operations. Right now humans manually orchestrate Agents; in the future Agents should manage and coordinate more Agents themselves.

Further out, AI does invention tasks. If AI can iteratively propose new solutions, run experiments, fully drive company operations — then future companies are more like financial products than human organizations.

The inside of the company is a black box; customers don't care. Agents could absolutely form "zero-person companies." I never thought one-person companies were the essence — what really makes sense is zero-person companies.

👦🏻 Koji

ZhenFund and we recently granted a project called YoYo Agent, which could count as a zero-person company.

Its creator built it and completely let go — no code changes, no funding. It has to evolve on its own, figure out how to earn money to buy tokens, with the goal of one day surpassing Claude Code.

Right now it earns money through GitHub donations. In the future, what people invest in might no longer be human companies, but individual Agents.

👨🏻‍💻 Xinlu Lai

I completely believe it. In the future you might be a big boss, meeting a friend, pulling a black card from your pocket and saying: "This card is running 5 companies, generating billions in annual revenue for me. This is my company, right here in this card."

👦🏻 Koji

That future — exciting and terrifying to think about.

👨🏻‍💻 Xinlu Lai

Hahaha, just kidding.

👦🏻 Koji

Alright, thanks Xinlu for today.

👨🏻‍💻 Xinlu Lai

Sure, thanks.

🚥

Crossing is looking for independent writers to produce AI product and model reviews. If you've written articles like "Hands-on with PixVerse C1" or "Hands-on with LibTV", please contact zeo0811@gmail.com. Your email should include: ① personal introduction, ② AI review articles you've written. We offer competitive compensation. Looking forward to observing and documenting the AI era together 🎪