Stop overestimating agents’ autonomy

If an agent only answers a question and gets it wrong, the user might just ask again; but if the agent starts placing orders, participating in scheduling, modifying production systems, or invoking real business capabilities, a single mistake can lead to more than a user‑experience issue—it becomes an actual business risk. So where exactly is the boundary for enterprise agents?

Recently, InfoQ’s “Geek Rendezvous” X QCon live program specially invitedNoDesk AI CTO Wang Fang as the host, together withFliggy algorithm expert Lv Detao, Huolala technical director Qi Longji, and Jiangsu Mobile AI direction CTO Wang Shangqi to discuss, as the  QConGlobal Software Development Conference 2026 (Shanghai) is about to take place, exploring enterprise-level Agent autonomy and production practices.

Some highlights are as follows:

• Business scenarios require more certainty and reliability, which models inherently lack, so we need a clear boundary to keep the model’s uncertainty within defined business limits.

• Key steps should still be handled with rule-based methods; only the description and generation of rules use AI, solving cost, boundaries, and accuracy, while interpretability, revocability, and controllability are also stronger.

• Anything involving user wallet rights must be handled by humans; tasks with high flexibility, such as generating replies, clarifying vague intents, or handling long-tail expressions, can be delegated to the model.

• The barrier for enterprise agents is not generating a superficially good answer, but whether the enterprise’s own data, tools, algorithms, business rules, and evaluation system can hold up in the real world.

The following content is compiled from live notes and edited by InfoQ.

Wang Fang: As model capabilities grow stronger, why do we increasingly need to discuss the boundaries of agents?

Lu Detao: The stronger the model, the more it can handle long‑range tasks, understand more complex requirements, and encounter more business states. In the past, if it answered a question incorrectly, the user might ask again; but in real business, if the recommended price or inventory is wrong, it directly leads to order creation or payment failure, and once it enters the transaction flow it becomes a serious experience loss. Moreover, the model can easily give an answer that looks plausible but is actually fabricated, such as inventing a hotel room type ID that fits business rules, which end‑users on the C‑side cannot detect at all. So the boundary is not about the model’s strength; rather, once it becomes stronger, how do we ensure that clearly defined matters are 100% correct.

Qi Longji: In the past two years, models have progressed from only answering questions to being able to invoke tools, but fundamentally they are still token‑prediction probability models and inevitably exhibit hallucinations, representing an uncertain capability. When applied to real business—order recommendations, driver contact, matchmaking decisions—these are real transactions, and mistakes have a large impact. Business scenarios require determinism and reliability, which the model naturally lacks, so we need a clear boundary that confines the model’s uncertainty within a defined business scope.

Wang Shangqi: It used to be a dialog box—if the user answered incorrectly, we would ask again. Now it’s a business system, and no one can tolerate failures. For example, in Mobile’s internal OA document approval recommendation, a wrong approval can have serious consequences, so at the application level we need to validate the Agent’s capabilities through Harness. Another point I’ve learned from building platforms: handing the large model entirely over to an Agent wastes compute and tokens, and the gateway may not even be able to handle it. Previously we defended against DDoS; now we also have to guard against accidental attacks and unintended consumption by Agents. Compute and tokens cost money, and if retry counts and boundary mechanisms aren’t controlled, a consumer‑facing product can be attacked by such Agents, while a B‑to‑B product can suffer task congestion. We’ve even seen a single faulty Agent bring down an entire production line. So one side of the boundary is capability, the other side is system stability.

Wang Fang: We have a client that is a top domestic apparel company. Their internal Agents had no restrictions—they could call internal database APIs directly with unlimited concurrency, which crashed the interface and affected the online service for more than half an hour. Therefore, from stability to business logic, we must ensure production determinism: the service must be stable, and business rules must execute within compliance, rather than operating outside the defined boundaries.

Today many agents can already retrieve information, perform analysis, and give advice, but several practitioners are pushing further, starting to invoke systems, change states, and participate in decisions. What threshold must an agent cross to move from a chat assistant to truly executing tasks?

Lu Detao: The hurdle isn’t whether it can call tools, but whether it can be accountable for the final outcome. For example, helping a user book tickets for two adults and one child at Shanghai Disney: a traditional assistant would just give a suggestion, but when it reaches the business system, it must determine whether the ticket type is adult, whether the composition of two adults and one child is correct, whether the crowd size is appropriate, whether there’s inventory, and whether the combined price is the lowest before entering the order flow—any mistake means a poor answer. We impose several layers of constraints: use a model for requirement understanding, put ticket combination and total price calculation into a solver to ensure the result is verifiable and reproducible; business IDs like hotel ID or room type ID are not passed raw to the model but replaced with short IDs and restored when displayed; rights and payments involving the user’s wallet are not directly exposed to the model and require user confirmation. So the real crossing point is validation, permission control, and a traceable closed loop.

Qi Longji: I understand that what truly gets crossed over are many tasks that used to have to be done by humans, and for the first time they can be completed by an AI system. The first step for a user placing an order is selecting a vehicle. We have small trucks and large trucks—what should a user who needs to transport a double-door refrigerator choose? With an Agent, we embed the logistics knowledge that users previously had to possess, allowing it to help users understand intent and select a vehicle. In this way, the business system shifts from pure execution to having intent‑understanding capability.

Wang Shangqi: Two hurdles. First, users’ acceptance of AI is low. Many AI products used to deliver results instantly, whereas large models need to convert text to vectors, call APIs, and then render the response into UI—the process is completely different. We generate visit plans for account managers; previously we relied on template retrieval, now we first guess which company the account manager might visit tomorrow, then combine internal data and Qichacha to pre‑generate the document, aiming to hit the request accurately, and the on‑site generation is much faster. So a large part of the work is designing the application architecture—use AI when appropriate, minimize its use when not, and do caching, pre‑execution, and pre‑matching in advance.

The second issue is permissions. Internal capabilities in enterprises have always relied on human operation, with responsibility resting on people; for consumer‑facing (toC) recommendations, it doesn’t matter if the user is right or wrong, but within a company, approving wrong orders, approving things that shouldn’t be approved, or being unable to hold anyone accountable is a problem. Therefore we invest heavily in intelligent agent permission control, including API permissions and MCP capability permissions—only those with the proper rights can use them, and responsibility can be assigned to individuals. When responsibility sharing and permission verification are needed, we use a human‑in‑the‑loop approach to confirm with a person, designing AI interactions according to corporate policies. This is similar to autonomous driving: L4 has never been released, and L3 is stalled not by technology but by the division of duties and permissions.

Wang Fang:Many agents in the industry are still at the demonstration or small‑scale pilot stage. A major challenge for B2B is accuracy. People rarely discuss an agent’s accuracy, assuming that a smart model solves everything, but that’s not the case. Take import‑export customs clearance, for example: frontline staff take photos of all kinds of products from various angles. First, you need to solve the perception problem by converting multimodal inputs into structured documents, then perform review, lookup, cross‑verification, and generate customs declaration and contract documents. Previously this was done entirely by humans; a single clearance required on‑site investigation and took more than forty‑five minutes. The biggest issue with agents here is that they cannot guarantee accuracy, so they’re not deployed: hand‑taken photos from different angles make it hard to reliably parse product codes, timestamps, and dates; customs clearance is very strict, and a single field error can cause the entire application to be rejected.

Another issue that affects accuracy is the need to work face‑to‑face with business experts, extracting the business goals, boundaries, decomposition logic, and underlying rule dependencies into language that an Agent can understand. We call this business translation. B2B differs from B2C: humans hand over about 80% of the work to the Agent, and it must handle a large batch—dozens of steps—in a stable manner with an accuracy of 90% or even 95%+. In addition to permissions, the process cannot be a black box: users may not need to see it, but if they want to inspect any step, clicking in should reveal the entire Agent workflow, showing which fields were parsed, why they passed or failed, and what underlying logic they depend on. When QClaw first launched, I thought it would be a big step forward for enterprise deployment, but it wasn’t, because it’s a black box, can’t guarantee accuracy, and doesn’t solve permission issues. This problem is especially pronounced in B2B and is a major obstacle to large‑scale Agent deployment.

Lu Detao: We have similar scenarios—B2B customer service refunds and change‑of‑policy rules, where a single mistake results in a financial loss.

Wang Fang: I have seen a pet food company conduct packaging material audits, and due to an oversight in the audit, millions of dollars worth of products could not be sold. I originally thought packaging material audits were simple, but in practice they are not: there are 60 to 70 fields to review, each backed by regulations from different countries, and different foods have different requirements. Recently a client built an audit‑type Agent; a single category requires more than 200 fields to be checked, and merchants must submit sixty or seventy documents, each containing hundreds of fields to extract. Some rules can be judged directly, but many require multiple jumps—ABC is one combination, ABD is another. Business experts need several days to sort everything out before it becomes complete. This is the hurdle an Agent must cross to be applied in complex scenarios, and it demands strong expertise. After a technical team handles such a scenario, they essentially become half‑business experts in that domain, needing to understand both the overall logic and the details to turn it into an Agent capability; without that knowledge or clear boundaries, the result will never go live, will remain a demo, and will fail as soon as an exception occurs, which is completely unacceptable for the business.

Qi Longji: Accuracy is an issue; currently it can’t be solved by large models alone. For example, when selecting a car, how to choose correctly 100% according to business rules: a refrigerator must be upright because of the compressor, but based on length/width/height it could also be placed horizontally; there are many more placement rules for irregular parts. In AI operations, the Agent used by operators needs to generate marketing and price configurations, which often require precise calculations and can only be done engineering‑wise. Outbound calls discussing price or extracting price can also make mistakes, e.g., adding a 10‑unit markup of 100; online that becomes an incident. Therefore, these must be handled using a Harness approach, or be constrained, defining clear boundaries between certain and uncertain areas, only then can they create value online.

Wang Fang: When facing a real business task, what criteria do you use to decide which step to assign to an Agent, which step to handle with code or traditional algorithms, and which step must be handled by a human?

Wang Shangqi: There’s also a practical issue with division of labor: when you do a lot of engineering, leaders ask where the innovation lies. Even with large models, why are workflow engines still rule‑based? The refrigerator example earlier, to me, is also rule‑based. But model capabilities are already heading toward AGI; the latest foreign models that generate code are impressive because code can form a closed loop. In enterprises it’s difficult because of permissions, corporate data, and unknown knowledge models. For example, a refrigerator must be upright, or certain audit conditions are AB, others are CD—these kinds of rules a generic model will never learn, and enterprises are unlikely to fine‑tune. At Jiangsu Mobile we have no fine‑tuning at all, and it’s hard for programmers either, because they don’t understand the business.

So our current approach is: let business users use AI coding to solidify the confirmed, rule‑required business rules into code, while the main process still runs with AI strings. For example, the internal dispatch workflow was originally orchestrated entirely by a rule engine; now we have business experts describe the rules, AI generates a code snippet, and business users don’t need to validate the code itself—when the process runs it simply calls that snippet. If an error occurs, we determine whether the intent was misidentified, in which case we adjust Harness’s prompts or add conditions; or whether the rule description is correct but the generated code is wrong, in which case the business department validates it with test cases and then revises the code. Through iterative cycles, the critical steps remain rule‑based, but the description and generation of those rules are handled by AI, solving cost, scope, and accuracy issues while enhancing explainability, reversibility, and control.

Qi Longji: We were also troubled about which to use Agent and which to use engineering. For example, user assistant, driver assistant—originally clicked in a graphical interface, after switching to a conversational mode we found that for existing customers it was like pouring with the left hand into the right hand, and efficiency actually decreased. So we concluded that Agents should be used to extend system capabilities, not to redo existing capabilities: give the Agent tasks that were previously impossible, that require rethinking and planning based on the current state, as well as extracted business knowledge; while real‑time transactions, rules, traditional algorithms (such as order‑acceptance probability prediction) that are solvable and deterministic should still use the tools they excel at. Agents are more about combining existing capabilities, linking them together, thinking and planning in real time, and continuously working toward business goals.

For example, AI matchmaking addresses long-tail orders: previously, the dispatch would call a driver, and if the driver didn’t accept within ten or twenty minutes, the system would replay the order according to the rules; now we can plan in real time based on the user’s and order’s status, use AI outbound calls to negotiate price with the user or driver, ask why they don’t want to accept, and what price would make them take it, collect enough driver intent, and then close the order. Before agents existed, this could only be done by customer service or dedicated staff. In summary, use engineering or machine learning for well‑defined problems, and use agents for open‑ended, continuously planned decision‑execution‑feedback problems. We have built many agents, spent many tokens, and have been wondering what the extra business value actually is; the token bill shows up every month, and it’s hard to say whether the ROI is positive. So agents should be applied where they truly generate business revenue and provide additional value.

Lu Detao: It’s a bit different from the two of you; we mainly focus on to‑C. Anything involving user wallet rights must stay on our side; for high‑flexibility tasks, such as generating replies, clarifying vague intents, handling long‑tail expressions, we can hand them to the model. Take ticket bundling as an example: at first we also used the best model available at the time to group large and small tickets, thinking it would work, but the accuracy was only around eighty percent, and in the end we ended up having the model generate requirements and solving them with traditional mixed‑integer programming.

Wang Fang: This actually involves two paradigms and two technology stacks, which differ greatly from deep learning and have a narrower range of applicable scenarios. Traditional recommendation systems mainly rely on user behavior and interaction logs, using collaborative filtering, matrix factorization, or deep model optimization to predict targets; enterprise Agents, in addition to learning from data, must explicitly organize business rules, expert knowledge, and tool execution chains. The problems and engineering constraints each faces are not exactly the same.

I have also visited manufacturing sites where they replace consumables, such as precision instruments in fruit processing lines and phone manufacturing. Previously, they would replace them in bulk after reaching ten thousand uses, which was quite wasteful; now, by combining an Agent to assess health, traditional deep learning handles perception, judging health fluctuations from images and numerical data. Previously, humans decided whether to replace, dealing with false alarms or real issues; now an Agent makes the decision, reducing both labor and wear. So there is no single paradigm for deciding which tasks use humans, which use traditional algorithms, and which use Agents—it still needs to be tailored to the specific business.

So for this kind of division‑of‑work design, what kind of person is suitable? Someone who understands the business, someone who understands the technology, or someone who knows a bit of both?

亓隆基: A few days ago a major company published an article, saying that after spending countless tokens they arrived at a key insight: AI engineering is an industry‑product‑research engineering effort and cannot rely solely on product‑research. Our experience is the same; to truly build a good business Agent, business, product, and development must all be involved, because relying only on product‑research leaves you unaware of the business strategy. Take AI matching as an example—how to call users or drivers; only real customer service and frontline staff know those strategies. So industry, product, and research must all be present, and for technology this is even more challenging than traditional engineering projects: the business will think you are delivering the most advanced productivity and expect you to tell them the best way to do it, but in reality it should be business and product‑research working together to extract effective business strategies, then have the Agent follow them to execute and achieve results.

Wang Fang: Narrow the problem further. We often use accuracy and confidence to decide whether something can go live, but in real business there is another, more direct criterion: whether a mistake can be undone. Is reversibility a sufficiently universal boundary condition? If not, what additional factors should be considered, such as the high cost of recovery even if it can be undone, or a low probability but extremely severe consequences?

Wang Shangqi: We do have requirements for revocation, but it is not a sufficient or necessary condition. Especially for orders, I can place an order with AI, but I cannot delete the original order/cancel interface, because once you go back and tell the AI to cancel, it’s already too late. So all the existing workflows of AI agents are still in place; revocation actually relies on the original GUI process to ensure it. There is also the recovery cost, which even determines whether AI operations are allowed: for example, stamping or audit automation is not inherently complex, but when large amounts of money or significant responsibility are involved, business users may refuse even a 99% accuracy because the recovery cost is unacceptable. Moreover, explainability and reproducibility are also crucial. Deep learning does not demand high explainability—just look at metrics and data—but in production, agents act on behalf of humans, and business users won’t accept them if they don’t know what they’re doing. It should be able to tell you step by step what it’s doing, like Claude does, and you can pause immediately if something’s wrong. Being pause‑able and explainable is very important.

Qi Longji: It still depends on whether the impact scope is acceptable. For example, AI-driven operations that modify backend marketing or price configurations— even if they can be rolled back, once deployed they will affect a large number of orders. If the impact is unacceptable, an additional manual review must be added before launch. We assume that an agent cannot guarantee 100% accuracy; for critical operations where the consequences are intolerable, manual confirmation is required. Each version of AI outbound calls undergoes a red‑line check to see if it says anything wrong. Some scenarios can be relaxed; for instance, if an amount extraction error occurs, we evaluate the loss rate, and if it is within a controllable range, the release is allowed. So ultimately it comes down to whether the mistake and its impact are tolerable, how large a scope or loss is acceptable, and based on that decide whether to release automatically or require manual confirmation.

Lu Detao: We are a lot like Teacher Qi. For example, if we recommend the wrong order date— the user wants Friday, we push Saturday, the date isn’t prominent on the recommendation card, the user might just pay and even use a coupon. At that point, if we try to roll back, the benefit is already gone, and hotel and transportation prices fluctuate quickly, so the good price disappears. Therefore we have to be especially careful. Secondly, we need to consider whether the user will notice the error, such as an obviously unreasonable itinerary, going back and forth to the same spot, or the recommendation reason says Hotel A but shows Hotel B’s card—none of these are acceptable.

Wang Fang: So B2C focuses more on user experience, while B2B treats safety and responsibility as red lines—who ultimately bears customs clearance errors, and whether an agent’s mistake will affect my performance.

Audience: How does an agent self‑optimize and iterate in business scenarios?

Wang Shangqi: There are two types. For business‑scenario optimization iterations, we are currently looking for bad cases to analyze, determining whether the intent recognition is wrong, the tool selection is wrong, or the tool is correct but the result or format does not meet expectations: if the intent recognition is wrong, we adjust the prompt or switch models; if the tool invocation is wrong, we assess whether the description is inaccurate or there are too many tools that need to be trimmed. In short, we either modify, switch models, or adjust Harness’s supporting configuration. The other part is our work on the MAS platform, AI observability, and AI stability, which we are still exploring. Currently, about 70% of agent optimization is still manual; the industry has some semi‑automated approaches that use tracing to optimize harnesses or skills. Honestly, they don’t work well or are uncontrollable in production scenarios, but they are acceptable in general scenarios.

The so‑called generic scenario is, for example, when OpenClaw becomes popular and the mobile team also creates an internal version for employees, and each department develops various skills to handle documents, handle complaints, etc. Previously we took the open‑source Harness, tweaked it, but the accuracy was not high. Management demanded high accuracy, no complaints, and also required evaluation criteria. We thought of using the call trace to evaluate—if a skill exceeds 20 steps, let the large model automatically analyze from the trace whether the skill generation is poor or the prompt is poor, and then dynamically optimize. In this somewhat generalized generic scenario it is useful: it can reduce the step count from typically over 20 steps and taking several minutes to under 15 steps on average, roughly improving efficiency by about a quarter; accuracy is hard to assess, so we look at whether the repeat generation rate has decreased. Therefore, dedicated business scenarios still rely on human evaluation and test sets, while generic scenarios can try trace‑based automation.

Qi Longji: Our experience shows there are two closed loops. The outer loop is the business metric loop. For example, AI matching solves order pairing; there are many steps, each with its own conversion funnel, so we must first have a business metric system to ensure we are solving the right problem: first find the right driver, then use AI outbound calls, rely on script SOPs, command compliance, and Agent capabilities to talk with the user, and finally close the deal; in between there are outbound line reach rates and connection rates. The outer loop ensures we can identify the bottleneck steps and the correct direction of effort—if the connection rate doesn’t improve, even a strong Agent yields no benefit. The inner loop is the closed loop of the Agent’s own capability. AI outbound calls are open-ended, so we need observability to record the entire process, checking whether intent recognition, ASR, and replies at each step are correct. Often this requires manual labeling; the industry uses LLM-as-a-Judge to accelerate this, and higher‑level models can also be used for labeling, saving a lot of labor. Additionally, large models can extract top‑performer scripts and strategies to speed up business knowledge extraction. Therefore, to iterate the Agent, both loops must be well managed: set a solid business metric system and clarify the direction in which the Agent should work; and for the Agent’s own capabilities, ensure scripts and business strategies are followed and the bad‑case rate is reduced.

Lv Detao:First, the evaluation must be accurate. Our online entry standards rely partly on strict code validation and partly on value models. If the evaluation is inaccurate, the direction of self‑evolution will be wrong, so we need to focus on the evaluation. Second, prepare an online golden dataset called metadata, and run back‑testing on it for every iteration to ensure that modifications are correct, because self‑evolution can easily be hacked and the model can become lazy.

Wang Fang:The core is to have a learnable target. As Professor Qi said, I need to know the logic of a gold‑standard customer service rep or a gold‑standard salesperson, and where that tag is; I also need to define the scenarios under that tag and the strategies to use. Self‑evolution requires such a feedback loop, including using the gold standard for offline back‑testing as Mr. Lv mentioned. First define the problem; as the corpus grows, the agent’s self‑learning feedback ability becomes stronger and can be tied to online metrics. I have done this in a customer‑service scenario before, and it was very effective: offline mining revealed that gold‑standard reps, when customers ask about discount conditions, explain how to use the discount and then use the product to drive clicks, influencing the decision. Because you already have many conversion and non‑conversion outcomes, the non‑conversions are often generic “answer‑the‑question” responses with very low conversion rates.

Wang Fang: The industry currently loves talking about Autonomous Agents, as if the more they can plan autonomously, invoke tools, and complete long tasks, the more advanced they are. However, in production environments, are more autonomous Agents really better for real-world business?

Qi Longji: I have two counterexamples. The first is order placement. We tried a fully agentic approach, giving the model the context, goals, and callable tools, letting it decide autonomously how to interact with the user, and the result was even worse than the pre‑defined workflow. In a clear business scenario, AI tends to output a lot of content; asking a question takes only a few seconds, but understanding it takes much longer. When it acts autonomously it offers the user too many choices, but a specific user just wants a hassle‑free experience—you simply tell them which car and price to choose. You use AI the same way: when making a PPT you just want it to finish quickly, not to discuss it endlessly. The second is AI scheduling. Again we used an agentic setup, handing over the goal, context, and tools for it to decide how to talk to users and drivers. The problem is that the path becomes uncontrollable: it may work in the end, but we don’t know which strategy it used, so we can’t continuously optimize. When a new strategy arrives, we can’t make it follow it to achieve the desired outcome; the link from strategy to execution to result is broken. Therefore, critical nodes need determinism, and we should only let the model act autonomously where its independent contribution is truly needed.

Lu Detao: In a production environment, the Agent must have clear boundaries and responsibilities. Even if it doesn’t reach 100%, it must be above 99%; otherwise it will cause significant damage to the C‑end. It can be flexible within the decision space, such as invoking various tools; but the responses delivered to the C‑end must be cautious—votes, real‑time prices, inventory, product IDs, order statuses must never be wrong. Errors lead to either public opinion crises or financial loss.

Wang Shangqi: From another perspective, what’s the difference between autonomy and loss of control? I understand autonomy as maximizing potential within limited rules, while loss of control means acting outside those rules. Why discuss autonomy? If a task is already very work‑intensive, an Agent is needed, but it should never become increasingly autonomous; autonomy is meant to solve problems that couldn’t be solved before. So the ceiling of autonomy is the flexibility you expect it to have in solving problems, but there must be a threshold—no threshold means loss of control. Technically, the threshold is simple: you’re allowed to invoke tools, but which tools you can call is set by me. Your autonomy lies only in choosing which of the allowed tools to use; the threshold is whether I provide 10 tools or 20 tools.

This also raises another issue: the original term was “trusted programming,” but now general programming is called “untrusted programming” because it writes code on its own. When given ten tools, it thinks it can’t finish the task but forces it anyway, writing its own code to implement it, making the process uncontrollable again. Therefore, everyone needs to use sandboxes. Moreover, why isn’t autonomy sufficient? Because 99% of vendors lack the ability to improve based on its behavior or errors: there are few agentic improvement solutions, harnessing is complex, and it’s often impossible to pinpoint the problem, since most business scenarios can’t retrieve data for reinforcement learning—the cost is too high. In the future, only enterprises that can do this may see increasing autonomy; otherwise, it will remain constrained by thresholds, or it will become out of control.

Wang Fang:Compared with recommendation, advertising and other systems that have already formed mature feedback loops, the optimization chain for enterprise agents is still not standardized. Although trajectory analysis, offline evaluation, and feedback data iteration are possible, achieving attributable, risk‑controlled continuous improvement remains very difficult, and there is a lack of widely reusable production paradigms.

Wang Fang: What will be the core competitiveness of truly valuable enterprise agents in the future?

Qi Longji: The model is the starting point; everyone can choose a base model, and picking a good model gives a higher starting point. In business, the first step is Harness, using engineering to separate certain and uncertain boundaries: give the planning that requires thinking to the model, give the certain parts to engineering, then integrate tools such as machine‑learning algorithms and operations research optimization—this is the lower bound of an enterprise Agent. Above the lower bound, continuous improvement comes from the two closed loops of the business loop and the Agent capability loop. The upper bound is like engineering: the quality of a business system ultimately depends not on the infrastructure but on the extraction of business knowledge and the design of the business architecture, which determines whether the system can support the business for five to ten years or requires a major reconstruction every year. Analogously for Agents, the upper bound lies in how much business knowledge can be extracted, what scenarios are identified, and which effort directions are pursued. So the model determines the starting point, Harness determines the lower bound, the dual loops set the direction, and the depth of business‑knowledge extraction and where effort is applied determine the upper bound.

Wang Shangqi: Whether an enterprise Agent is built by myself or for another company, the core competitiveness and barriers are different. For us, quickly connecting enterprise capabilities is a major challenge. We have worked on standards such as MCP, Skills (maybe not yet protocol type), AGUI, but integrating legacy systems into an Agent is still difficult. I strongly agree on data extraction—without data, an enterprise Agent without data extraction is meaningless. The biggest issue in enterprise production scenarios is that rules and business data are mostly embedded in existing systems. Companies like China Mobile, PetroChina, etc., we have provided some services for them; when you try to diagnose an enterprise you’ll find it hard because you can’t obtain or connect to their systems. So the key for the future is how to use a relatively generic approach to organize and expose the capabilities of enterprises with poor IT infrastructure, turning them into a platform that can be integrated quickly.

Palantir, which was very popular before for data business modeling, has existed for a long time, but its capabilities couldn’t be unleashed. Even after organizing the data and building a platform, it still couldn’t be used—until large models arrived and made it usable. Today, most enterprises lack exactly this kind of Palantir‑style platform that can automatically extract data assets. Another key point is how enterprises balance management with the agents themselves: can a corporate Agent carry responsibilities and processes? We now not only create business Agents, but also link agents with existing business workflows, where the workflow corresponds to the original responsibilities. For example, intelligent approvals and audits require the agent to align with the workflow to ensure clear responsibility and authority. So, on one hand we need the ability to extract enterprise capability data, and on the other hand we need the ability to associate Agents with processes—both built on sufficiently strong harness, loop, and data capabilities.

Lu Detao: Travel is a relatively niche industry. I think the core competitiveness of future enterprise agents will still be the industry supply and knowledge in niche fields, and whether that can become an executable, verifiable, and iterative system capability. For example, itinerary planning—adjusting the base model can produce a decent itinerary, but the challenge is whether it can actually work: the distances between attractions, transportation, opening hours need to align, and the daily travel intensity must be considered, with attractions existing in reality. The itinerary then leads to booking hotels and tickets; prices and inventory must come from real business systems, and the assembled tickets must meet genuine travel needs, with user confirmation before ordering. These are not things a model can freely generate. Models are suitable for understanding preferences, filtering attractions, generating proposals; map routes and opening hours can be fetched with tools, ticket combinations can use deterministic algorithms, but prices and inventory must be provided by business systems. Therefore, the barrier for enterprise agents is not producing a superficially good answer, but whether the company’s own data, tools, algorithms, business rules, and evaluation framework can hold up in the real world.

Wang Fang:This is somewhat like a world model, whether it actually works in the real world. Over the past two years we’ve been discussing how to make agents smarter and do more; but once agents go into production, another issue becomes increasingly important: what are we actually allowing agents to do, and what must be done by humans?

Continuing the hype: See you at AICon Beijing in December