From Answering Questions to Getting Work Done: A Deep Dive into the Agentic Evolution of LLMs

For the past two years, competition among large language models has centered on one question: who answers more accurately? Whether the test was knowledge Q&A, content writing, or code completion, quality was measured within the scope of a single conversational exchange. The direction of recent next-generation model releases, however, sends a clear signal: the industry’s frame of reference is shifting from “answering ability” to “working ability.” A model no longer just produces a block of text—it receives a goal, autonomously decomposes it into steps, calls tools, executes operations, verifies results, and ultimately delivers a usable output. The industry calls this the “agentic” transformation of LLMs. This article breaks the transition down across five layers: the capability divide, technical foundations, engineering practice, evaluation, and safety governance.

1. “Answering Well” vs. “Getting Work Done”: One Word, Two Paradigms

A model that “answers well” is, in essence, a knowledge retrieval plus text generation engine. The user asks a question; the model responds with text within one or a few turns, and the output is the end of the story. Its ceiling is set by knowledge coverage, language organization, and reasoning depth, and its success metric is “how good the answer is.”

A model that “gets work done” is a closed-loop, goal-to-result system. Given the same requirement, its workflow becomes:

1. Understand the goal and constraints: both explicit requirements (delivery format, time range) and implicit constraints (data definitions, business rules);
2. Decompose the task: turning a fuzzy goal into an ordered, executable sequence of subtasks;
3. Call tools: autonomously selecting retrieval, database queries, code execution, external APIs, and other means to obtain real data;
4. Correct course dynamically: observing the result of each step and re-planning when it encounters errors, empty results, or mismatched data definitions;
5. Deliver and self-check: validating the output for format and logical consistency, attaching process notes when necessary.

The differences can be summarized in one comparison table:

Dimension	Answers well	Gets work done
Unit of interaction	One conversation turn	One complete task
Output form	A text snippet	A structured deliverable / a system state change
Failure handling	The user rephrases the question	Self-reflection, retries, alternative paths
Success metric	Answer accuracy and fluency	Task completion rate, cost, latency
Risk boundary	Says the wrong thing	Does the wrong thing, with real side effects

The last row deserves particular attention: as the model moves from “saying” to “doing,” the cost of a mistake escalates from “an inaccurate paragraph” to “an incorrect change operation.” This is why agentification is not merely a model capability upgrade—it is a wholesale reconstruction of the engineering and governance systems around the model.

2. The Four Technical Foundations of “Getting Work Done”

1. Deep Reasoning and Task Planning

The prerequisite for working is thinking clearly. New-generation models have broadly strengthened long-chain reasoning: before emitting an action, they unfold multi-step deliberation—decomposing the task, comparing alternative paths, and anticipating risks. The prevailing industry practice is the “reason–act” loop: in each round, the model first outputs its analysis of the current situation and then decides the next action; when the action’s result feeds back, a new round of reasoning is triggered. This mechanism of “thinking while doing, and correcting while doing” is what keeps an agent stable in open, uncertain environments.

2. Tool Calling and Structured Output

A model that works must “grow hands.” Through tool-calling mechanisms, the model drives external systems with structured parameters, which imposes two hard requirements:

• Strictness: the output must strictly conform to the tool’s parameter schema—correct types, valid enum values, and all required fields present;
• Selectivity: choosing accurately among tens or even hundreds of candidate tools without misusing or overusing them.

The engineering lesson here: the more standardized the tool description, the more accurate the model’s calls. A good tool definition should include semantically clear names, a statement of purpose, parameter constraints, and typical examples:

{
  "name": "query_sales_summary",
  "description": "Query sales summary data for a specified time range and region, returning total amount and order count",
  "parameters": {
    "type": "object",
    "properties": {
      "start_date": { "type": "string", "description": "Start date in YYYY-MM-DD format" },
      "end_date":   { "type": "string", "description": "End date in YYYY-MM-DD format" },
      "region":     { "type": "string", "enum": ["north", "south", "east", "west"] }
    },
    "required": ["start_date", "end_date"]
  }
}

3. Long Context and Memory

Real tasks often span enormous amounts of material: dozens of pages of requirements documents, codebases with thousands of lines, tens of thousands of log entries. Long-context capability determines whether the model can “read it all in one pass,” while memory mechanisms determine whether it can “remember across sessions.” What matters even more in engineering is context engineering: how the task goal, tool list, history trajectory, and intermediate results are organized in layers, when to compress them into summaries, and when to retrieve them on demand—these decisions directly determine the stability of long-running tasks. The rule of thumb: keep the information that must always be present (goals, constraints, key state) in a stable region, and promptly evict use-once-and-discard intermediate artifacts from the context window.

4. Code Generation and Sandbox Execution

Code is the most universal all-purpose tool in an agent’s toolkit: data analysis, format conversion, and batch file processing can all be solved by generating a snippet of code. Its value lies in compiling the “probabilistic output of natural language” into “reproducible, deterministic computation” that is inherently testable and rollback-ready. On the engineering side, the execution environment should run in a controlled sandbox—restricted network access, an isolated filesystem, whitelisted dependencies—so that “badly written code” never turns into “a broken environment.”

3. Engineering Practice: Assembling a Model into a Reliable Agent

1. The Core Loop: Plan, Execute, Observe, Reflect

A robust agent skeleton can be sketched in pseudocode:

function run_agent(goal, tools, memory, max_steps):
    context = memory.load()
    for step in 1..max_steps:
        plan    = model.reason(goal, context, tools)        # reasoning and planning
        action  = plan.next_action()                        # choose the next action
        if action.type == "deliver":
            return verify(action.result, goal)              # self-check before delivery
        result = sandbox.invoke(action.tool, action.params) # execute inside the sandbox
        memory.append(action, result)                       # record the trajectory
        if result.failed:
            context += model.reflect(result.error)          # reflect on failure
        context = memory.compact(context)                   # compress the context
    return escalate_to_human(goal, memory)                  # escalate to a human when the step limit is reached

Three design points: a step cap prevents infinite loops from burning cost; failure reflection turns error messages into input for the next round of planning; and escalation on limit ensures the system degrades gracefully at the edge of its capability instead of grinding on to the bitter end.

2. State Persistence and Checkpoint Recovery

A long task may run for tens of minutes, and any intermediate step can be interrupted by a timeout or a rate limit. Persisting every step’s action and result as checkpoints—combined with idempotent tool design (re-running the same operation produces no side effects)—lets the task resume from the breakpoint instead of starting over from scratch.

3. Deployment and Infrastructure

When agent applications move into production, general-purpose cloud infrastructure significantly reduces engineering overhead: container platforms isolate execution environments, message queues turn long tasks asynchronous, object storage manages intermediates and deliverables, and logging services plus monitoring and alerting deliver full-chain observability. On cloud platforms such as Baidu AI Cloud, these capabilities are offered as general-purpose products that developers can combine on demand, rather than building the entire underlying infrastructure themselves.

4. Rethinking Evaluation: From Answer Accuracy to Task Completion Rate

In the era of “answering” models, evaluation revolved around per-question accuracy. Once models start “working,” evaluation must be end to end:

• Task completion rate: across a set of real tasks, the proportion the agent completes without human intervention;
• Step success rate and tool-call accuracy: pinpointing whether failures occur in planning, tool selection, or parameter construction;
• Cost and latency: the average number of inference calls consumed per task and the end-to-end elapsed time;
• Human takeover rate: the proportion of tasks requiring human intervention mid-stream, which directly determines real operating cost.

The practical recommendation is to build a tiered task benchmark: from single-tool short tasks, to multi-tool medium tasks, to cross-system long tasks, increasing pressure level by level to map the capability boundary curve—and then deciding which scenarios can be handed to the agent for autonomous execution, and which must retain a human confirmation checkpoint.

5. Safety and Governance: Making Agents Controllable and Auditable

The stronger the capability, the tighter the reins. An agent’s governance checklist should include at least five items:

1. Least privilege: each tool is granted only the minimum permissions needed to complete its task, with deletion and fund-related operations isolated separately;
2. Sandbox isolation: code execution and external access both take place in controlled environments;
3. Human review for sensitive operations: irreversible actions (data deletion, outbound sends, production changes) require mandatory human confirmation;
4. Full-chain audit: every reasoning input, tool call, parameter, and result is recorded, enabling a complete replay after the fact;
5. Rollback: key changes retain snapshots or operation logs so that errors can be recovered.

6. Conclusion

The standard for judging what makes a new-generation LLM “strong” has changed: it is no longer just “does it answer well,” but whether it can, in a real environment, carry one task through from start to finish. For developers, this is both an opportunity and an engineering challenge—four foundations (reasoning, tools, context, execution) must be connected, and two systems (evaluation and governance) must be rebuilt. Forging an “answering” model into a “working” agent will be the main battleground of the next phase of application deployment.