Designing AI products around actions and state

Google announced an experimental Gemini 2.0 Flash model yesterday with native tool use, including Google Search, code execution and user-defined functions. The launch material also shows research prototypes that act through a browser and work on coding tasks. Once a model is calling tools, a chat box doesn't give you enough state to show what's going on. Is the task waiting on a tool, asking for approval, retrying something that failed, or has it left a partial result behind?

I'd give every agent-style run a task record that lives outside the chat transcript, with an ID, an owner, the stated objective, when it was created, its current status and links to the inputs it's allowed to use. Queued, running, waiting for input, waiting for approval, blocked, completed, cancelled and failed are a reasonable set to start with, as long as they're honest. Don't show "working" while the system is waiting indefinitely on a tool or has lost its worker.

When the model asks to use a tool, treat it as a proposed action and turn it into a typed record with the tool name, arguments, target, risk level and state. Validate the arguments against a schema, resolve friendly references to stable IDs, and check permissions with the task's execution identity instead of taking the model's word that it's allowed. Anything that might be retried needs an idempotency key, otherwise a timeout after a successful call can send a second payment or message.

Approval belongs right before an action that crosses a meaningful boundary. If you ask on every read, people learn to accept prompts without looking, and if you ask once at the start of a broad task, they're authorising changes they couldn't see yet. Show the actual effect: the recipient and final content for a message, the record and changed fields for an update, the selection rule and count for a bulk action. Keep in mind that approving a draft isn't approving the send. Record who approved, what exact action they saw and when, and ask again if the proposal changes.

Stopping needs the same attention. A stop button can't reverse something an external system has already accepted, so cancelling should mark the task as cancellation requested, block new actions, let anything in flight reach a known boundary or time out, and then list what completed, what was interrupted and what never started. If four of five actions went through, the screen has to say which four, or the user may rerun the whole task and duplicate the work. Any compensation should be its own proposed action with its own approval, and the stop control has to sit outside the model's own interface and permissions so the agent can't hide or disable it.

This is where Gemini 2.0's native tool use lands for product teams. Once a model can call Search, run code or hit your own functions, the product has to show what each run is doing, which action is waiting on the user and what they can still stop, and a chat transcript won't carry that on its own. If you've already got a tool-enabled prototype, I'd draw its state diagram before adding another tool, covering task states, action states, approval, timeout, retry, cancellation and partial completion. For each transition, write down what the screen shows and what the operator record keeps, and build the views that are missing first.