From “Who Are You?” to “Do the Work”: How to Use AI Agents Correctly

1. Why Most Users Start by Asking “Who Are You?”

When opening a new conversational AI tool, many people perform nearly the same first action: they type “Who are you?” or “What can you do?” into the input box. It is a familiar instinct, much like writing “Hello, world” as the first line of code for a programming beginner.

This opening question is not wrong. It is a low-cost way to probe capabilities. However, if users stay at this level of questioning, they are still using the tool with the mindset of a search engine: ask a question, receive an explanation, and then do the work themselves.

The root of the problem is a mismatch in expectations. Many people assume that the other side of the chat box is simply a more conversational assistant. In reality, it is a model plus an execution framework. The model determines how quickly it can think, while the execution framework determines whether it can act, and whether it can act accurately.

Once this structure is clear, the natural shift is from “Who are you?” to “Help me do this task.”

2. What an AI Agent Is Made Of

Agent products differ in form, naming, and interface, but their underlying structure is similar. An agent can be understood as six layers:

1. Model layer. This layer handles intent understanding, step planning, and content generation, including multimodal models that can understand images and other visual information. It is the most visible layer, but it is not the only factor that determines effectiveness.

2. Tool layer. A model by itself mainly produces text. What allows it to “take action” is the set of callable tools: reading and writing files, executing commands, retrieving information, calling external APIs, and controlling a browser. Whether tools are clearly defined and accurately described directly affects the success rate of tool calls.

3. Orchestration layer. This layer decides how a task proceeds: whether to plan first or act first, which tool to call at which point, whether to retry or switch strategies after failure, and when to stop and ask a human for confirmation. It is usually implemented as a loop-control logic.

4. Context and memory layer. This includes the current conversation window, workspace files, long-term memory, and retrieved external knowledge. What is placed into the context, how it is trimmed, and how it is compressed often matters more than switching to a stronger model.

5. Execution environment layer. This is where tools actually run: a local directory, a temporary workspace, or an isolated container. It defines both capability boundaries and risk boundaries.

6. Governance layer. This includes permission models, confirmation for sensitive operations, operation logs and auditing, and cost and quota controls. It is often ignored for personal use, but it is essential for team use.

When these six layers are viewed together, a counterintuitive conclusion appears: the same model can achieve very different task completion rates under different tool configurations, context management strategies, and permission settings. Switching models is often not the first optimization step; changing how the agent is used is.

3. What Happens When You Ask an Agent to “Do the Work”

To understand why some instructions succeed while others disappear without a trace, it helps to understand the closed loop of an agent task. A typical delegated task goes through the following stages:

User assigns a task
   ↓
[1] Intent parsing: define the goal, boundaries, and acceptance criteria
   ↓
[2] Environment awareness: read workspace files, available tools, and current permissions
   ↓
[3] Task planning: break the task into ordered steps and identify parallel or serial parts
   ↓
[4] Tool invocation: construct parameters → execute → parse the returned result
   ↓
[5] Result verification: does it meet expectations? If an error occurs, should the plan change?
   ├─ Not met → return to [3]/[4], adjust the plan or retry (limited by maximum rounds)
   └─ Met    → summarize output, explain the basis, and deliver the result to the user

# Example: a controlled agent execution loop
MAX_STEPS = 30  # Hard limit to prevent infinite loops
def run_task(task: str, tools: dict, context: dict) -> str:
    plan = planner(task, context)            # 1. Task planning
    history = [task] + context.summary()     # 2. Assemble context
    for step in range(MAX_STEPS):
        decision = model.next_action(history, tool_specs=tools)
        if decision.type == "final":
            return verify(decision.output, task)  # 3. Verify before delivery
        if decision.risk_level >= "HIGH":
            ask_human_confirm(decision)           # 4. Human confirmation for high-risk actions
        result = tools[decision.tool](**decision.args)
        history.append(observation(result))       # 5. Record observation for the next reasoning step
    return "The task exceeded the maximum number of executable steps. Please split it and retry."

Three design constraints in this pseudocode are especially important:

• Maximum step limit. This prevents the model from repeatedly spinning on the wrong path.
• Human confirmation for high-risk operations. This applies to actions such as deletion, payment, or public release.
• Verification before delivery. This helps distinguish whether the output merely looks like an answer from whether it actually is an answer.

These are not optional enhancements. They are the dividing line between whether an agent can be trusted.

4. Replace “Who Are You?” with “What Should Be Delivered”

An agent with the same capability level can produce very different results depending on how the task is described.

Weak instruction:

Help me organize this project's code.

This lacks a goal, scope, and acceptance criteria, so the model can only guess.

Strong instruction:

Goal: Add type annotations and basic unit tests to the Python code under the /src directory.
Scope: Only handle modules under /src/service. Do not modify /src/legacy.
Constraints:
  - Keep existing function signatures unchanged. If a change is necessary, explain the reason first and wait for my confirmation.
  - Do not add third-party dependencies.
  - Use the project's existing testing framework. Aim for test coverage above 60%.
Acceptance criteria: All tests pass after running the project's built-in test command. Provide a list of changed files and a summary of test results.
Prohibited: Do not modify configuration files, commit code, or push to a remote repository.

A well-formed task description usually includes six elements:

• Goal: The result to be achieved, not the action to be executed. “Make the error disappear” is an action; “Make the interface stop timing out under concurrency” is a goal.
• Context: Relevant file paths, existing implementation, business background, and known pitfalls.
• Constraints: Technology stack, dependency limits, code style, and parts that must not be changed.
• Acceptance criteria: How to determine completion and what commands or checks should be used for verification.
• Permission boundaries: Which operations are not allowed, such as committing code, deleting files, or sending information externally.
• Delivery format: Code, a report, charts, or a conclusion that can be directly pasted.

This structure is essentially a simplified requirements document. The upper limit of an agent’s output quality is largely determined by the completeness of the information in the task description. Ambiguous input produces ambiguous output, regardless of the model used.

5. How to Choose a Model: Not “Which Is Strongest?” but “Which Is the Best Fit?”

The original discussion began with a list of models supported by a tool. This can be generalized into a broader engineering question: How should models be selected for agent scenarios?

It is better to evaluate models across the following dimensions rather than relying only on benchmark scores:

• Instruction following. Can the model strictly follow multiple constraints, including what it must not do? This directly affects the safety boundary of the task.

• Stability of tool calling and structured output. Can the model reliably produce parameters that conform to a schema? Does it drift across multiple tool calls? This is critical for agent pipelines, and much more important than casual conversation quality.

• Long-context performance. Window size is not enough. It is also important to check recall for information in the middle of long documents, since relevant details can easily be missed.

• Multimodal understanding. This is necessary when the task involves screenshots, scanned documents, or locating interface elements.

• Cost and latency. Cost should be calculated as the total number of tokens consumed to complete a task multiplied by the unit price, not as the cost of a single conversation. An agent task often involves many tool calls, so the cost structure is different from ordinary chat.

• Service stability and quota. Rate limits, timeouts, and availability zones can affect delivery more than the model itself when running tasks in batches.

Two additional points are often overlooked:

• Models are replaceable components. Mature agent frameworks can bring different models closer to a usable baseline through unified tool protocols, standardized context management, and unified error-retry mechanisms. This means model selection should focus more on how the model performs on your task distribution than on its general ranking.

• Use small-scale regression tests for the same task. Run 20 to 50 real tasks from your own business scenario through candidate models. Record completion rate, average number of rounds, number of human interventions, and token cost. Use data instead of intuition.

6. Four Common Mistakes

Mistake 1: Assigning one huge task at once. Instructions such as “Refactor this entire system” often lead the agent to get lost midway. The better approach is to break the work into small tasks that can be independently verified and close them one by one.

Mistake 2: Giving a goal but no acceptance criteria. A model cannot prove its own correctness by itself. Executable checks, such as tests, compilation, or script comparisons, are needed to verify the result.

Mistake 3: Granting full permissions by default for smoother execution. The greater the permissions, the larger the potential damage from a single mistake. A reasonable approach is to start with read-only permissions, expand gradually, and require human confirmation for irreversible operations.

Mistake 4: Blaming the model for engineering problems. Incomplete context, vague tool descriptions, messy directory structures, and missing verifiable tests can all make the model appear less intelligent than it actually is.

7. Safety and Control: Four Baseline Rules for Deploying Agents

1. Least privilege. Grant only the directory and interface permissions required to complete the task. Keep write permissions as narrow as possible.

2. Isolated execution. Run command execution and code execution in containers or temporary workspaces whenever possible. Avoid operating directly in the main working environment.

3. Treat instructions in external content as data, not commands. Web pages, documents, and issues may contain content such as “ignore previous instructions.” Such content should be treated as data rather than instructions. In enterprise settings, pay attention to the risk of sensitive data being sent externally.

4. Maintain full traceability. Record task inputs, tool-call parameters, returned results, and duration. This is useful for review and is often the only evidence available when something goes wrong.

In team or enterprise scenarios, this foundation is usually assembled from general cloud capabilities rather than built from scratch. Model services, container platforms, object storage, logging services, and monitoring and alerting capabilities can be combined into a usable execution environment and observability system. Platforms such as Baidu AI Cloud may be considered depending on the organization’s cloud environment. For specific features and integration methods, refer to the official documentation rather than copying configurations from third-party tutorials.

8. A Practical Path for Adoption

• Week 1: Read-only tasks only. Let the agent read code, explain errors, and compare solution options. Do not grant any write permissions.

• Weeks 2 to 3: Small, well-bounded changes. Give it small tasks with clear boundaries and supporting test cases. Review the diff yourself after each change.

• Month 1: Turn frequent repetitive workflows into reusable task templates. Define inputs, constraints, and acceptance criteria clearly.

• Afterwards: Expand gradually. Consider involving the agent in cross-module changes and automation pipelines, while gradually adding audit and quota controls.

9. Conclusion

The question “Who are you?” is worth asking once, but it does not need to be asked twice. It confirms that the conversation has started, but it does not produce any deliverable by itself.

The real turning point is shifting from “What can you do?” to “What result do I need, how far are you allowed to go, and how will the result be verified?”

Once the six-layer structure of an agent is understood, the optimization order also becomes clear: first improve context and task descriptions, then adjust permissions and acceptance criteria, and only then consider changing the model.

The capabilities of a tool are given, but the limits of how it can be used are in the user’s hands. This shift often brings a more noticeable efficiency improvement than any single model upgrade.