Resident Office Agents: Always-On Automation for Daily Administrative Work

1. Problem Definition: Why We Need “Work Done While the Computer Is Off”

Traditional office automation mostly stays at the stage of “a person opens software, clicks a button, and triggers a script.” Execution depends on the local terminal being online. When the computer shuts down, the network switches, or the user walks away, long-running workflows are interrupted. Daily administrative work, however, often has three characteristics: it spans multiple systems, involves long chains of steps, and contains sensitive data. For example, finding the invoice corresponding to a business transaction, drafting a payment reminder email based on the aging schedule, or preparing materials for a contract to be signed are never single actions. They require searching, comparing, generating, and confirming across a finance system, an email service, and a contract management module.

“Working for you 24/7 while your computer is off” does not mean keeping the local machine running non-stop. It means moving the execution engine to a cloud-based or remote always-on environment, where the local terminal only serves as the entry point for initiating, approving, and viewing results. The technical core is not a chat interface, but a persistent, recoverable, and auditable task execution system: task state is stored in a database, execution actions go through a controlled tool adaptation layer, sensitive operations enter a human approval queue, and failed tasks are retried based on policy or escalated to humans. Industry discussions around this capability are shifting from “intelligent assistants” to “resident office agents.”

2. Reference Architecture: Six Layers for Persistent Execution

A practical resident office agent typically consists of six layers:

1. Ingress layer: Receives task requests from common entry points such as email, forms, instant messages, and business system events. It performs identity verification and task registration only, and does not directly execute high-risk actions.
2. Orchestration layer: Handles task decomposition, state machine progression, timeout control, retry policies, breakpoint resumption, and human intervention. It decides “what to do first, when to do it, and what to do when it fails.”
3. Tool adaptation layer: Encapsulates capabilities from the finance system, email service, contract management module, etc., into unified tools. Controlled APIs are preferred; browser automation may be used as a supplement when necessary. Tool descriptions must include input constraints, output structure, risk level, and whether the operation is rollbackable.
4. Cognition and document processing layer: Uses large language models, rule engines, and document parsing to handle intent understanding, field extraction, summarization, draft generation, and consistency validation. Model outputs should be as structured as possible and must not hold long-lived credentials directly.
5. Security and governance layer: Enforces least privilege, short-lived credentials, field-level masking, sandboxed execution, approval policies, immutable audit logs, and compensation/rollback mechanisms.
6. Runtime infrastructure layer: Relies on common cloud infrastructure such as container platforms, message queues, object storage, databases, logging services, and monitoring/alerting to host the resident execution engine. A deployment might use a generic cloud environment (e.g., Baidu AI Cloud), but the architecture itself should remain neutral and not be tightly coupled to a specific execution environment.

The key point of this architecture is the separation of “cognition” and “execution”: models are responsible for understanding and generating intent, while the executor is responsible for calling tools according to policy. Models cannot obtain unlimited system access; all write operations must pass through policy validation.

3. Three Typical Workflows: Invoice Retrieval, Payment Reminder Emails, and Contract Preparation

Invoice retrieval is a read-only retrieval task. After triggering, the orchestration layer first generates a search plan based on conditions such as business transaction number, time range, and amount. It then queries the finance system through the tool adaptation layer, extracts fields such as invoice number, issue date, amount, and status, and performs a consistency check with the business document. The result should include source location and an evidence chain, for example, “from row X of page Y in finance record Z,” rather than returning only a natural-language conclusion. If there is a conflict in amount or status, the task is escalated for human review.

Payment reminder email drafting is a “read-heavy, write-light” task. The system first retrieves aging data, outstanding balances, and historical communication records, then generates an email draft. The draft must contain checkable fields and a view of discrepancies. By default, only a draft is created; it is not sent directly. Sending is marked as a high-risk action and requires human approval or satisfaction of preset rules—for example, if the amount is below a threshold and the customer status is normal, automatic sending is allowed; otherwise, the task enters an approval queue.

Contract preparation for signature is a cross-system assembly task. The system prepares a signing package based on the contract template, business information, and approval records. It checks mandatory fields, attachment completeness, and version consistency, then generates a signing checklist. Actions such as submitting the contract or initiating signing must require approval, and before/after snapshots must be preserved to ensure reversibility and traceability.

4. Breakpoint Resume: The Core Mechanism for Persistent Execution

A resident agent must assume that any step can fail: API timeouts, missing fields, expired permissions, or delayed human approvals. Therefore, a task cannot be implemented as one long function running from start to finish. It must be designed as a state machine, with each step persisting a checkpoint after completion. When the task is resumed, it continues from the most recent checkpoint rather than re-executing all actions. For write operations, idempotency keys and deduplication records must be used to avoid duplicate email sends or duplicate contract submissions.

Illustrative pseudocode is shown below:

task = {
  "id": "task-001",
  "type": "invoice_lookup",
  "state": "PENDING",
  "steps": [...],
  "checkpoint": {...},
  "policy": {
    "read_only": true,
    "require_approval": ["send_email", "submit_contract"]
  }
}
while task.state not in ["DONE", "FAILED", "CANCELLED"]:
    step = next_step(task)
    if step.requires_approval and not approved(task, step):
        task.state = "WAITING_APPROVAL"
        persist(task)
        break
    result = execute_with_sandbox(step, short_lived_credential(task))
    task.checkpoint = merge(task.checkpoint, result.evidence)
    task.state = advance(task, result)
    persist(task)

Policy configuration should also be explicit, to avoid scattering security rules across the codebase:

policy:
  data_scope: finance_invoices_only
  write_actions:
    - create_email_draft
    - prepare_contract_package
  require_approval:
    - send_email
    - submit_contract
  audit: immutable_log
  rollback: snapshot_before_write

5. Security and Compliance: Automatic Execution Must Be Controllable

Resident agents handle highly sensitive information such as finance, contracts, and customer communications. The principle of least privilege must be applied: tasks receive only the short-lived credentials needed for the current step, and these credentials expire automatically; models see only the masked fields necessary for their work; write operations execute in a sandbox with before/after snapshots recorded; audit logs are immutable and support retrieval by task, operator, time, and data object. For actions such as email sending, contract submission, or amount modification, approval thresholds, dual-person review, or discrepancy confirmation should be set. The system should also provide one-click revocation or compensation flows, such as withdrawing a draft, invalidating a signing package, or generating a correction record.

6. Human-in-the-Loop and Observability

“Resident” does not mean “unattended.” A proper human-in-the-loop interface includes an approval queue, confidence thresholds, discrepancy views, task timelines, and failure reason classification. Observability metrics should cover task success rate, human intervention rate, average processing time, failure retry count, audit coverage, and sensitive-action blocking rate. Before going live, historical tasks should be replayed in a sandbox. The rollout should be phased: read-only first, then writes; single system first, then cross-system; drafts first, then sending—gradually expanding the scope. Through canary releases and offline evaluation, automated execution can improve efficiency while remaining explainable, auditable, and rollbackable.