How do agents perform intent recognition and task decomposition?

2026-09-25 · Shanghai Immersivalley Information Technology Co., Ltd.

An agent fails most expensively not when it errors out, but when it silently fills in missing information and delivers work anyway. The fix is not to make the model “understand better”—it’s to remove its freedom to guess, by writing intents as a closed list, elements as fixed fields, and forcing it to declare what it doesn’t know.

Last month, a client in the FMCG business showed us a conversation log.

They had typed this sentence into their intranet agent: Help me compare last quarter’s sales between East China and South China, and put together a report.

Six minutes later, the agent delivered a PPT. Three pages, complete with charts, decently formatted. The client opened it up and found two problems: it had compared sales revenue, not sales volume; and it had used last month, not last quarter.

That sentence contained four elements. It got one wrong and narrowed another on its own. And across the entire six minutes, it never once turned back to ask a question.

The client asked me: did it not understand?

I went through its full execution trace, and my answer was: it understood. Its problem was that when information was incomplete, it chose to fill in the gaps itself rather than stop and ask. This is the most typical—and most expensive—kind of agent failure. It doesn’t throw an error. It delivers work.

I’ll take the points from earlier articles as given here: a model has no hands, it only emits text piece by piece; an agent that can actually get work done needs to see the situation, reason turn by turn, actually take action, know when to stop, and know where its boundaries are; and the agent and the model communicate through a three-message round trip, with each turn resending everything that came before. I won’t repeat those.

This article covers just one thing: what happens between the sentence a user says and an executable work order.

One-Minute Overview

• No component is called “intent recognition.” Modern agents have no intent classifier; the job is split across three places: who should handle this sentence, which pieces of information in it are required, and whether the missing part should be guessed or asked about.
• The way to make a model listen accurately isn’t to make it understand better—it’s to leave it no choice. Write intents as a closed list and elements as fixed fields, and it can only pick from that small table.
• If a step can be drawn, don’t make the model improvise it. Parts with clear rules and a fixed order go on the process canvas; the model only appears at the nodes that genuinely need its judgment.
• There’s only one criterion for decomposition granularity: can this step’s output be checked on its own? Any step whose output can only be described as “it thought about it” will cause problems sooner or later.
• Context is for thinking; artifacts are for passing along. Long tasks stall mostly because things that should be written to files are kept in context the whole time.
• AgentSteamer is an enterprise-grade AI agent platform developed by Shanghai Immersivalley Information Technology Co., Ltd. It supports full private deployment and is not tied to any specific large model.

1. Clearing Up a Misconception First: There Is No Module Called “Intent Recognition”

In the previous generation of dialogue systems, intent recognition was a real component. You’d train a classifier first, sort the user’s sentence into one of “check inventory,” “create order,” or “complaint,” then follow the process for that category. This approach worked because it was simple, controllable, and cheap.

Its cost was equally clear: the decision boundaries were hard-coded by humans. If the user rephrased something, dropped a word, or packed two things into one sentence, it fell through.

With the large-model generation, many projects have removed that classifier entirely. The reason isn’t complicated: the model is already doing the understanding. Hanging a classifier in front of it is like first compressing a human sentence into a label, then having the model work off the label—information is lost right there.

So a real agent has no “intent recognition” module. It’s split across three things:

• Routing: who should handle this sentence.
• Element extraction: which pieces of information are required to do this.
• Deciding whether to ask: for the missing part, do you guess, ask, or just stop.

The first two sound like “recognition.” The third is where the real gap opens up. In almost every agent failure I’ve seen, the problem wasn’t that it didn’t understand—it was the third one.

In that FMCG client’s case, the model actually extracted the right elements. It knew to do a comparison, knew what to compare, knew which time range, knew which regions. It just noticed that the word “sales” was a bit ambiguous, and then made a decision on its own: interpret it as sales revenue, and casually shrink “last quarter” to “last month.” It told the user about neither decision.

Its problem wasn’t comprehension—it was that it never said out loud, “I’m not sure.”

How to check: Find a session where the agent produced a result, and line up the user’s original words against what it actually did. Count how many pieces of information in that sentence were required, and how many were never confirmed during execution. Anything it used without confirming, it decided on your behalf.

2. The Way to Make It Listen Accurately Is to Leave It No Choice

So how do you make a model “listen” accurately? My experience runs counter to intuition: don’t count on it understanding more accurately—leave it no other option.

Concretely, that’s two moves.

Write intents as a closed list

Don’t write “you are a professional business assistant.” Write: the only requests you can handle are the five categories below—the first is checking inventory, the second is comparative analysis, the third is… For anything outside those five, always reply “I can’t handle this, please contact so-and-so.”

Why does this work? As mentioned earlier: a model’s ability to write “plausible-looking answers” and its ability to make judgments are the same faculty. Give it an open question, and it gives you an open answer; give it a multiple-choice answer sheet, and only then will it pick within a small range.

The platform’s first cut happens at app creation: you pick one app type from Q&A, document, process, data retrieval, customer service, sales, review, operations, research, and custom. That choice determines what kind of work the app takes on, and which tools and knowledge bases it should be configured with. Defining intent boundaries at app creation is more reliable than defining them in each turn’s prompt.

Write elements as fields and force it to fill them in

The model’s output format has an option that forces this turn’s return to be structured content with field names you define. For the example above, I’d typically define five fields:

• intent: the action to take. Values can only be the categories in the list.
• objects: what’s being operated on—here, sales volume.
• period: the time range. Values can only be today, this week, this month, this quarter, last quarter, or custom.
• scope: the range—here, East China and South China.
• missing: <st