Google’s work agent puts the unfinished job at the centre of enterprise AI

The handoff is the product

An answer can be useful without finishing anything. A colleague still has to open the right application, find the current record, decide which version matters and turn the answer into a deliverable. That handoff is where the next enterprise AI contest becomes interesting: the customer is buying the removal of work, not simply a more fluent description of it.

In its October 8 Gemini at Work announcement, Google described a work agent that plans tasks, uses tools and connects business systems, returning finished work into environments including documents and inboxes. It also described model selection, cost controls and enterprise governance. Those are the company’s descriptions, rather than findings from an independent product test.

The distinction matters because a polished result and a completed business process are different things. A proposal can read beautifully while carrying the wrong price. A customer update can accurately summarise an old account record. Evaluating the output alone would miss the failure that matters to the buyer.

Where the integration bill moves

Consider a hypothetical sales team preparing a renewal. The task crosses several kinds of information: the contract, usage history, unresolved support issues and the account owner’s latest commitments. Finding each item is only part of the job. The agent also has to recognise which information is authoritative and what the user is entitled to change.

A universal agent could make that journey feel simpler. It could also concentrate the burden of maintaining connections. When an application changes a field or a customer changes its approval rules, someone must keep the workflow working. The relevant economic question is whether the supplier absorbs that work or hands it back as a configuration project.

For specialist software companies, this creates two possible businesses. One supplies dependable records and actions that other interfaces can use. Another owns the judgement inside a particular workflow: what counts as an acceptable exception, which approvals are necessary and when automation should stop. Both require more than a conversational front end.

That is why an incumbent agent does not automatically erase smaller products. A broad interface can become a distribution channel for specialised capabilities. The risk for a startup is narrower: if its main contribution is moving text between systems, a general agent may reproduce much of the perceived value. A product built around difficult decisions has a more demanding case to answer, but also more to defend.

The difference becomes clearer if the renewal includes an exception. Suppose the account owner has offered a discount, but the contract system still contains the standard price. An agent that simply gathers available information could produce a confident document from incompatible records. The system needs a way to recognise the conflict and route it to someone with authority to settle it. Faster retrieval would not resolve that particular problem.

For a specialist vendor, this is where accumulated workflow knowledge can become economically meaningful. The vendor may understand which record takes precedence, which exceptions are common and which changes require a second person. A general interface could use that capability without replacing it. The bargaining question would then concern who owns the customer relationship and how the specialist gets paid for the value it supplies.

There is a less comfortable possibility too. If customers increasingly begin work in a broad agent interface, a specialist product may become less visible even while its underlying service remains essential. That would require founders to think about distribution through tools and integrations, alongside the familiar effort to bring users into their own application.

Count accepted jobs, then count the repairs

A useful evaluation would follow a task from request to acceptance. Did the right person approve it? Was the correct record updated? Could the customer identify the sources? How long did checking take? These are proposed evaluation criteria, not published performance results for Gemini.

The accounting should include rejected work. If a team saves ten minutes generating a document and spends fifteen verifying it, the impressive demonstration has not produced an operational gain. Conversely, a modest-looking automation that reliably removes a repetitive handoff may be worth more than a sophisticated assistant that needs constant supervision.

Cost controls belong in that same assessment. The price of model use is one component; integration maintenance, human review and error recovery are others. Comparing agents only on a per-request charge would ignore the labour needed to turn their output into something the organisation will actually use.

There is also a practical reason to begin with bounded tasks. A reversible draft has a different consequence from an external commitment or an irreversible record change. A customer can expand an agent’s authority as its performance becomes observable, rather than treating access to every tool as a prerequisite for discovering value.

Design the trial around disagreement

A test set should include cases where the records disagree or an instruction is incomplete. Perfectly prepared demonstrations can show what the agent is capable of under favourable conditions. They tell a buyer less about how the system behaves when the everyday messiness of a business returns.

The organisation could ask the agent to explain why it stopped, not merely whether it succeeded. A refusal to make an unsupported change may be the correct result. If a scorecard counts only completed actions, it might penalise appropriate caution and encourage the wrong kind of automation.

An evaluation also needs a baseline. Compare the agent-assisted process with the way the task is actually performed today, including existing shortcuts and review. A comparison against an artificially slow manual process would overstate the benefit. The point is to discover whether the customer’s real work improves.

A more revealing contest

Google’s announcement makes completed work the centre of the pitch. It does not by itself establish how reliably the product completes a particular customer’s work, or what the full operating cost will be. Those answers require observed deployments and task-specific evaluation.

The competitive story is therefore less about which assistant sounds most capable and more about who owns the messy last stretch. In that stretch sit permissions, exceptions, current information and responsibility for repair. A startup that understands those details has a concrete problem to solve. A buyer that measures them has a better chance of purchasing a useful agent.