Agentic Systems: Architecture, Implementation, and Governance Practices

1. Fundamental Definition of Agentic Systems

Agentic systems are software systems capable of understanding goals, decomposing tasks, invoking external tools, and continuously adjusting their plans based on execution results. Unlike traditional Q&A applications, an agent does more than generate text; it completes a series of continuous actions around a specific goal, such as reading materials, extracting information, creating tasks, operating business systems, generating reports, and submitting approvals.

A complete agent typically comprises five core capabilities:

1. Goal Understanding: Translating natural language requirements into executable tasks.
2. Task Planning: Breaking down complex goals into multiple interdependent steps.
3. Tool Invocation: Executing external actions via APIs, functions, browsers, or desktop operations.
4. State Memory: Saving task context, historical results, and user preferences.
5. Result Validation: Determining execution success and performing retries, rollbacks, or requesting human intervention if necessary.

Therefore, the focus of an agent is not just the model itself, but the system engineering comprising the model, tools, data, permissions, and runtime environment.

2. Typical System Architecture

Enterprise-level agents can adopt a layered architecture to reduce module coupling and facilitate future scaling.

2.1 Interaction Layer

The interaction layer receives user instructions and returns execution results. Entry points can be web pages, mobile apps, office collaboration tools, or internal business systems. The interaction layer should clearly display task statuses, such as “Waiting for Confirmation,” “Reading Materials,” “Execution Failed,” or “Completed,” preventing users from assuming the system is unresponsive.

For high-risk operations, the interaction layer should incorporate a confirmation mechanism. For instance, before an agent deletes data, sends external notifications, or submits financial approvals, it should present the operation details, impact scope, and target objects to the user for confirmation before execution.

2.2 Task Orchestration Layer

The task orchestration layer is the control center of the agent, managing the task lifecycle. Common workflows include:

• Receiving the goal and identifying the task type;
• Generating an execution plan;
• Selecting appropriate tools for each step;
• Recording inputs, outputs, and intermediate states;
• Deciding to continue, retry, or terminate based on results;
• Aggregating results and generating a readable report.

Complex tasks should not rely entirely on a one-shot generated plan. A more robust approach is adopting a “Plan-Execute-Observe-Adjust” loop. After each step, the system should re-evaluate subsequent actions based on real results.

2.3 Model Inference Layer

The model inference layer is responsible for semantic understanding, plan generation, tool selection, and result interpretation. To improve stability, model outputs should be constrained to structured formats, such as returning task steps, tool names, parameters, expected results, and failure handling methods, rather than outputting unverified natural language directly.

Additionally, different types of model calls should be distinguished:

• Fast Calls: For classification, information extraction, and simple judgments;
• Deep Calls: For complex planning, long document analysis, and exception handling;
• Validation Calls: For checking if results comply with business rules.

This division reduces latency and costs, and minimizes resource waste caused by using high-complexity reasoning for all tasks.

2.4 Tool Execution Layer

The tool execution layer connects internal enterprise systems and external capabilities, including database queries, file processing, message sending, search services, workflow approvals, computational tasks, and browser or desktop operations.

Tool design should follow three principles:

• Single Responsibility: One tool completes one clear action;
• Clear Parameters: Input fields, types, required fields, and constraints must be explicit;
• Verifiable Results: Return structured status, error information, and necessary context.

For example, a “Submit Approval” tool should not just return “Success” or “Failure”; it should also return the submission ID, current status, target workflow, and timestamp for subsequent tracking by the agent.

3. Long-Task Processing and State Management

When executing complex tasks, agents might run for tens of minutes or longer. Relying solely on the current conversational context can lead to information loss, redundant execution, and goal drift.

3.1 Short-Term Context

Short-term context is used to retain key content within the current task, such as the user’s goal, completed steps, pending items, and the most recent tool return results. Context should be periodically compressed, retaining only information valuable for subsequent decisions to prevent irrelevant content from continuously occupying the reasoning space.

3.2 Long-Term Memory

Long-term memory is suitable for storing stable information, such as user preferences, departmental rules, common workflows, and historical task summaries. However, memory cannot be written unconditionally; it must undergo filtering, classification, and permission checks.

It is recommended to categorize memory into:

• User-level memory;
• Team-level memory;
• Business-level knowledge;
• Temporary task states.

Different types of memory should have varying retention periods. Sensitive information must also support deletion, modification, and auditing.

3.3 Checkpoint and Resumption

Long tasks should employ persistent state recording. After completing each critical step, save the task progress, tool results, and next-step plan. If the service restarts or the network drops, execution can continue from the most recent safe checkpoint rather than starting over.

A schematic workflow is as follows:

Receive task
  ↓
Generate plan and save
  ↓
Execute step 1 and record result
  ↓
Validate step 1
  ├─ Success: Proceed to step 2
  ├─ Retryable: Perform limited retries
  └─ High risk or unknown: Pause and request manual confirmation

4. Implementation Boundaries of Computer Operation Capabilities

Some agents can perform computer operations through screen recognition, mouse and keyboard control, or browser automation. These capabilities are suitable for handling legacy systems lacking standard APIs, but the risks are significantly higher than standard function calls.

Implementation should focus on:

1. Operation Scope Limitation: Allow access only to specified windows, directories, and business systems.
2. Sensitive Action Interception: Operations like deletion, fund transfers, batch modifications, and external data transmission must require secondary confirmation.
3. Visual Result Validation: Do not judge success solely by click actions; read page states or generate screenshot evidence.
4. Timeout and Rollback: Stop subsequent actions during page loading anomalies, element changes, or network failures.
5. Comprehensive Auditing: Record operation timestamps, target pages, executed actions, and final results.

Computer operations are suitable for assisting human workers and should not directly undertake high-value production tasks without permission isolation and result validation.

5. Plugin-based Extension and Enterprise Workflows

Plugin-based design can encapsulate general reasoning capabilities into reusable toolkits. A plugin typically includes tool definitions, input constraints, execution logic, permission declarations, and error handling rules.

For instance, an HR-focused plugin can handle candidate profile organization, interview scheduling, and statistical aggregation; an operations plugin can perform data queries, daily report generation, and anomaly alerts; a design team plugin can manage asset archiving, requirement organization, and version note generation.

The plugin system must establish unified standards:

• Consistent tool naming and parameter formats;
• Plugins possess only minimum necessary permissions;
• Every call generates an audit record;
• Plugin version changes are traceable and rollbackable;
• Clear boundaries for external data transmission;
• Plugin exceptions must not affect core task scheduling.

For enterprise users, the value of plugins lies not in quantity, but in whether they can be stably embedded into existing workflows with clear accountability boundaries.

6. Cloud Deployment and Large-Scale Execution

When enterprises need to run a large number of agent tasks, they should adopt cloud-hosted approaches to centrally manage compute resources, task queues, storage, and monitoring.

Typical deployment components include:

• Task Queues: Peak shaving to prevent massive tasks from overwhelming models and business systems simultaneously;
• Container Runtime Environments: Isolating dependencies and permissions for different tasks;
• Object Storage: Saving documents, screenshots, task artifacts, and intermediate files;
• Databases: Recording task states, user configurations, and audit information;
• Logging and Monitoring Systems: Tracing call chains, error rates, latency, and resource usage;
• Key Management Systems: Centrally storing access credentials and controlling usage scope.

At scale, monitoring should not focus solely on the number of model calls. It should also track task success rates, human takeover rates, average completion time, duplicate execution ratios, and cost per task. These metrics better reflect whether the agent genuinely improves production efficiency.

7. Security, Permissions, and Compliance Governance

Once agents possess execution capabilities, security concerns expand from “information leakage” to “erroneous operations.” Therefore, security design should cover the entire process: input, inference, tools, and output.

7.1 Input Security

Conduct content detection on user inputs, uploaded files, and external web content to prevent malicious instructions from inducing the agent into unauthorized execution.

7.2 Permission Security

Adopt the principle of least privilege, separating read, modify, delete, and external send permissions. Different users, departments, and task types should use different permission configurations.

7.3 Data Security

Sensitive data should be classified and graded, with masking applied when necessary. Unnecessary private information should not be retained long-term in model context, logs, and caches.

7.4 Output Security

Apply rule validation to generated content and tool results. Especially in scenarios involving financial amounts, contracts, personal information, and external communications, manual review nodes should be set up.

8. Fault Recovery and Service Continuity

Agent systems can be affected by model unavailability, network fluctuations, tool exceptions, data source changes, or infrastructure failures. A reliable system should feature the following mechanisms:

• Limited retries with progressive delays;
• Tool call timeouts and circuit breakers;
• Checkpoint saving for critical tasks;
• Multi-node or multi-region disaster recovery;
• Routing failed tasks to manual processing queues;
• Idempotency for important operations to prevent duplicate submissions;
• Regular fault drills.

It is particularly crucial to prevent “runaway automatic retries.” If the system cannot determine the cause of failure, continuing to execute may cause duplicate orders, duplicate messages, or data pollution. In such cases, the task should be paused for human confirmation.

9. Effectiveness Evaluation Methods

Agents cannot be evaluated solely by the fluency of their responses. It is recommended to establish a metric system across four dimensions:

1. Accuracy: Whether task results comply with business rules;
2. Completion Rate: Whether tasks can be completed without intervention or with minimal intervention;
3. Efficiency: Whether time consumption, manual steps, and resource usage decrease;
4. Security: Whether unauthorized access, misoperations, and sensitive data exposure are controllable.

Before launch, testing should be conducted using real but desensitized task sets, covering normal, boundary, exception, and malicious scenarios. Post-launch, continuously collect failure cases and convert them into rules, test samples, or tool improvement items, forming a closed loop.

10. Implementation Recommendations

Enterprises should not pursue full autonomy from the very beginning when building agents. A more robust path is:

1. Select scenarios with stable workflows, clear rules, and controllable risks;
2. Start with information organization and assisted decision-making, then gradually open up execution permissions;
3. Prioritize building standardized tools rather than stacking complex prompts;
4. Design confirmation, auditing, and rollback mechanisms for every critical action;
5. Validate benefits through small-scale pilot runs before expanding the task scope;
6. Manage models, tools, data, and permissions in layers to prevent the system from becoming unmaintainable.

Overall, the core value of an agent lies in transforming natural language goals into executable processes while continuously perceiving, judging, and adjusting during execution. A truly mature system is not one that “can do anything,” but one that stably completes high-frequency, complex tasks with actual business value under clear boundaries, controllable permissions, and auditable workflows.