Should a Workplace Agent Start in Your Mobile App?
A workplace AI agent does not automatically belong in a new app. Use workflow frequency, permissions, integrations and user context to choose its first interface.
A workplace AI agent can make a product question feel urgent: where should employees use it? Google Trends FR surfaced coverage of a new Google workplace agent, including reporting by Reuters and Bloomberg. That signal makes the interface decision timely, but it does not establish that the agent has a particular mobile integration or that every business needs one. The durable question is about workflow fit. Should employees reach an agent through an existing mobile app, or should the first release use a separate interface? Decide by examining the work, the user’s context, the systems and permissions involved, and the cost of building and supporting another surface.
Start with the employee task, not the device
List the specific tasks the proposed agent would support, then identify where employees already complete each task. A phone is a plausible starting point when work is already mobile: for example, a hypothetical field employee might ask for a site checklist or submit a short status update while away from a desk. A task that involves reviewing long documents, comparing several records, or approving complex exceptions may be better suited to a larger screen. These are product hypotheses to validate, not assumptions about what an agent can do. Map the complete workflow, including what happens before and after the agent responds, before choosing a channel.
For each candidate task, record how often it occurs, whether it is time-sensitive, where the employee is likely to be, and what information or action is required. Note whether a phone offers a genuine advantage, such as using an existing app session or capturing information at the point of work. Also document friction: small-screen review, interrupted sessions, poor connectivity, or the need to switch between tools. If the task is occasional and needs substantial context, a separate web interface may be a clearer first step. If it is frequent and naturally fits the existing app journey, extending that app may reduce interface fragmentation—but only if its foundations suit the work.
- Write one task statement in the form: “When [work situation], the employee needs to [task] so they can [outcome].”
- Observe the current task path and identify where a mobile interaction would remove a step rather than merely add an AI entry point.
Compare integration, permissions and delivery scope
An existing app is not automatically the cheaper or simpler option. Check whether it already has the relevant employee identity, navigation, device support, and connections to the business systems the workflow depends on. Define which system owns each piece of data and which service performs any action. The agent interface should not become a shortcut around existing authorization rules. A separate interface may need its own sign-in, accessibility work, support process, and integration contracts; integrating into the mobile app may instead require changes to app architecture, backend APIs, release procedures, and older supported versions. These are cost and delivery drivers to assess during discovery, not generic estimates.
Set permissions according to the specific task, not a broad idea of what an agent might eventually do. Read-only answers from approved records have a different impact from actions that change assignments, submit forms, or send messages. For any proposed action, define which user identity applies, what the agent may access, what must be confirmed by a person, and how the business can inspect the outcome. Keep a clear boundary between a suggested answer and a completed operation. If the first workflow requires capabilities that the current app or service layer cannot safely support, a limited separate interface or a non-agent workflow may be a more responsible MVP than a rushed mobile integration.
- Inventory identity, data sources, APIs, action permissions, confirmation steps, audit needs, and supported devices.
- Ask engineering to estimate the smallest end-to-end workflow in each interface, including testing, release and ongoing support.
Choose a testable first interface and evaluate it
Use a simple decision rule: choose the existing mobile app when the target task is already phone-shaped, employees use that app for the surrounding workflow, and the required identity and integrations can be extended without weakening controls. Choose a separate interface when the work needs a distinct desktop workspace, the mobile app would require a disproportionate redesign, or the workflow needs to be validated before committing to app releases. A hybrid approach can be appropriate later, but it adds consistency and support questions. Avoid launching the same agent in multiple places just to maximise access; each additional surface creates decisions about permissions, context, and where employees should go for help.
For a hypothetical pilot, imagine employees already use a company app to record equipment inspections. Test one narrow task: ask the agent to locate an approved inspection procedure and guide the employee to the relevant step. Compare a proposed in-app flow with a simple separate interface using representative users and realistic, non-sensitive test data. Evaluate whether users find the task, understand the response’s source and limits, finish the workflow, and know what to do if the system cannot answer. Track completion, errors, escalation, and support questions against a baseline you define before the pilot. Do not expand access or enable consequential actions until the workflow, permissions, and fallback behaviour have been reviewed.
- Write pilot acceptance criteria before development: task completion, source visibility, safe fallback, permission checks, and user comprehension.
- Decide in advance what evidence would justify integrating the workflow into the app, changing the interface, or stopping the pilot.
The right first interface is the one that fits a defined employee task and can support it with clear permissions, dependable integrations, and a manageable delivery scope. A mobile app is a strong candidate when the work already happens on phones and the app can carry the workflow without forcing a larger redesign. A separate interface can be useful when the task needs a different workspace or the product question is still unproven. Treat the Google workplace-agent signal as a prompt to assess employee workflows—not as evidence that a mobile integration exists or should be built.