How to Engineer Trustworthy AI Agents: Execution Control, Safety Boundaries, and Multi‑Agent Collaboration

The session began by framing the fundamental shift from building a flashy demo to deploying an agent that can safely act in real‑world environments such as mobile devices, enterprise clouds, or customer workflows. The hosts emphasized that the problem changes from "can it run?" to "will it cause accidents?" and introduced the concept of Harness Engineering as the infrastructure that makes agents trustworthy, auditable, and recoverable.

First guard – sandbox vs. permission boundary : When asked which protection to implement first, both guests agreed that the choice depends on the scenario but that production systems need both. OPPO’s perspective highlighted the difficulty of fully sandboxing mobile GUI agents because device APIs, permissions, and UI elements are tightly coupled to hardware. Their solution is a layered permission check—sensitive page detection, intent validation, and risk assessment at action generation. Tencent Cloud argued that in cloud environments sandboxing and permission boundaries are inseparable: sandboxing isolates execution, while permission checks constrain business impact. Without both, high‑risk operations like deleting instances remain vulnerable.

"Strict then lenient" checkpoint policy : The panel stressed that too few interruptions are dangerous, but excessive interruptions erode safety. Checkpoints should cover three categories: irreversible operations (e.g., payments, deletions), incomplete intents (e.g., missing order details), and conflicting execution paths (e.g., ticket sold out). They warned against fixed‑interval interruptions; instead, checkpoints should be risk‑aware, combining confidence scores, historical preferences, and business constraints.

Rollback challenges : Both speakers agreed that rollback is one of the hardest engineering problems for agents. In cloud APIs, rollback can rely on declarative systems like Kubernetes that reconcile desired state. In GUI contexts, actions are not transactional; agents must perform step‑wise compensation (e.g., removing an item from a cart) because a simple "back" button cannot revert state changes.

Tool‑call safety : The discussion moved to the danger of chaining individually legal tool calls into hazardous sequences. The recommendation is to audit at the workflow level, tightening permissions for read‑only operations while requiring secondary confirmation, manual approval, or audit trails for write‑heavy actions such as configuration changes or bulk deletions.

Human‑in‑the‑loop (HITL) : Agents should allow users to "grab the steering wheel" at any time, treating manual takeover as a regular design feature rather than an exception. Mobile agents must detect environment changes (e.g., UI redesign, out‑of‑stock items) and pause for user clarification. Enterprise systems also need HITL for compliance, especially for actions involving permissions, billing, or resource destruction.

Multi‑agent coordination : The panel cautioned against naive multi‑agent designs that give each agent independent decision‑making power. Instead, they advocated a central brain that handles planning and intent judgment, with subordinate agents acting as specialized executors (coder, reviewer, tester). For programming scenarios, they suggested isolating each agent’s workspace using git worktree and merging results later to keep boundaries clear.

Evaluation, observability, and error attribution : A three‑layered approach—offline benchmarks, online telemetry, and error attribution—was proposed. Offline tests must evolve with UI and API changes, while online logs should capture prompts, tool parameters, results, error codes, and latency via standards like OpenTelemetry. Success metrics should include task completion rate, interaction burden, safety incidents, and stability, not just raw success percentage.

Memory and experience : The final segment highlighted the need for both short‑term context compression and long‑term experience retention. Critical debugging information (error codes, key nodes, failure reasons) must be preserved even when context windows shrink. Agents should also record failed GUI paths, mis‑invoked skills, and manual corrections as reusable experience, turning the system into a seasoned assistant rather than a reset‑on‑each‑run novice.

In conclusion, the experts agreed that Harness Engineering will remain essential even as models become more capable, because real‑world deployment involves permissions, compliance, exception handling, and user preferences that raw model intelligence cannot guarantee. Trustworthy agents are those that know when to act, when to pause, when to ask for help, and when to roll back.