Building a HarmonyOS Agent Workbench That Shows Intent, Not Chat
Most Agent integrations on mobile start with a chat box that hides the model's decision-making. Exposing intent, tool selection, and failure context inline turns the UI into a debugging surface, which is what teams actually need during integration before they can trust an Agent with real tasks.
A new Agent workbench built with ArkUI and a local Gateway shifts the HarmonyOS interaction model from conversation to task orchestration. Instead of displaying a natural-language reply, the page shows the structured routing result: which intent was recognized, which tool will execute, whether confirmation is required, and the model's reasoning. The interface connects to only two endpoints—a health check and an intent router—keeping the end-side thin and the model Key off-device.
The page models every exchange as a stateful message: pending, success, or error. A health-check button at the top quickly isolates whether a failure is in the UI code or the Gateway process. When the Gateway address is deliberately broken, the error stays inline in the message list rather than disappearing into a toast, preserving the task context for debugging.
The workbench validates four integration points: local Gateway reachability, Network Kit requests from a HarmonyOS device, structured intent routing from natural language, and clear failure states for unreachable addresses. It stops short of executing tools, but the boundary it draws—service status, user input, model routing, execution feedback—is the minimum a production Agent UI needs beyond a chat bubble.
An Agent UI that only shows final replies is a black box; a workbench that shows routing decisions is a debugging tool, and the latter is what teams need before they can ship.
The three responsibilities defined here—initiate task, make model judgment visible, keep failure in context—form a practical checklist that applies to any mobile Agent integration, not just HarmonyOS.
Keeping the model Key exclusively on a local Gateway and off the device is a security boundary that also simplifies the client code to pure display logic.
Showing a `pending` state before replacing it with a result is a small UI detail that eliminates a common source of user confusion during network latency.