← Back to Blog

Your AI Agent Needs a Job Queue, Not a Chat Window

Dhaval Bhatt
A glowing AI agent workflow moving through queued, active, approval, and completed checkpoints on a dark purple background

The most important AI agent release this month was not a smarter model.

It was a job queue.

On July 7, Google expanded Managed Agents in the Gemini API with background execution, remote MCP connections, custom function calls, and credential refresh. The technical details matter. But the bigger signal is simple: useful agents are moving beyond chat sessions and becoming long-running workers.

OpenAI is moving in the same direction. Its updated Agents SDK supports controlled sandboxes, durable execution, snapshots, and rehydration from checkpoints. Its workspace agents can keep working in the cloud, run on schedules, and stop for approval before sensitive actions.

The model is becoming one part of the product. The surrounding system is becoming the product.

A chat request is not a real workflow

Chat interfaces trained us to expect a quick cycle: ask a question, wait a few seconds, receive an answer.

That works for summarizing a document. It breaks when the job requires the agent to:

  • research across multiple sources;
  • process a large folder of files;
  • call several tools in sequence;
  • wait for a person to approve a decision;
  • recover from a failed connection;
  • continue working after the user closes the browser.

Those are not chat turns. They are jobs.

Google’s background execution documentation explains why this shift is necessary. Standard HTTP requests commonly close after about 60 seconds. A multi-step agent may need several minutes. Background execution lets the application start the work, receive an interaction ID immediately, and check or stream progress while the task runs elsewhere.

That changes the customer experience. Instead of a spinner that may fail, the user gets a durable job with a visible state.

Design the states before you design the prompt

Google’s Interactions API exposes states including in_progress, requires_action, completed, failed, and cancelled. Those labels look like implementation details. They are actually a useful product blueprint.

Before you refine a system prompt, define what your customer should see at each stage:

  • Queued: We received the job and saved the inputs.
  • Working: The agent is gathering information or using tools.
  • Needs approval: A person must confirm a consequential action.
  • Completed: The result is ready, with the supporting evidence.
  • Failed: The system explains what stopped and what can be retried.
  • Cancelled: The user can stop a run without losing control.

Imagine an agent for commercial property managers. It reviews inspection reports, checks lease requirements, prepares follow-up tasks, and drafts vendor messages.

A weak version puts the whole process behind one “Run” button.

A dependable version shows which properties were reviewed, which documents are missing, which actions require approval, and where the agent stopped. The prompt can be identical. The second product earns more trust because the workflow is legible.

Persistent state is what makes the agent useful tomorrow

Long-running work also needs memory that is more concrete than conversation history.

An agent may need a workspace containing files, installed tools, intermediate calculations, and previous outputs. Google’s managed agents can preserve an environment across interactions. OpenAI’s Agents SDK can externalize state, snapshot the run, and restore it in a fresh sandbox if the original environment fails or expires.

This matters because real work is messy. Connections drop. Credentials expire. A reviewer asks for a correction. A source document arrives late.

If every interruption forces the agent to restart, you did not build a worker. You built a fragile demo.

For your first product, persistent state does not need to be elaborate. Save four things:

  1. the original customer request;
  2. the files and data the agent used;
  3. the current workflow step;
  4. the outputs and approvals produced so far.

That record gives you resumability, an audit trail, and the raw material for improving the product. It also helps a human understand what happened when the result is wrong.

Approval gates are a feature, not a limitation

Founders often describe autonomy as if the best agent is the one that never asks permission. That is the wrong goal for many valuable workflows.

Google’s system can pause in a requires_action state when client input is needed. Its security guidance recommends human verification for generated code, data transformations, configuration changes, and other sensitive work. OpenAI’s workspace agents can be configured to request permission before actions such as editing a spreadsheet, sending an email, or adding a calendar event.

The lesson is not “agents are unsafe.” The lesson is to place autonomy where the cost of a mistake is low and judgment where the consequence is high.

A practical first version might let the agent:

  • collect and organize evidence automatically;
  • calculate or classify routine cases;
  • draft the recommended action;
  • pause before sending, deleting, purchasing, publishing, or changing a system of record.

Your domain expertise tells you where that line belongs. A generic builder sees a tool call. You know which action creates legal, financial, operational, or reputational risk.

That judgment is part of the product.

Build the smallest durable worker

Do not respond to this shift by adding ten agents and a complicated orchestration diagram. Start with one narrow job that matters.

Choose a workflow that takes 15 to 60 minutes today and has a clear finished output. Map the steps. Mark the tools. Identify the approval point. Define success and failure. Then build the smallest system that can run, pause, resume, and show its work.

Your first checklist is short:

  • Can the customer leave and return without losing the job?
  • Can the agent resume after an interruption?
  • Can a human see what it did?
  • Can the user cancel or retry?
  • Does the agent pause before an irreversible action?
  • Is the final output tied to evidence the customer can inspect?

A chat window can demonstrate intelligence. A durable workflow demonstrates value.

That is the opportunity for domain-expert founders. You already understand the sequence, the exceptions, the handoffs, and the decisions that make a real job complete. New agent infrastructure makes those workflows easier to build. It does not decide which workflow deserves to exist.

If you want help turning the process you know into a focused AI product and a 12-week launch plan, book a strategy call. That is what we build inside the AI Product Accelerator.


Sources: Google, “Expanding Managed Agents in Gemini API” (July 7, 2026); Google AI for Developers, “Background execution”; Google AI for Developers, “Agents Overview”; OpenAI, “The next evolution of the Agents SDK” (April 15, 2026); OpenAI, “Introducing workspace agents in ChatGPT” (April 22, 2026).