From AI Agents to Task Delivery: Engineering AI Applications for Production

In the “People’s Park Talks AI” discussion, the most important question is not whether one particular model is stronger. It is that AI applications are moving from “answering questions” to “completing tasks.”

In the past, users mostly treated large language models as a chat window: ask a question, follow up, summarize, rewrite, or generate a code snippet. Today, more and more scenarios require a model to understand a fairly complex goal and break it down into multiple steps on its own. The model then calls tools, accesses data, performs operations, checks the results, and delivers a usable outcome.

This shift changes how AI systems are evaluated. The focus moves from “how fluent the answer is” to “whether the task is fully completed,” and from a race between individual model capabilities to competition across a complete engineering stack.

1. From Calling Models to Delivering Tasks

Traditional AI applications typically involve single-turn or short multi-turn interactions: the user enters some text, and the model returns a result. Their value depends on the model’s own language understanding, knowledge coverage, and generation quality.

That approach falls short when use cases expand to complex tasks such as data analysis, document processing, code generation, operations troubleshooting, workflow automation, and content production. Real tasks usually involve multiple steps, multiple tools, multiple data sources, and multiple roles working together.

For example, “Help me finish the quarterly business analysis report” is not just about writing a summary. It involves at least the following steps:

1. Clarify the analysis objective: is it for management or frontline staff, and is the focus growth, cost, risk, or conversion?
2. Retrieve data: read from the business database, report files, logging systems, or object storage.
3. Clean the data: handle missing values, outliers, duplicate records, and time range issues.
4. Analyze metrics: calculate year-over-year and month-over-month changes, trends, segment contributions, and abnormal fluctuations.
5. Draw conclusions: identify business problems and offer actionable recommendations.
6. Validate the results: check data definitions, calculation formulas, and whether the conclusions are consistent with the data.
7. Produce deliverables: generate documents, charts, slides, meeting notes, or follow-up tasks.

In this process, the model is only one link in the task execution chain. A working system also needs task orchestration, access control, tool invocation, result validation, logging, cost budgets, and security auditing. In other words, AI applications are evolving from a model API into an agentic workflow.

2. The Risks of Relying on a Single Top-Tier Model

Model capabilities keep improving, but another problem is becoming increasingly clear: depending solely on one top-tier closed-source model is not a good foundation for long-term, stable production infrastructure.

The reason is not just model capability. Enterprise applications also have to account for cost, stability, compliance, replaceability, data security, and service continuity.

First, the cost of model calls is hard to control. Complex agent tasks often involve multiple rounds of reasoning, repeated tool calls, long context reads, and repeated validation. If every task calls a high-capability model directly, token consumption rises quickly. A request that looks like a simple business query may trigger more than ten model calls behind the scenes. Without budget controls, call limits, and cost attribution, bills can easily get out of hand.

Second, data boundaries are unclear. Enterprise data often includes sensitive content such as user information, business records, source code, and contract text. Sending all of it directly to an external model service requires data masking, permission isolation, access auditing, and compliance measures. This is especially important in industries such as finance, healthcare, government, and energy.

Third, service stability is a risk. A production system should not break down entirely because one model service is rate-limited, upgraded, has its policies changed, or becomes unavailable. A better approach is to avoid locking into a single model. Instead, build a unified model access layer that supports multi-model routing, fallback switching, canary releases, and fault isolation.

Fourth, capability boundaries are not transparent. Different models have different strengths in reasoning, code generation, long-form text, structured output, tool calling, and multimodal understanding. Without standardized evaluation sets and task benchmarks, developers tend to pick models by gut feeling. The result is inconsistent quality, wasted spend, and fluctuating user experience.

What enterprises really need is not “whichever model works best,” but an AI application stack built around models that is controllable, observable, and well governed.

3. The Agent Execution Loop: Tasks, Permissions, Tools, and Audit

A mature agent system should not just “take a prompt and return an answer.” It should form a complete execution loop, which can usually be broken down into the following modules:

1. Task entry layer: receives the user request and determines the task type, priority, budget range, data permissions, and expected form of delivery. For example, if a user asks to “generate this week’s operations report,” the system must first recognize this as a data analysis task, not an ordinary Q&A request.
2. Planning and orchestration layer: breaks complex tasks into executable steps, such as:
   • Retrieve this week’s core metrics.
   • Compare them with last week’s data.
   • Identify abnormal metrics.
   • Generate hypotheses about the causes.
   • Produce a draft report.
   • Request human confirmation.
3. Permission check layer: every step must have its permissions verified before it runs. The model can propose a plan, but it should not automatically hold top-level access to every system. Tool calls must follow the principle of least privilege.
4. Tool execution layer: includes database queries, file reads and writes, search, spreadsheet calculations, code execution, API calls, and message notifications. Tools should run in a controlled environment to prevent unauthorized access and uncontrolled side effects.
5. Result validation layer: checks model output for format, factual accuracy, rule compliance, and consistency. For example, monetary fields must be numeric, date ranges must be valid, and conclusions must not go beyond what the data supports.
6. Audit logging layer: records who started which task under what permissions, which tools were called, how many resources were consumed, and what results were produced. These logs are essential for post-incident reviews, accountability, and optimization.
7. Human confirmation layer: high-risk actions such as deleting data, changing production configurations, sending external emails, confirming payments, and merging code into the main branch should not be fully automated. They need a human confirmation step.

The following pseudocode outlines a basic execution loop:

def execute_ai_task(user_input, context):
    # 1. Parse the task objective and budget
    task = parse_task(user_input, context)
    budget = get_budget(task)
    # 2. Generate the execution plan
    plan = planner.generate_plan(task)
    # 3. Security and permission checks
    if not security_check(plan, context):
        raise PermissionError("The task plan failed the security check")
    # 4. Execute step by step
    results = []
    for step in plan:
        if budget.remain_cost <= 0:
            break
        # Re-check permissions before execution
        check_permission(step, context)
        result = executor.run(step)
        # Log the audit record and resource usage
        log_audit(task, step, result)
        budget.consume(step.estimated_cost)
        # Validate critical steps
        if step.requires_review:
            result = human_review(result)
        results.append(result)
    # 5. Produce and archive the final output
    final_output = verifier.verify(results)
    archive(task, final_output)
    return final_output

The point of this code is not the specific interfaces it uses. It shows that the core of an agent system is not letting the model act freely, but running tasks reliably within defined boundaries, budgets, permissions, and audit trails.

4. Controlling Token Costs: From Call Freely to Schedule on Demand

When discussing AI applications, many people focus on “what the model can do” and overlook “what it costs to do it.” For agent tasks, the cost is rarely that of a single Q&A turn. It is the total cost of an entire task chain. A complex task may involve planning, tool calls, result validation, retries after failures, and context summarization. Each step consumes tokens and compute resources.

There are several practical ways to reduce AI application costs:

1. Classify tasks by complexity: not every task needs a high-capability model. Lightweight models can handle simple Q&A, format conversion, and classification or extraction. Reserve high-capability models for complex reasoning, code generation, and long-document analysis. Routing tasks by level can significantly lower average costs.
2. Cache results: use semantic caching for frequently asked questions. When many users ask about the same policy, the summary of the same document, or the cause of the same code error, the system can reuse a previously verified result instead of reasoning again from scratch.
3. Batch and asynchronous processing: non-real-time tasks can be processed in batches to reduce peak-time load on model calls. Examples include generating reports overnight, cleaning documents in bulk, and running offline code scans, all of which can be handled asynchronously through queues.
4. Compress context: long documents, multi-turn conversations, and tool outputs can quickly bloat the context. Use summarization, key information extraction, and chunked retrieval so that only the necessary information reaches the model.
5. Cap retries: tool calls from agents can fail. Without limits, the model may get stuck retrying in a loop and waste resources. Set maximum rounds, maximum duration, maximum token budgets, and a circuit breaker for errors.
6. Attribute costs: call costs should be traceable by team, application, and user. Only when costs can be attributed can you set budgets, allocate quotas, and make informed optimization decisions.

From Baidu AI Cloud’s engineering perspective, AI applications can rely on general-purpose cloud capabilities:

• Object storage for input and output files
• Message queues for asynchronous tasks
• Container platforms for deploying execution services
• Log services for tracing the call chain
• Monitoring and alerting for tracking resource usage and unusual spikes

Together, these capabilities support a stable, controllable AI production environment.

5. GUIs Will Not Disappear, but They Will Move to the Background

The claim that “the GUI is dead” is not accurate. A more reasonable view is that traditional graphical interfaces are shifting from the main entry point for user actions to the entry point for viewing and monitoring task results.

Users used to open software, click through menus, fill in forms, switch between pages, copy data, and run scripts themselves. In an agent-based model, the user simply describes the goal. For example: “Tidy up this week’s sales data, identify underperforming stores, generate a report, and send it to the person in charge.” The system then retrieves the data, analyzes it, generates the document, and sends the notification automatically. Users may still see an interface, but it mainly shows task progress, permission confirmations, result previews, and error alerts. It no longer requires them to perform every step manually.

This means the focus of next-generation software interaction is no longer page layout, but the ability to delegate tasks. Enterprises need to rethink their system boundaries and answer questions such as:

• Which operations can the model understand?
• Which tools can be called safely?
• Which steps require human confirmation?
• Which data must not leave the internal network?
• Which results must be replayable and auditable?
• Which failures must trigger an automatic fallback?

For developers, the value of the GUI has not disappeared; it has been redefined. The GUI is changing from an operation interface into a governance interface. Through it, users check task status, approve high-risk actions, adjust execution strategies, review cost usage, and inspect audit records.

6. Natural-Language-Driven Development: Low Barrier Does Not Mean Low Standards

The original discussion refers to “vibe coding,” which can be described more broadly as natural-language-driven development. Developers describe requirements in natural language, and AI helps generate code, scripts, configuration, test cases, and documentation. This approach lowers the barrier to programming and lets business staff, operations staff, and product managers build prototypes quickly.

But a low barrier does not mean engineering standards can be skipped. In fact, once code is generated faster, quality governance becomes more important.

Natural-language-driven development should at least follow this process:

1. Clarify requirements: natural-language descriptions are often vague. “Build a data statistics page” is not enough. You need to define which metrics to track, where the data comes from, how often it refreshes, who can access it, how errors are handled, how results are displayed, and what performance is expected.
2. Produce verifiable specs: before the AI writes code, it is best to generate a task specification first. The specification should cover inputs, outputs, boundary conditions, exception paths, dependencies, and test cases.
3. Generate module by module: do not generate an entire system in one go. Build it piece by piece, including data models, the API layer, business logic, access checks, logging, and error handling.
4. Write automated tests first: for critical logic, generate test cases before the implementation code. This helps avoid problems where code “looks like it runs” but fails on edge cases.
5. Never skip code review: AI-generated code may contain security flaws, permission issues, performance problems, or violations of team conventions. It must go through human review or static analysis.
6. Use version control with rollback: AI-assisted development produces a large number of code changes. Every change must be traceable and reversible, with test records kept.

The following pseudocode shows a practical example:

def build_feature_from_natural_language(requirement):
    spec = clarify_requirement(requirement)
    tests = generate_tests(spec)
    code = generate_code(spec, tests)
    if static_check(code) != "pass":
        code = fix_issues(code)
    if run_tests(code, tests) != "pass":
        raise BuildError("The generated code failed the tests")
    review_record = code_review(code)
    deploy_if_approved(code, review_record)

The core of this workflow is simple: natural language expresses intent, and engineering systems ensure quality. Only when the two work together can AI-assisted programming move beyond experiments and into production.

7. Restructuring Organizational Capabilities: From Writing Prompts to Governing Tasks

As AI adoption matures, organizations need more than people who can write prompts. They also need people who can define tasks, design workflows, evaluate results, and control risks.

• Business users need task-decomposition skills. They should be able to break a vague request into clear steps, such as “first pull the data, then validate the fields, then draw conclusions, and finally confirm them with a human.”
• Developers need agent engineering skills. These include model integration, prompt management, tool wrapping, access control, cache design, retry handling, evaluation systems, log tracing, and cost control.
• Managers need to establish AI governance mechanisms that answer questions such as:
  • Which scenarios are allowed to run automatically?
  • Which scenarios require human review?
  • Which data must not be sent to models?
  • How is model output accepted or approved?
  • How is AI-generated code reviewed?
  • How are cost budgets allocated?
  • How is accountability handled when something goes wrong?
  • How are model upgrades rolled out gradually?
  • How are knowledge bases updated?
  • How are results measured?

It also helps to define three categories of core metrics:

1. Effectiveness metrics: task completion rate, first-pass rate, rate of manual edits, user satisfaction, and error rate.
2. Security metrics: number of unauthorized calls, alerts for sensitive data leaks, block rate for prohibited output, and confirmation rate for high-risk operations.
3. Cost metrics: average token consumption per task, average number of calls, average execution time, cache hit rate, and the cost of failed retries.

Only by putting effectiveness, security, and cost on the same governance dashboard can AI applications avoid the trap of being “impressive in demos but unusable in production.”

8. A Layered Architecture for Enterprise AI Applications

Based on the discussion above, enterprises can adopt a layered architecture when building AI applications.

Layer 1: Unified model access layer. This layer hides the differences between models and provides a common interface for calling, authentication, rate limiting, routing, fallback, and usage metering. Different tasks can be routed to different models according to their strengths, which avoids relying on a single point.

Layer 2: Task orchestration layer. This layer breaks user goals into steps and defines their execution order, dependencies, conditional branches, and human confirmation points. Complex tasks should not be handed to the model all at once. The orchestration layer should control how they are executed.

Layer 3: Tools and data layer. This layer wraps capabilities such as database queries, file reads, search, code execution, API calls, and notifications. Every tool should have clear permissions, parameter validation, timeouts, and audit records.

Layer 4: Knowledge management layer. This layer stores enterprise documents, business rules, coding standards, historical tickets, FAQs, and product documentation. The knowledge base needs version control, access control, update auditing, and retrieval evaluation.

Layer 5: Observability and governance layer. This layer includes logging, distributed tracing, monitoring and alerting, cost analysis, call statistics, anomaly alerts, and audit reports. For production-grade AI applications, there is no stability without observability.

Layer 6: Application interface layer. This layer provides interfaces for task progress, result previews, human approvals, permission requests, cost dashboards, and feedback on exceptions. The interface is no longer the only place to operate, but an entry point for governance.

Under this architecture, model capability is only one part. The assets an enterprise really accumulates are task templates, knowledge bases, evaluation sets, tool libraries, access control systems, cost models, and audit standards.

9. The Real Gap Between Individuals and Enterprises: Who Can Reuse AI Reliably

On the question of whether ordinary people can still use top-tier AI, the answer is not simply whether a given model is open to the public. What matters is whether individuals and organizations have engineering practices that let them reuse AI capabilities reliably.

Individuals can start with small tasks:

• Use AI to draft a weekly report outline, then check the facts manually.
• Use AI to organize meeting notes and automatically extract action items.
• Use AI to generate code snippets, then add tests.
• Use AI to analyze document structure, then confirm the conclusions manually.
• Use AI to write spreadsheet formulas, then verify the calculation logic.

The goal is not “full automation,” but a human-AI collaboration loop.

Businesses should start with scenarios that have clear boundaries, well-defined value, and manageable risk. Examples include:

• Internal document Q&A
• Ticket summarization
• Knowledge assistance for customer support
• Code review assistance
• Report generation
• Log anomaly analysis
• Test script generation
• Business process automation
• Knowledge base update reminders
• Turning meeting notes into action items

These scenarios usually share three characteristics: clear task boundaries, a manageable cost of errors, and results that humans can review. As templates, rules, and evaluation sets accumulate over time, AI becomes a tool teams can use every day, not just something that occasionally impresses.

10. Conclusion: AI Competition Enters the Engineering Phase

What “People’s Park Talks AI” really highlights is that AI applications have entered a new phase. Competition is no longer just about who has the largest models or the highest benchmark scores. It is about who can reliably turn model capability into business results.

Future AI systems need at least four capabilities:

1. Executable: able to complete multi-step tasks, not just chat.
2. Controllable: able to respect permissions, budgets, workflows, and security boundaries.
3. Observable: able to record, trace, replay, and audit every action.
4. Sustainable: able to keep iterating and improving while costs stay under control.

In this phase, the value developers provide is not simply calling a model, but designing reliable agent workflows. The value businesses provide is not chasing the latest product, but building their own AI engineering capabilities. Cloud platforms such as Baidu AI Cloud can provide general-purpose capabilities such as model services, object storage, message queues, container platforms, logging, monitoring and alerting, and access management. Even so, how well AI performs in practice still depends on how well a business governs its tasks, data, processes, and risks.

In one sentence: the next stage of AI applications is not “the model works for you,” but “you design a system that lets the model work safely.”