How to Build a Controlled Runtime for Enterprise Agents

1. Define What Completing a Task Means

Consider an illustrative service-ticket task, not a deployed client case: an employee selects an authorized ticket, the system reads approved service material and proposes a draft, then creates a follow-up after confirmation. Completion means the source system contains the correct task and ticket reference, not that the model says it succeeded. A draft-only pilot needs no message-sending or ticket-closing access.

Associate each task with its initiator, input version, approval object, tool actions and final result. Distinguish active work, approval waits, failures, cancellation and completion. A browser closing must not erase execution state. Before resuming, reconcile actions already performed. Cancellation stops pending work; correcting completed writes requires authorized business procedures.

2. Separate Harness, MCP and Skills

A Harness is the runtime that organizes a task: state, context, tools, iteration and cost limits, and handoff on exceptions. It does not replace business databases or authorization. Evaluate pause, timeout, versioning, recovery and verification behavior, not the number of tools in a demo. A conventional workflow may be simpler for fixed approval sequences.

MCP is one protocol for connecting tools and resources; a CLI or API can also expose capabilities. Skills describe task methods and constraints but cannot replace server authorization. Tools need input and output contracts, action scope and error semantics. A narrowly defined draft-task tool is easier to govern than arbitrary SQL or full administrator access. Verify business status, not just HTTP success.

3. When Execution Isolation Is Needed

Evaluate isolated execution for code, untrusted files or browser actions. Separate task or tenant storage and caches, limit compute, memory, time and outbound access, and avoid production credentials or broad file mounts. Containers are an implementation choice, not proof of safety; isolation depends on configuration, runtime, networks, mounts and maintenance. Some tasks need stronger isolation or must remain manual.

Define creation, use, pause, expiry and cleanup. Failures or disconnected users must not leave resources running indefinitely. Retain only authorized artifacts and necessary records for investigation. Revalidate identity and scope before resuming, rather than inheriting old credentials or approvals. Both managed and self-hosted options need data-location, quota, cleanup and migration plans.

4. Bind Authorization to a Specific Action

Access to one customer does not allow an agent's service account to read every customer. Enforce current identity, tenant, resource and action at execution time, with credentials held by a trusted backend and limited in scope and duration. Instructions inside files, pages or model output cannot elevate access. Valid parameters still require business-rule and authorization checks.

Approval should show the exact object, fields, recipient or amount and bind to a version. Recheck changes, revocation or resource-state updates before execution, obtaining fresh approval where needed. High-risk checks belong in the business execution layer. After timeouts, reconcile the source system before retrying, and use idempotency or manual handling where safe retry is unavailable.

5. Monitor Service Health and Task Outcomes

Latency, API errors, resource use and cost describe system health. Completion, human corrections, denied access and reconciliation describe task quality. Carry task identifiers across the entry point, models, tools and source systems. Apply redaction, access and retention controls. Diagnosis needs references, bounded parameters, results and versions, not unrestricted storage of sensitive inputs or private model reasoning.

Acceptance should test timeouts, rejected approvals, revoked users, exhausted budgets, duplicate events and runtime failures. Record expected actions, actual business state, evidence and ownership. Operators need a queue and enough context to take over safely. A successful model response with a failed business action is not task completion; partially completed workflows must not be blindly replayed.

On narrow screens, scroll horizontally to see all columns.

6. Define Cost, Ownership and Handover

Development covers task design, tool contracts, state, access, integrations, execution environments, testing and handover. Operating costs may include models, servers, isolated compute, storage, monitoring and maintenance. Estimate from workload, duration, concurrency and retention, not a model subscription alone. Identify reusable infrastructure and the remaining upgrade or support responsibilities.

Handover includes architecture and deployment documents, tool inventory, access matrix, environment configuration, task states, test samples, stop and recovery procedures, and limitations. Define asset and account ownership contractually; avoid dependence on developers' personal accounts. Begin with a sanitized workflow and desired result. International clients can use email or WhatsApp without sharing credentials or sensitive data.

Official information and scope of verification

Reference check date: 2026-10-06. Platform capabilities change with the version, the package, the area and the authority; information is used to describe technical capabilities and does not represent search volumes, the results of the customer in Sino-China or the original cooperative qualifications.

• Alibaba Technology: AI Native Engineering Handbook (external reference, not a ZhiHua case study)