AWS is betting that AI agents need a different interface as they move beyond answering prompts and start working autonomously in the background.

The company has open-sourced Pizza Bot, a self-hosted application that gives users an inbox for managing work delegated to AI agents, with separate threads for ongoing tasks and a queue for work that is completed or needs human input, rather than keeping the management of agents restricted inside a conventional chat window.

The rationale, according to AWS, is that background agents do not always need a user’s attention while they work and an inbox model will let users hand off longer-running tasks, return to them later, and see which jobs are complete or require intervention.

Under the hood

That approach is reflected in how the inbox organizes work with the help of an “All” tab that contains the history of each task or conversation, including the agent’s messages and work performed, the “Unread” tab that flags completed work that users have yet to review, and an “Action” tab that surfaces tasks paused while waiting for user input or approval.

The inbox interface also has a panel named Activity that shows users how an agent handled a particular task along with the transcript, AWS wrote in a blog post introducing Pizza Bot.

AWS’ inbox-oriented rationale also extends to Pizza Bot’s architecture.

It uses LangChain’s Deep Agents as the harness and LangGraph as the stateful runtime, with a combination of the two allowing an agent to checkpoint its progress as it works, preserving its messages, tool activity and current state so a task can be paused and resumed rather than being tied to a live chat session, the hyperscaler wrote.

Pizza Bot’s server sits on top of that stack, connecting the agent runtime with the user interface, skills, MCP servers and the model provider, with developers able to choose from Anthropic, OpenAI, Google Gemini and Amazon Bedrock, as well as local models through Ollama, it added.

As for its out-of-the-box capabilities, the application comes with skills for working with files, browsing the web and delegating tasks to specialist agents. Developers can also add existing Agent Skills and MCP servers to give the agents access to other tools and services, the hyperscaler wrote.

Enterprise integration could remain a hurdle

However, analysts were not too convinced that Pizza Bot’s out-of-the-box skills and support for existing tools will make its implementation easier for enterprises.

While the out-of-the-box capabilities and added support for existing skills saves enterprise teams the time to build the application, it leaves out the integration work required to make it work, said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

“Integration is where most of the money in an enterprise agent deployment goes. A sales or finance team gets value from an agent when it can read and update CRM, email and ERP, and each of those systems needs a connector someone has to build, secure and maintain,” Chopra pointed out.

Pizza Bot’s integration could be further complicated by the application’s lack of support or any SLA, according to Manoj Chandra Jha, principal analyst at Nord-IQ Research. That means the integration and operational burden ultimately falls on enterprises, who would be responsible for running, securing and maintaining the open source software themselves, Jha said.

Rise in enterprise productivity likely

But for enterprises willing to take on that integration work, the inbox-oriented approach could improve productivity.

“It’s a meaningful shift because it changes the economics of delegating work to agents. A chat interface requires a person’s attention throughout the task, while an inbox brings them in only when their judgment is needed, much like how executives delegate work to their teams,” Chopra said.

“Coding agents have already demonstrated this model, where an engineer assigns an issue and reviews the resulting pull request. Pizza Bot extends that approach to tasks such as meeting preparation and follow-ups,” Chopra added.

Further, the analyst pointed out that the inbox-oriented approach could give enterprise teams a clearer window into how scheduled tasks perform.

“For scheduled tasks, having the results delivered as threads gives users a way to track what happened in the background and spot failures that might otherwise go unnoticed,” Chopra said.

Out of sight, out of mind

There are risks with this approach, however: “The inbox model can make bad work less visible. When somebody is watching an agent in a chat window, they can see it going off the rails,” said Phil Fersht, CEO of HFS Research.

In contrast, when hundreds of tasks are running quietly in the background, users may not see an agent making mistakes until the task is complete or an exception requires their attention, potentially making problems harder to catch early, Fersht said.

That reduced visibility can also create approval fatigue, according to Chopra.

“An agent sending back dozens of threads with multiple approval requests can condition users to approve them without reading them closely,” Chopra said.

There is also a risk in the delay between an agent preparing an action and a user approving it: “Information that was current when the agent paused may no longer be valid hours later, potentially resulting in an outdated CRM update or a meeting invite for a slot that is no longer available,” he said. “An assumption that might be caught in a live chat can go unchallenged as the agent continues building on it and consuming model resources. Scheduled runs can also add costs without anyone watching them in real time.”

Those disadvantages can be countered by designing processes with fewer, better-timed approval points, and verifying that the underlying data is still current before allowing an action to execute, he said.

Adoption likely to start with technical teams

Such tradeoffs are likely to shape where Pizza Bot gains traction.

“Adoption will likely be bottom-up, with individual technologists and small platform teams drawn to Pizza Bot’s control and standards-based design,” Jha said. “Risk-averse industries, especially ones in the regulated sectors, and business users with limited technical expertise, however, are likely to approach the application more cautiously,” he added.

That could leave Pizza Bot occupying a more targeted role in the enterprise, as a way for technical teams to experiment with asynchronous agents and new ways of delegating work, rather than an immediate replacement for the governed interfaces and managed services enterprises typically use for business-critical processes, he said.

This article first appeared on InfoWorld.

The first hit is access. I have talked with technology leaders whose teams had a working model but could not secure the capacity to operate it at production scale on the economics they had forecast. The available capacity sat outside the assumptions behind the existing agreement, and market pricing had moved well beyond the budget. As CIO.com has reported, AI is exposing the limits of enterprise cloud strategies created before these workloads became material.

Data movement creates another problem. AI workloads may cross regions or providers in search of an available GPU or a better price on a particular chip. I have seen finance teams confront cloud bills that ran well beyond forecast because data had to leave one cloud to reach compute available in another. The increase had nothing to do with headcount or a wave of new applications. It came from an architecture assembled around capacity rather than cost.

Egress pricing also changes the economics of portability. Consolidating with one hyperscaler may simplify operations, but it can become expensive to change course when the provider cannot supply the right capacity in the right place. By the time the CIO needs alternatives, the cost of moving data may have weakened the negotiating position.

Then the question reaches the board: What will AI cost next year? Some CIOs cannot answer with confidence because the contract and cost model were built around a different workload. That is more than a forecasting problem. It tells the board that the company has committed to an AI roadmap without understanding the infrastructure economics beneath it.

What prepared CIOs are doing differently

The CIOs in the best position separated AI economics from the rest of the cloud estate before returning to a provider. They stopped defending cloud spend as one number and accounted for training and inference by workload, region and chip. That work gave them something far more useful than another high-level forecast: evidence they could negotiate from.

Some have resisted the usual pressure to consolidate everything with one hyperscaler. They have kept selected AI workloads portable across providers or moved GPU-heavy training to specialized infrastructure companies. Portability carries its own engineering and governance costs, so it is not automatically the right answer. But a credible ability to move a workload creates leverage that a cloud strategy built around dependence cannot.

The contract requests have changed as well. CIOs are asking for guarantees tied to named chip types, shorter terms for volatile AI capacity and the ability to rebalance spend categories as the workload mix changes. One structure is a reserved allocation for a specific GPU generation rather than a general compute credit. Another is a shorter AI-specific commitment layered over a longer agreement for the general-purpose estate. The two workloads do not have to be forced into the same planning horizon.

The work should start before the provider puts a proposal on the table. Once the negotiation has been reduced to a renewal number and a discount percentage, the most important assumptions have already escaped scrutiny.

Start with the workload rather than the existing agreement. Which AI use cases are expected to reach production during the next term? Which require training, which rely mostly on inference and which can use a managed model without dedicated GPU infrastructure? Those distinctions determine whether the company needs reserved capacity, flexible consumption or no direct GPU commitment at all.

Then test the location assumptions. Where does the underlying data reside? What residency or sovereignty rules limit where it can move? If the preferred capacity is available only in another region or from another provider, calculate the transfer, egress and operational costs before calling that option cheaper. A lower compute rate can disappear quickly when the data has to travel to reach it.

Capacity and discounts also need to be separated. A favorable price does not guarantee that the required chip will be available when a production workload needs it. Conversely, a capacity reservation can protect access while creating a cost for infrastructure the company does not fully use. The CIO needs both numbers: the economics of consuming the capacity and the economics of holding it.

Finally, decide what must remain portable. Full multi-cloud portability is expensive and often unnecessary. But there may be a small number of high-cost AI workloads where dependence on one provider creates more risk than portability costs. That is where an alternative architecture can become negotiating leverage rather than an abstract cloud principle.

None of this requires treating the original agreement as a mistake. It was often a reasonable decision based on the company’s workload at the time. What has changed is the cost of leaving it unexamined.

A three-year cloud agreement cannot be treated as a three-year suspension of judgment. Before the next renewal, test the commitment against the workload the company is actually running, not the company it was when the agreement was signed.