At 8 a.m., Wang, a line supervisor, finds the box-carrying robots piling up again in Zone A. It is a familiar headache on the floor… He wants to know what actually happened after 11 p.m. last night: which robots were involved, where they got stuck, whether any faults were raised, and at which step the orders began to pile up.

Answering that is not hard. What makes it hard is that Wang has to open the system and pull up five or six different screens:

1. Filter the order list by time
2. Open each order to read its execution log
3. Switch to the robot page for the status at that moment
4. Cross-check timestamps against the alarm log
5. Reconstruct the whole timeline in his head

Before, this would eat half his day. By the time he traced the problem, the morning was gone, and lunch had lost its appeal. Then Wang started using the M4 AI Assistant, and it found the root cause in minutes.

But can a large model really solve everything?

Many people will say: today's models are powerful. Just ask, "Why did orders pile up in Zone A last night?", and it will work out the answer and send it back.

The reality is quite different. A large model can reason, but it cannot carry out the operations for you. So how is the M4 AI Assistant able to dispatch orders directly? Let us start by clarifying a few concepts.

How Large Language Models and Agents Relate

Across the industry, an Agent is commonly understood as a large model plus a Harness. Whatever the large model does not do is the Harness.

Taken literally, "harness" is the gear strapped to a horse so its strength can actually pull a cart. The metaphor holds up well.

Put it in shop-floor terms: a large model is like a vastly knowledgeable engineer who has never set foot in your plant. They understand the principles, they reason well, they express themselves clearly, and they can pick up whatever you tell them. But they do not hold the keys to your plant. They have no system permissions, no view of live status, and no way to walk over and press a button.

Everything needed to put that person properly on the job — an ID badge, permissions, operating procedures, a review process, and someone to take over when things go wrong — that is the Harness. The person together with that whole mechanism is what we call an Agent.

So the division of labor is clear. Within a single task, the large model handles exactly three things:

1. Think: assess where things stand and decide what to do next, and why.
2. Propose: put forward a concrete action, such as "query the order list for this time window."
3. Stop: decide that there is enough information to give an answer.

Everything else belongs to the Agent:

• Actually executing that action — which API to call, how to validate parameters, what to do on a timeout, how many times to retry a failure, and whether this person is authorized for this operation.
• Managing the context. Every turn makes the conversation history longer. The model's context window has a limit, and anything beyond it is lost. The Agent decides what to keep and what to compress.
• Keeping the loop under control. Left to itself, a model can easily spin in place: calling the same tool again and again, or circling the same line of reasoning. The Agent has to impose hard limits: a maximum number of steps, a break-out after repeated identical actions, and a hard stop once the total time is exceeded.

An Agent, then, is neither a different kind of large model nor merely a chat interface. The large model supplies the understanding and judgment; the Agent supplies the tools, processes, and boundaries that turn that judgment into action.

Agents Handle Multi-Step Tasks Through an Understand-Act-Feedback Loop

Traditional software waits for the user to complete a chain of operations: find the entry point, select the object, fill in the details, submit the task, then switch screens to check progress.

An Agent typically receives a goal instead. For example: "Deliver one box of material A to workstation 3."

An Agent with the right capabilities and permissions might work through it like this:

1. Understand that the user wants to complete a material delivery.
2. Check whether the material, starting point, and quantity are complete; ask follow-up questions if anything essential is missing.
3. Query the live status of inventory, robots, and the dispatch system.
4. Determine whether the conditions for execution are met, and form a plan.
5. Ask the user to confirm where needed, then create the transport task in the system.
6. Keep pulling execution results; when something goes wrong, analyze why, and decide whether to continue or hand it back to the user.
7. Verify that the material actually arrived at the destination, then report the final result.

The process comes down to: understand the goal, take action, get feedback, reassess, and then finish, continue, or ask the user.

The value of an Agent comes from this loop. It goes beyond one question and one answer, advancing the task according to the changing state of the real world.

What Agents Can Do for Us

In robotics projects, the large model (LLM) interprets what the user says, analyzes information, and decides the next step, while the Agent queries systems, calls tools, and retrieves real results. Together, they take on three kinds of work.

Turning Cross-Screen Investigation into a Single Conversation

Take the question from the opening. When a user asks why orders piled up in Zone A last night, the LLM identifies the time window, the area, and the type of question, and works out what else it needs. The Agent then queries orders, robot status, and alarm logs. With the data in hand, the LLM reconstructs the timeline and explains the cause. The user no longer switches screens back and forth, or assembles scattered information by hand.

Turning Scattered Experience into Knowledge on Demand

The Agent can search product documentation, release notes, and historical tickets, while the LLM filters what is relevant, distills the key points, and produces an answer that is easy to follow.

This reduces reliance on a handful of experienced staff, and the answer carries its source and version so the user can verify it further.

Handling Imprecise Human Language

A robot might be named AMB-01, while people say amb 1, amb01, or AMB 1. Speech input may even come through as "amb one." Tool interfaces, however, require exact values. This is precisely where a large model outperforms traditional rules by a wide margin. Rather than writing a pile of conversion rules for letter case and symbols, which you will never finish, hand the model the list of robots that actually exist on site at the start of the session — "this system contains the following robots." The model can then match amb 1 to AMB-01 on its own, with a markedly higher success rate.

Whether an Agent works well often depends less on how strong the model is than on whether anyone has thought carefully about how information is fed to it.

What Agents Cannot Do Today

An Agent's reach is set by what people have connected to it. It only uses the tools and skills already installed: it can look up an order because someone built an order query interface, and it can run a simulation because someone wrapped that into a skill. Where the corresponding capability does not exist in the system, it cannot get the job done.

And even with the full set of tools, stringing them into a dependable, complete delivery still takes real work: picking the right tool, resolving a vague reference into a specific object, retrying or rerouting after a failure, and confirming the goal was actually met once a result comes back. More sobering still, the parameters a large model produces are a high-probability guess, and that falls short of the reliability a gate demands. So irreversible operations stay with a human to confirm, and interfaces have to return accurate errors of their own, such as "this order is already complete and cannot be cancelled." Once an Agent goes beyond conversation and starts changing physical state, scrutiny tightens further: approval before the operation, idempotency protection for repeated execution, mutual exclusion between similar operations, full auditing, and the ability to take over at any time. None of these can be skipped.

These mechanisms have nothing to do with how pleasant the conversation feels, yet they decide whether an Agent can go live at all.

Why Agents Are Harder to Build for a Factory

General-purpose Agents already write code, research topics, and organize files, and they do it smoothly. Moving that same set into a workshop runs into three additional constraints.

The cost of a mistake cannot be undone. In a chat, when the model gets something wrong, you simply ask again. On the floor, a robot moving the wrong way can mean a collision, a halted line, or damaged goods. So approval before the operation, idempotency protection for repeated execution, mutual exclusion between similar operations, full auditing, and the ability to take over at any time are all indispensable. None of these mechanisms has anything to do with conversation quality, yet they determine whether you can ship at all.

An industrial-grade Agent has to know the domain. A general assistant can help you write a weekly report, but it does not know the difference between Executing and Pending, nor which alarms need immediate attention when forklifts and box-carrying robots share the same routes. What makes this harder is that on-site conditions change every second: a robot position retrieved a few minutes ago may already be stale, and any judgment has to rest on live data.

Permissions have to line up with people. Who can dispatch orders, who can change dispatch settings, and who gets read-only access are already spelled out in industrial systems. Once an Agent is connected, it has to follow the same rules and leave an auditable record behind.

This is where the industrial bar sits. Handling conversation well is only the entry ticket; completing a task safely in a real operating environment is the hard part.

The Second-Generation M4 Agent Is Coming

In 2025 we released the M4 AI Assistant, which brought natural language into the management and control of robot systems. Users could express what they needed in text or speech, covering order dispatch, robot and order status queries, inventory lookups, and problem analysis.

That introduced a new way of working: rather than translating their goal into a series of page operations item by item, users can start by stating what they want to accomplish, and let AI bridge the gap between that goal and M4's actual capabilities.

The M4 AI Assistant proved the value of combining large models with robotics business logic, and it prompted a further question: if an Agent had a more independent product form, a richer set of task methods, and a more complete execution process, what else could it help users accomplish?

Building on the M4 AI Assistant, we are now developing a second-generation Agent.

This new work moves beyond a single feature entry point inside M4, aiming instead at robots and complex systems, and at interaction and execution that are more independent and more flexible. It keeps natural language as the entry point and focuses on several directions:

• Supporting more robot management and on-site work through extensible task methods.
• Showing the execution process, the capabilities being called, and current progress more clearly.
• Adapting to different devices and usage scenarios, so users can interact with robot systems more conveniently.

These directions are still being refined. What we expect from the second-generation Agent goes beyond a smarter chat box: a more natural, more transparent, and more trustworthy way for people and machines to work together.