Over the past two years, the AI industry has been dominated by one question: whose model is stronger?
That question still matters. Model capability is the starting point of this AI cycle. But as models become the underlying capability behind more products and workflows, the center of competition is shifting. More companies are discovering that the hard part is not simply making a model answer better. The hard part is making it act reliably, safely, and continuously in real environments.
That is why we have become increasingly focused on Agent Harness.
If the model is the brain of an agent, the harness is the system that allows that brain to enter the world and start working. It includes context, tools, runtime, permissions, risk controls, evaluation, tracing, and feedback. Without these layers, even the strongest model remains inside a chat box. With them, an agent can move from answering questions to executing work.
This essay is not about another agent application. It is about a more fundamental question: as software is rewritten for agents, which infrastructure layers become important, which opportunities are investable, and which narratives may struggle to build durable moats?
We start with the new To-Agent coordinate system, then explain why Harness becomes a critical layer in the agent economy, what investment opportunities and risks we see, and finally use trading agents as a vertical case study to show why execution trajectories and outcome feedback may become some of the most valuable data assets in next-generation AI infrastructure.
-
From To-B / To-C to To-Agent
Many of the frameworks we inherited from the internet era are becoming less sufficient.
In the past, when we evaluated a product, we first asked whether it was To-B or To-C, how much DAU it had, what retention looked like, where traffic came from, and how users converted into paying customers. This worked because the first user of software was always human. A person opened an app, read the interface, clicked buttons, made decisions, and completed actions.
The agent era is changing that assumption.
In more and more scenarios, the entity entering the system, reading information, calling tools, and initiating actions is no longer directly a human. It is an agent acting on behalf of a person or an organization. The agent does not care whether the page is beautiful. It does not need a traditional user manual. It cares whether the API is clear, whether the schema is structured, whether permission boundaries are explicit, whether tool descriptions are readable, and whether execution results can be verified.
This is not a minor change in interaction design. It is a replacement of interface assumptions.
Software used to be written for humans, so we optimized pages, buttons, copy, and flows. Increasingly, software needs to be written for agents, which means it must become callable, composable, verifiable, and traceable.
That is why a new dimension is becoming important beyond To-B and To-C: To-Agent.
To-Agent does not mean humans no longer matter. It means that in many products, the direct user, caller, or executor will be an agent. The final buyer may still be an enterprise or an individual, but whether the product can be discovered, called, and repeatedly used by agents will become a new distribution layer.
This matters for investment analysis. A product may not have high DAU in the traditional sense, but if it becomes the default invocation layer for many agents, it can still be extremely valuable. Conversely, a product that looks complete for human users may be bypassed if it cannot be read, called, and composed by agents.
This is why we think the first new map of the agent era is not To-B / To-C, but To-Human / To-Agent. The former serves humans and improves human productivity. The latter serves agents and helps them discover, understand, call, execute, pay, verify, and review.
-
The Giants Are Not Fighting Over Model Features. They Are Fighting Over Agent Entry Points.
Over the past year, the moves of major companies have looked different on the surface. Some are building protocols, some are building skills, some are building agent builders, some are building payment rails, and some are building wallet tooling. Viewed separately, they look like scattered feature launches. Viewed together, they are competing for the same position: the entry point through which agents access real systems.
Anthropic is the clearest example.
MCP addresses how agents connect to external systems. When Anthropic introduced MCP, it described it as an open standard for building secure, two-way connections between AI-powered tools and external data sources. In other words, MCP is not mainly about improving chat UX. It is about how agents enter data sources, development environments, and business systems.
Agent Skills addresses another problem: how agents acquire professional workflows. Anthropic compares building a skill to creating an onboarding guide for a new hire. A skill can include instructions, scripts, reference materials, and procedures, making the agent more reliable and reusable in a specific task domain.
Claude Code fits the same pattern. It is not just a coding assistant. It is a long-task execution system. It can read code, edit files, call tools, run tests, handle errors, and continue looping when the task is not complete. Coding is one of the first workflows where agents have been meaningfully validated because it naturally has a structured environment, explicit feedback, executable tools, and relatively clear verification.
Anthropic’s rise is not simply about adding more features. It is about treating agents as long-task execution systems earlier than many others. Its advantage is not only in the model, but also in the system around the model that makes execution happen.
OpenAI’s AgentKit is moving in the same direction. It brings together tools needed to build, deploy, and optimize agents, lowering the difficulty of taking agents from prototype to production. The keywords here are not chat, but builder, connectors, eval, deployment, and optimization. OpenAI also describes AgentKit as a toolset for developers and enterprises to build, deploy, and optimize agents.
Coinbase and Cloudflare’s x402 effort shows that the agent economy also needs payment and settlement rails. Coinbase describes x402 as embedding payments directly into web interactions through HTTP “402 Payment Required,” enabling AI agents, APIs, and apps to transact value as seamlessly as they exchange data. Cloudflare frames x402 as a common language for clients and services to exchange value on the web. Coinbase AgentKit further turns wallets and onchain interactions into components that AI agents can call, emphasizing a framework-agnostic and wallet-agnostic crypto-native agent toolkit.
Bitget represents another version of this entry-point competition in the vertical context of trading agents. Unlike x402, which focuses more on payment protocols, or AgentKit, which focuses more on wallets and onchain interactions, Bitget Agent Hub is more directly oriented toward trading execution. Bitget combines MCP, API, Skills, and CLI into an invocation system that connects AI models, development tools, and live trading execution chains. Its official Agent Hub page positions it as AI-era crypto trading infrastructure for developers and Vibe Coders to access trading capabilities.
The significance is not simply that an exchange has launched more AI tools. More precisely, Bitget is trying to answer a narrower and more demanding question: if trading agents are to operate in CEX environments, what kind of harness do they need? They need tools, interfaces, strategy skills, command-line invocation, permission isolation, and eventually execution trajectories, outcome evaluation, and risk feedback. Bitget has taken an early step, but there is still no industry standard. The platform that can better connect discovery, integration, authorization, execution, verification, and review is more likely to own the entry point in the high-value domain of trading agents.
Taken together, these moves suggest that AI infrastructure is expanding from the Model Stack to the Agent Stack. Future competition will not only be about model capability, but also about how agents connect to systems, gain permissions, call tools, make payments, execute, verify, and learn.
This brings us to the central question: when agents are no longer just chat windows but begin executing tasks inside real systems, what is missing in between?
-
Between Answering and Executing, Agents Need Harness
A simple formula helps explain the agent era:
Agent = Model + Harness.
The model provides intelligence. The harness provides the execution system.
It made sense that the market first focused on models. Without sufficiently capable models, today’s agents would not exist. But as model capability continues to improve, many bottlenecks are moving elsewhere. Enterprises care about whether an agent can connect to their systems, whether it can obtain the right permissions, whether failures are accountable, whether the execution process is visible, who judges whether the result is good, and whether the agent can learn from failure.
All of these questions belong to the Harness layer.
A complete harness is not just a tool-calling framework. An agent needs context to understand the task, business background, historical state, and organizational rules. It needs tools and skills to call external systems and reuse workflows that have been refined in a specific domain. It needs runtime and orchestration to handle long tasks, multi-step execution, failure recovery, and parallel collaboration. It needs identity and permission to make clear who it represents, what it can do, and what it cannot do. It also needs guardrails, evaluation, trace, and feedback to record the execution process, judge outcomes, and improve the next execution.
This is why we tend to view Harness as an OS layer rather than a normal SaaS feature.
Many single-point agent products already exist: memory tools, tool-calling platforms, orchestration frameworks, observability products, and eval platforms. They all have value and many may become good early-stage companies. But over the long term, the risk and value of agents both come from the loop. A single layer, if not connected to other layers, can easily become a transitional tool.
Tools without permissions and risk controls make automation more dangerous. Tracing without identity and authorization produces low-quality logs. Orchestration without evaluation may allow agents to confidently keep making mistakes. Memory without feedback pollutes context. Evaluation that cannot influence runtime decisions remains post-mortem scoring.
The value of an operating system never comes from a single module. It comes from stable coordination among modules. Agent Harness is similar.
-
How We See the Investment Opportunities
Under this framework, Agent Harness is not a single market. It is a set of infrastructure opportunities.
The first opportunity is in discovery and protocol layers. Agents need to find external systems, understand what they can do, and call them in standardized ways. MCP servers, tool registries, skill marketplaces, structured documentation, and machine-readable APIs will become new distribution surfaces. The opportunity is large, but it can also be overestimated. A directory or protocol alone may not capture durable value. The more interesting value lies in usage, workflows, and data built on top of the protocol.
The second opportunity is in context and skill layers. General-purpose models know a lot, but real work depends on organizational and industry context. Legal, finance, healthcare, security, chip design, audit, and supply chain all have their own procedures, terminology, templates, compliance requirements, and exceptions. Teams that can structure this experience into context and skills that agents can use may build durable vertical moats.
The third opportunity is in runtime and orchestration. Long-running agents need state management, failure recovery, cost control, sandboxing, and multi-agent coordination. The demand is real, but competition will be intense. Model companies, cloud vendors, and open-source frameworks will all enter. We are more interested in teams that own a specific high-value use case than those building generic workflow builders.
The fourth opportunity is in evaluation, observability, and trace. We believe this layer is underappreciated. Many agent projects fail not because the model is incapable, but because enterprises do not know why the agent acted, how far it got, where it failed, where the cost went, or whether the outcome is trustworthy. Trace and eval may look like developer tools in the short term, but in the long term they may become the data infrastructure of the agent era. Trace alone is logging. Trace plus eval can become a training and judgment system.
The fifth, and the one we are most interested in, is vertical harness. This is not simply a vertical agent app. It is the integration of context, tools, workflow, permission, guardrails, evaluation, trace, and feedback loops inside a high-value domain. Legal, healthcare, finance, trading, security, and chip design are strong candidates because tasks are valuable, mistakes are costly, workflows are deep, outcomes are measurable, and feedback loops matter.
We are also cautious about several areas.
Generic agent frameworks look like large opportunities, but they face pressure from both sides. Model companies can move downward with managed agents, while vertical workflow companies can move upward by owning deeper context and execution data. Without strong ecosystem, distribution, or real execution data, the middle layer may be hard to defend.
Thin model wrappers also need caution. Applications without workflow ownership, proprietary context, execution data, or distribution barriers will be increasingly vulnerable to model upgrades and platform-native features.
Protocol narratives should not be evaluated only by hype. MCP, x402, and A2A all deserve attention, but protocols are not business models by themselves. What matters is real developer adoption, invocation volume, integration into mainstream agent builders, and participation in actual execution chains.
Finally, data flywheels need scrutiny. Many companies will claim to have a data flywheel. A real one requires data rights, structured schemas, and evaluation labels. Data collection without user consent and compliance boundaries may become a liability rather than a moat.
-
Trading Agents as a Stress Test for Harness
Trading agents are one of the best vertical cases for understanding Agent Harness.
The reason is simple: trading amplifies nearly every harness problem.
Trading involves real capital. Mistakes are expensive. Execution requires authorization. Risk controls must work in real time. Processes need to be auditable. Outcomes are measurable. Markets run 24/7. The value of a trading agent cannot be judged only by whether it can place an order. More important questions are whether it knows whom it represents, which account it can access, how much risk it can take, what assets it is allowed to trade, when it must stop, and whether its execution quality can be assessed.
A mature Trading Agent Harness should therefore contain an end-to-end chain.
The agent first needs to discover the trading system and understand its interfaces and tools. It then needs identity and permissions, knowing whom it represents and what it can do. Only then come market data, account information, order placement, cancellation, positions, stop-losses, hedging, and other tool calls. More importantly, the trading task should be separated into research, planning, execution, and verification, instead of allowing one agent to hold excessive permissions and evaluate itself.
Risk control is central. Budget limits, maximum leverage, maximum drawdown, asset restrictions, frequency limits, and anomaly circuit breakers must be built into the system, not added as after-the-fact warnings. Evaluation also cannot rely only on PnL. Short-term profit may come from excessive risk, while short-term loss may reflect correct risk control. Better evaluation should consider slippage, risk-adjusted return, adherence to user goals, and abnormal behavior under extreme market conditions.
The most important layer is trace.
Every agent trade generates a trajectory: market state, decision process, tool calls, risk checks, execution action, fill result, and subsequent attribution. Ordinary trading logs record what happened. Trading agent traces also record why it happened and how the result should be interpreted.
This is what we mean when we say: Harness itself becomes Dataset.
If a Transaction Foundation Model emerges in the future, it will not only need market and trade data. It will need trading trajectories that include strategy intent, risk boundaries, execution paths, and outcome labels. Such data must come from real execution and must be designed with reusable schemas from day one. Otherwise, three years later, the industry may find that it has accumulated many logs but little trainable data.
This is why competition in trading agents may eventually move from API competition to execution data competition.
-
Exchanges and Bitget’s Early Exploration
In the trading agent context, exchanges occupy a unique position.
Model companies can provide reasoning. Middleware companies can provide workflow. Wallets can provide signatures and onchain permissions. Cloud platforms can provide runtime. Centralized exchanges, however, control another set of assets: custody accounts, order and trade data, market depth, risk systems, clearing systems, permission structures, and 24/7 operational infrastructure.
These assets give exchanges a structural opportunity to build Trading Agent Harnesses. They are closest to real execution and real outcomes, and therefore best positioned to accumulate high-quality execution data.
This does not mean exchanges will win automatically. Exchanges are often not strong in developer ecosystems. Their documentation and APIs may not be agent-friendly. Compliance requirements make product iteration more cautious. User trust in automated trading must be built gradually. Most importantly, trading data usage requires strict authorization, anonymization, privacy, and compliance design.
If exchanges want to enter the agent era, exposing APIs will not be enough. They need to upgrade from execution backends to trusted harness layers.
Bitget is an early example in this direction. Public materials show that Bitget Agent Hub is built around MCP, API, Skills, and CLI modules, aiming to connect AI models, developer tools, and real trading execution, so that developers and AI agents can access market data, run strategies, and execute trades. Bitget has also disclosed that Agent Hub covers multiple modules and dozens of tools across areas such as spot, futures, copy trading, and wealth-related products. (Bitget)
This suggests that Bitget has taken the first step: making exchange capabilities more visible and callable by agents.
But from an industry perspective, this remains early. Tool exposure is only the starting point. The real divide will come later. Whether an exchange can become a Trading Agent Harness depends on whether agents can discover it by default, whether key and signing boundaries are clear, whether permissions are granular enough, whether trading behavior is traceable, whether outcomes are verifiable, whether failures can be written back into guardrails, and whether execution traces can become data assets.
If Bitget or other exchanges continue to evolve toward trace, evaluation, guardrails, KYA, and feedback loops, exchange competition may expand beyond liquidity, product depth, and user scale into agent-native trust and execution data.
That will be more important than which platform exposes more APIs.
Conclusion: The Next AI Infrastructure Is Not Just Better Models
The real change in the agent era is not that AI can speak better. It is that AI begins to act.
Once AI begins to act, infrastructure must be rewritten. It needs to discover tools, obtain permissions, call systems, make payments, execute actions, be audited, be evaluated, and improve from failure.
Together, these capabilities form Agent Harness.
From an investment perspective, we are most interested in companies that can enter high-value workflows and continuously accumulate context, workflow, trace, evaluation, and outcome data. They may not look like the hottest products at first. They may not have the most polished front-end. But if they stand in the right position, they may become true infrastructure in the agent era.
Trading agents are only one example. Similar logic will apply to legal, healthcare, security, chip design, enterprise compliance, and financial workflows.
The future of AI competition may unfold in three stages.
First, competition over whose model is stronger.
Second, competition over who can make agents complete real work more reliably.
Third, competition over who can turn every execution into data that improves the next execution.
The long-term value of Agent Harness lies in the third stage.