Harness Engineering: Execution Control, Safety Boundaries, Human‑AI Collaboration, and Multi‑Agent Design

Guardrails: Sandbox vs. Permission Boundary

Both experts agreed that in production environments a sandbox and a permission boundary are indispensable, but the emphasis differs by scenario.

Mobile GUI agents (OPPO) : Full sandboxing is difficult because device accounts, system APIs, and UI are tightly coupled to the hardware. OPPO implements layered permission checks: the client first detects sensitive pages, the agent performs intent verification during planning, and a risk check is applied after action generation.

Enterprise cloud agents (Tencent Cloud) : Sandbox isolates execution, while permission boundaries limit business impact. Both are required to prevent accidental deletions, VM rebuilds, or network‑policy changes.

"First Strict Then Lenient" Policy

Permissions are tightened by default and relaxed only after concrete needs are verified. The approach mirrors a firewall’s default‑deny rule: irreversible operations must never rely on the assumption that the model will not err.

Checkpoint Design

Checkpoints answer when a human must be notified. Three categories were identified:

Irreversible operations (e.g., payment, deletion, authorization).

Incomplete intents (e.g., ordering a latte without size or store).

Conflicting execution paths (e.g., booking a ticket that is already sold out).

Too few interruptions risk unsafe actions; too many cause confirmation fatigue. A risk‑level approach was suggested: high‑risk actions require manual confirmation, low‑risk actions may auto‑retry, and medium‑risk actions are judged dynamically based on context, confidence, and business constraints.

Rollback Challenges

Rollback is one of the hardest engineering problems for agents.

API‑level rollback : Straightforward when the underlying system is declarative (e.g., Kubernetes). Desired state can be reapplied to revert changes.

Stateful services : Require snapshots, backups, compensating transactions, or manual intervention.

GUI rollback : UI actions are not transactional. Step‑wise compensation and "step‑level rollback" are needed to restore previous UI state.

Tool‑Call Safety

Legal individual tool calls can combine into dangerous outcomes. Audit must operate at the task level, not just per‑API. Read‑only queries may be liberal, but any configuration change, resource deletion, or bulk operation should trigger stricter validation, secondary confirmation, or human approval.

Human‑in‑the‑Loop (HITL)

Users must be able to intervene at any moment, analogous to grabbing a steering wheel. Mobile agents should detect environment changes (page redesign, missing button, out‑of‑stock item) and proactively request help instead of proceeding blindly. In enterprise settings, HITL also satisfies compliance for privileged actions such as billing or resource destruction.

Multi‑Agent Coordination

Unrestricted collaboration leads to decision conflicts and state races. The preferred architecture is "one brain, many hands": a central agent makes planning and intent decisions, while peripheral agents execute specific roles.

Isolation of each agent’s workspace (e.g., using git worktree) and merging results later keeps boundaries clear.

Evaluation, Observation, and Error Attribution

A three‑pronged reliability stack was recommended:

Offline benchmarks that are refreshed as UI or APIs evolve.

Online telemetry that records every prompt, tool parameter, result, error code, and latency. Standards such as OpenTelemetry can be used to build an auditable call log.

Error attribution to trace failures back to specific components.

GUI agent evaluation should measure task success, interruption frequency, safety violations, and user burden.

Memory and Experience Management

Context length cannot grow indefinitely. Once a threshold is reached, compression must retain critical debugging information (error codes, key nodes, failure reasons, user preferences).

Experience accumulation means persisting every failure path, skill‑recall mistake, or manual correction as long‑term knowledge, turning the agent into a seasoned assistant rather than a reset‑on‑each‑run novice.

Conclusion

Even as models become more capable, Harness Engineering remains essential because real‑world systems involve permissions, business rules, compliance, exceptions, user preferences, and organizational processes that raw inference cannot guarantee. Engineering the boundaries that separate model intelligence from production reality makes agents safe enough for deployment.