From Answering Questions to Getting Work Done: The Capability Leap and Engineering Landing of Agentic Models

1. Background: Why Answering Questions Is No Longer Enough

Over the past two years, evaluation of large models has centered on single-turn tasks such as knowledge Q&A, text generation, and code completion. These tasks share common traits: clear input, closed context, and output that can be judged in one pass. As long as a model “answers correctly and writes plausibly,” it earns a high score.

But real production scenarios are rarely this ideal. What developers actually need models to accomplish often has the following characteristics:

• Vague goals: A user only says “help me complete the logging for this module,” without specifying format, fields, or where to persist the data.
• Long step sequences: A single task may require reading files, checking documentation, editing code, running tests, and fixing errors, potentially looping a dozen times.
• Dependence on external environments: It requires invoking command lines, accessing APIs, reading and writing databases, and manipulating file systems.
• Mid-task failures: Tool errors, API timeouts, and insufficient context all require the model to judge the situation and adjust its strategy on its own.
• Results that need verification: The output is not “looks correct” but “actually runs successfully.”

This is precisely the dividing line between “answering questions” and “getting work done.” Question-answering models optimize the quality of a single output; working models optimize the completion rate of multi-step tasks. The former is a function; the latter is a loop.

From an engineering perspective, this shift is not a minor tuning of model parameters but a restructuring of the entire application architecture: context management, tool protocols, state persistence, error recovery, permission control, and observability all need to be redesigned. This article focuses on this theme, breaking down the key capability dimensions of agentic models and offering a practical engineering path for implementation.

2. Capability Breakdown: Four Key Dimensions from Single-Turn to Multi-Step

2.1 Task Decomposition and Planning

Single-turn Q&A does not require planning because the question itself is a complete instruction. Multi-step tasks, however, require the model to first break the goal into sub-goals and then determine the dependencies among them.

A common misconception is to interpret “planning” as having the model output a nice-looking to-do list. True planning capability is reflected in three aspects:

1. Adaptive granularity: Simple tasks are not decomposed; only complex tasks are. Over-decomposition inflates the number of calls and actually lowers the success rate.
2. Executability: Each sub-step can be mapped to a concrete action (read a file, call a tool, generate a patch), rather than vague descriptions like “analyze” or “optimize.”
3. Rollback capability: The plan is not written once and frozen. If a step fails during execution, the model needs to be able to replan the remaining path.

In engineering implementation, a “plan–execute–reflect” loop structure is typically used. Below is a simplified pseudocode illustration:

def run_agent(goal, tools, max_steps=20):
    plan = planner(goal, tools)          # initial plan
    state = init_state()
    for step in range(max_steps):
        action = select_action(plan, state)   # select the next step from the plan
        result = execute(action, tools)       # execute, may succeed or fail
        state = update_state(state, action, result)
        if result.failed:
            plan = replan(goal, state)        # replan after failure
        if goal_satisfied(goal, state):
            return state
    return state  # reached step limit, return current state

The key to this code is not the loop itself, but the replan and goal_satisfied components—they determine whether the model can recover from errors and whether it can judge that the task is truly complete.

2.2 Tool Invocation and Protocol Specification

“Getting work done” necessarily means the model must operate on the external world. The core difficulty of tool invocation is not “whether it can be called” but “whether it is called accurately and reliably.”

In practice, the following issues need to be addressed:

• Accuracy of tool descriptions: Tool names, parameters, and semantics must be clear and unambiguous. Vague parameter naming is the primary cause of invocation failures.
• Parameter validation: Model-generated parameters may be missing fields, have type errors, or fall out of range. Structured validation must be performed before execution, rather than passing errors directly downstream.
• Invocation idempotency: Retries are the norm, so write-operation tools must be designed for idempotency to avoid side effects from repeated execution.
• Result trimming: Tool return content can be very long and needs to be truncated or summarized before being fed back into context; otherwise, it quickly exhausts the context window.

A robust tool definition should include a parameter schema and error semantics:

tool_spec = {
    "name": "write_file",
    "description": "Write content to the file at the specified path, overwriting if it exists",
    "parameters": {
        "path": {"type": "string", "required": True},
        "content": {"type": "string", "required": True},
        "encoding": {"type": "string", "default": "utf-8"}
    },
    "idempotent": True,
    "timeout_ms": 5000
}

It should be emphasized that the reliability of tool invocation depends heavily on the readability of error information. If a tool returns only a status code on failure, the model cannot correct itself based on it; if it returns “parameter path is missing, please provide a relative path,” the model can self-heal in the next turn. Therefore, the tool layer should take on the responsibility of “translating machine errors into feedback the model can understand.”

2.3 Context and State Management

The greatest enemy of multi-step tasks is context bloat. Each step’s tool returns, model reasoning, and intermediate results all compete for window space, causing early critical information to be pushed out.

Common management strategies include:

• Layered context: Divide context into “goal layer (task description),” “plan layer (current plan),” “fact layer (confirmed environment information),” and “trajectory layer (historical actions and results),” with different retention priorities for each layer.
• Summary compression: Perform rolling summarization of historical trajectories, keeping only conclusive information and discarding redundant intermediate output.
• External memory: Write long documents and large result sets to external storage, keeping only reference identifiers in context and reading them on demand.
• State snapshots: Persist state at key nodes to support interruption recovery, avoiding starting from scratch after a task failure.

There is an easily overlooked point here: state is not just the model’s conversation history. Whether a file has been modified, whether tests have passed, and whether a certain API has been called—these environmental facts must be explicitly recorded; otherwise, the model will repeat executions or misjudge progress in the next turn. Treating conversation history as the sole source of state is a typical cause of multi-step task breakdown.

2.4 Result Verification and Self-Correction

For “answering questions,” humans judge whether the output is correct; for “getting work done,” the model needs to judge it first itself.

Verification methods generally fall into three layers:

1. Syntax layer: Whether the generated content can be parsed (whether JSON is valid, whether code compiles).
2. Semantic layer: Whether the result satisfies task constraints (whether fields are complete, whether the logic is self-consistent).
3. Execution layer: Validate the result in a real environment (run tests, call APIs, compare outputs).

The cost of the three layers rises in order, so a reasonable strategy is “cheap first, expensive later”: syntax errors are sent directly back to the model for rewriting, semantic issues are self-checked by the model, and only execution-layer verification actually consumes external resources.

The key to self-correction is the quality of the feedback signal. If verification returns only “failed,” the model has no starting point; if it returns “missing closing bracket on line 3,” the correction success rate improves significantly. This is consistent with the principle of tool error handling: feed actionable diagnostic information back to the model.

3. Engineering Landing: Practical Points for Building Stable Agent Workflows

3.1 Make the “Loop” Infrastructure

Many teams write the agent loop into business code during the prototype stage, resulting in scattered logic and difficult debugging. A more reasonable approach is to abstract the loop into runtime infrastructure, with the business side only responsible for providing tools and validation rules.

The runtime needs to provide capabilities including:

• Step count and time budget control to prevent infinite loops;
• Input/output tracing for each step to facilitate replay and troubleshooting;
• Concurrency and rate limiting for tool invocations;
• Failure retry and degradation strategies;
• Breakpoints for human intervention (pause for confirmation before critical write operations).

3.2 Observability Is a Prerequisite for Stability

Troubleshooting agent applications is much harder than traditional applications because failures are often “decision errors” rather than “code exceptions.” Therefore, it is necessary to record:

• The planning content and actually selected action for each step;
• The complete parameters and returns of tool invocations;
• Changes in context window usage;
• Verification results and correction trajectories.

This data can be used not only for troubleshooting but also for building regression test sets—solidifying real failure cases into evaluation cases is one of the most effective ways to improve task completion rates.

3.3 Permission and Boundary Control

Letting models “get work done” means granting them operational capabilities, so boundaries must be clear:

• Grant tools according to the principle of least privilege, separating write operations from read operations;
• Require mandatory human confirmation for high-risk operations (deletion, publishing, billing);
• Set whitelists for file system and network access;
• Retain audit logs for all write operations.

These measures are not distrust of model capability but necessary engineering constraints—any automated system needs guardrails.

3.4 Trade-Offs from Single-Agent to Multi-Agent

As task complexity rises further, a single agent’s context and responsibilities become overloaded. At this point, it can be split into multiple roles (such as planner, executor, and reviewer), each holding an independent context.

But multi-agent systems are not without cost: communication overhead, state synchronization, and blurred responsibility boundaries all increase system complexity. Practical advice is to first get the workflow running with a single agent, clarify the bottleneck, and then split, rather than designing a complex multi-role architecture from the start.

4. Summary

From “answering questions” to “getting work done,” the essence is the evolution of model application form from “function calling” to “process orchestration.” The evaluation criteria change accordingly: no longer the fluency of a single output, but the completion rate of multi-step tasks, the ability to recover after failure, and the controllability of the entire workflow.

For developers, four things deserve focus:

1. Planning must be executable and rollback-capable, rather than remaining at the level of text;
2. Tools must be validatable and diagnosable, and error information must be consumable by the model;
3. State must be explicitly managed, and conversation history cannot be treated as the sole source of truth;
4. Verification must be layered, using low-cost methods to intercept most problems.

Improvements in model capability will continue to lower the threshold for “getting work done,” but these engineering-side constraints will not disappear. Turning loops, tool protocols, state management, and observability into reusable infrastructure is the key to making agent applications truly stable in production.