Workplace Agents on Phones: Design for Lost Connectivity
Plan what a workplace-agent app can save, queue or must hold when a connection drops, and show employees clearly whether an AI-assisted task is actually underway.
Workplace agents are entering the conversation as mobile product teams consider how employees might initiate work from a phone. Google Trends FR’s 24-hour signal includes Reuters’ report on Google Cloud introducing a Gemini agent for work; it is context, not proof of demand or a design recommendation. The practical product question is narrower: what should the app do when an employee starts an AI-assisted task and the connection is unreliable? The answer depends on the consequence of the task, the data it needs and whether the server has confirmed receipt. Treat connectivity as part of workflow scope, not as a promise that the agent can work offline.
Classify the task before designing offline behaviour
Start by separating what the phone can safely retain from what requires a live service. A draft prompt, selected record identifier, non-sensitive form values or a task description may be useful to preserve locally, subject to the organisation’s data policy and device protections. But displaying saved inputs is not the same as performing the task. If the agent needs current business records, permissions, policy checks, a model response or an external system, the app cannot honestly claim that work has started until the relevant service has accepted it. Map each workflow step and name its dependency before deciding what the interface does during a network failure.
Use consequence and reversibility to set the boundary. A low-risk request to summarise a previously downloaded document may allow the user to save a draft and submit it later. A request to change a customer record, send a message, approve an expense or trigger an operational action should wait for server validation and confirmation. Do not queue a command that could become unsafe or misleading as its context changes. Even apparently routine work may depend on fresh data or permissions. Product, engineering, security and operations owners should agree which inputs can be stored, how long they remain there, and which actions must never execute from a stale or unverified state.
- For each workflow, record its required data, permission checks, server dependencies and business consequence.
- Mark steps as save locally, submit when connected, or require a live response before the user can continue.
- Set retention and deletion rules for any locally stored work, especially on shared or managed devices.
Make pending, failed and completed states unmistakable
A reliable interface distinguishes a saved draft from a request that has reached the server. If the employee loses signal before submission, say that the task is saved on this device and has not been sent. If a request was submitted but the response was interrupted, show that its status is being checked rather than inviting an immediate repeat. The server may have accepted the request even though the phone never received confirmation. Give each submitted operation a stable identifier and provide a way to retrieve its authoritative status when connectivity returns; this reduces ambiguity for both the user and support teams.
Use plain status language tied to actual system evidence: “Draft saved on this phone,” “Waiting to send,” “Received by the service,” “Agent response available,” or “Could not confirm—check status.” Avoid “working offline” unless the relevant computation and required data genuinely are available locally. Show when a status was last checked, and make stale results visibly distinct from current ones. Retry behaviour should be explicit: safe reads can often be retried, while changes with side effects need deduplication and a status check before resubmission. Never make a spinner or optimistic success message stand in for server acknowledgement.
- Design separate states for unsent drafts, queued requests, server-accepted work, unknown outcomes, failures and completed results.
- Use idempotency or an equivalent server-side duplicate-prevention approach for retryable actions with side effects.
- Provide a clear next step: reconnect, retry, review the saved draft, or contact support.
Scope a connectivity MVP and test its failure paths
For an MVP, select one representative employee workflow and specify its connectivity contract before estimating implementation. Identify the minimum local data, whether it contains sensitive information, how the app protects it, and what event triggers submission. Agree how the backend acknowledges receipt, reports processing status and handles duplicate requests. Also decide what happens if a user signs out, changes account, reinstalls the app or leaves a request pending for an extended period. These choices affect mobile storage, API design, authentication, observability, QA and support; treating them as edge cases can create scope gaps and unreliable delivery estimates.
Test transitions, not only a successful reconnection. Interrupt the network before submission, during upload, after server acceptance and while the agent response is returning. Reopen the app, submit twice, change accounts and let a queued draft become stale. Confirm that the employee can tell what has happened and that the backend does not execute a consequential action twice. Include weak and intermittent connections, not just airplane mode. For the pilot, track operational evidence such as unresolved request states, duplicate prevention and support-reported confusion. These are evaluation measures for the workflow, not claims that an agent performs work without a connection.
- Define acceptance criteria for each network-loss point, including expected screen state and recovery action.
- Estimate offline storage, server status lookup, retry logic and QA as explicit scope items.
- Pilot with a bounded, low-consequence task before extending queued behaviour to business-changing actions.
A mobile workplace agent should preserve useful employee input where policy permits, but it must not blur saved work with submitted work or imply that a server-dependent agent is operating offline. Define the boundary per task, make server acknowledgement authoritative, and design recovery around the possibility that a response was lost after an action was accepted. For product leaders, these decisions are practical MVP and cost drivers: they shape local storage, APIs, security controls and testing. A clear connectivity contract makes the workflow easier to estimate, validate and support.