This week on the a16z show, Greg Brockman, president and co-founder of OpenAI, made the point that developers have been “retooling the world” to make software more accessible to AI agents. But computer use could offer a simpler path forward. 

And for Brockman, simplicity is really the North Star for AI: “We really should be one AI that’s unified, that makes it so easy and smooth for you to be less engaging with the computer and less wrapping yourself around the computer.” 

Meanwhile, other AI companies continue to invest in connector infrastructure. 

“We’re kind of retooling the world,” Brockman says. Is it time to stop? 

MCP servers, CLIs, APIs, and other agent integrations help AI agents reach more tools, data, and software. But that wide access doesn’t come without some burden — at least that’s what it sounds like in Brockman’s conversation with Ben Horowitz and Erik Torenberg, hosts of the a16z show. As OpenAI’s president explains:

“What if it’s more behaving like a human? Can it just use a computer?”

“People have been building these MCP servers and these CLIs and just really sort of taking the world of software and making it accessible in this almost stilted way that is not really meant for humans,” he said. “It’s like we’re kind of retooling the world.”

How did we get here? “For agentic use cases, it really comes down to the tools,” said Brockman, indicating why MCP servers and other connectors have become so common. But if models can learn to use computers the same way that people do, then perhaps developers no longer need to keep building purpose-built integrations for every application. 

As Brockman wonders: “What if it’s more behaving like a human? Can it just use a computer?”

OpenAI has been thinking about computer use since the beginning

As Brockman details on the podcast, the idea traces back to the early days of the AI company when the team laid out a three-step plan during an offsite meeting in November 2015 that the president says the team largely stuck to for the following 10 years. 

Around this time, Brockman says the OpenAI team also broached the idea of using reinforcement learning directly against a computer interface:

“We also talked about, what if we could do reinforcement learning where the environment is screen pixels, keyboard, mouse, right? Same interface as a human.”

From where he sits, this could open up the computer for nearly any sort of task. More importantly, Brockman muses that computer use for agents could help the broader industry advance AI without requiring purpose-built integrations every step of the way. Instead of building and maintaining scores of specific connectors, an agent could simply use the same computer interface people do. 

“There’s so much software that you don’t even think about,” he told Horowitz and Torenberg. “How much of your life is clicking around menus and typing things into a spreadsheet and things like that? None of that is what we should be doing.”

Instead of building and maintaining scores of specific connectors, an agent could simply use the same computer interface people do. 

In fact, Brockman says computer use capabilities are part of why he considers GPT-6 Astra, OpenAI’s newest flagship model, “pretty reasonable to call” AGI. 

But connectors aren’t disappearing yet

Though Brockman is bullish on computer use, the rest of the industry isn’t giving up on structured integrations. In fact, some are plowing ahead. 

AWS, for example, recently launched a managed consent portal, a managed web experience and session binding endpoint for AgentCore Gateway, a capability of Amazon Bedrock AgentCore that connects agents to external tools and services. On Monday, the cloud company published a detailed walkthrough of the feature. 

For example, with the Consent portal, an administrator could configure GitHub and Slack as gateway targets and send the portal URL to developers who can then open the URL, sign in with their corporate IdP, and connect GitHub and Slack as needed, independently. 

Meanwhile, even at OpenAI, plugins aren’t going away. Though OpenAI Codex arrived in the browser with a new Chrome extension back in May that allowed agents to operate within live browser sessions and authenticated workflows across multiple tabs, plugins remained the preferred route because they allowed Codex to work directly with services, such as Slack, Gmail, and GitHub, without manually navigating their interfaces.

Brockman told the a16z show hosts that simplicity should be the North Star. Reliable computer use could be one way to get there. But for now, connectors are still hanging in there.

The post OpenAI president: “The computer should be there to empower you.” So stop retooling software for AI agents appeared first on The New Stack.

Any business worth its salt in 2026 needs to be embracing the right tools to reach its customers, and few tools carry as much weight as WhatsApp.

Paid messaging on the app crossed a $2 billion annual run rate in the fourth quarter of 2025, CFO Susan Li told investors on Meta’s January earnings call. But getting a business properly set up on WhatsApp can still be a fiddly job. The initial onboarding can send developers jumping between Meta’s account settings, API documentation, and code editor as they connect and verify a phone number, configure webhooks, and get the integration working. Some of that is a one-off job, but things like managing message templates, testing changes, and troubleshooting the setup can bring developers back to those same tools later.

Meta’s answer, announced today, is to let AI coding agents handle much of that setup directly through MCP.

Connecting coding agents with WhatsApp

The easiest way to understand what the WhatsApp Business Tools MCP server is all about, is to look at the sort of job a developer might want to hand over to an agent.

Take an online retailer that wants to use WhatsApp for customer support, order updates or the occasional special offer. A developer can connect the new MCP server to an agent such as Claude or Codex, sign in with their Meta account, and choose which of the businesses they already administer the agent is allowed to access. That access is scoped to whatever businesses they select — connecting the agent doesn’t give it free rein across every Meta account associated with the developer.

Give the agent the number and the display name the business wants to use, and it can handle the steps needed to add the number and set up the WhatsApp account behind it. Meta then sends a one-time verification code by SMS or voice; once the developer gives that code back to the agent, the number can be verified and registered for sending messages.

In a blog post announcing the feature on Tuesday, Zoë Lieberman, who works on product marketing at Meta, says the idea, ultimately, is to turn what might otherwise be a string of separate API tasks into something the user can ask an agent to do in plain English.

“You describe what you want — your agent handles the accounts, numbers, templates, and API calls.”

“You describe what you want — your agent handles the accounts, numbers, templates, and API calls,” Lieberman writes.

A template example

Much of the WhatsApp Business Tools MCP server is concerned with getting a business up and running on WhatsApp in the first place. Message templates, however, show how the agent can remain useful once that initial setup is done.

There is a WhatsApp rule worth explaining, though. When a customer messages a business, it opens a 24-hour customer service window, during which the business can reply with ordinary, free-form messages. Each new message from the customer starts that 24-hour clock again. The idea is to stop businesses turning an old customer conversation into an open-ended channel for unsolicited messages: once the window has closed, the business generally needs to use a message template that Meta has approved if it wants to contact that customer again.

So the retailer could ask the agent to create a marketing template offering customers a coupon, for example, or a utility template for sending order updates. The template can include elements such as a header, body copy, footer and buttons.

From the same conversation, the person using the agent can list the business’s existing templates, pull up a particular version, update it or delete it.

Once the pieces are in place, the developer can ask the agent to send a test message and check that everything behaves as expected before putting it in front of customers. If the recipient is outside the 24-hour customer service window, the agent can flag that a free-form message can’t be sent and offer an approved template instead.

There is also the other half of a WhatsApp conversation to deal with: what happens when the customer replies?

The developer can ask the agent to configure the webhook that tells WhatsApp where to send those incoming messages and other events, such as the retailer’s CRM, customer-support platform, chatbot or order-management system.

The agent can inspect the account as well as change it. That means asking what has already been configured or what still needs attention — for example, whether the business is missing the payment information Meta needs to charge for billable WhatsApp messages.

There are some guardrails around all of this. The agent operates using the access of the person who connected it, and Meta says actions performed through the MCP are recorded.

“Every read runs under your own viewer context, every invocation is logged, and anything that changes state requires an authenticated person rather than an app-level credential.”

“Every read runs under your own viewer context, every invocation is logged, and anything that changes state requires an authenticated person rather than an app-level credential,” Lieberman writes.

Meta’s MCP push stays tied to human identity

That human-bound approach lands amid a broader debate over how AI agents should identify themselves. Agents today often inherit the permissions of the person using them, while some companies are pushing toward giving agents their own scoped, revocable identities — evidenced by Vercel’s recent acquisition of Better Auth. The concept is also showing up in the big cloud platforms, too, such as with Microsoft’s Entra Agent ID, which automatically assigns an identity to agents created in Azure AI Foundry or Copilot Studio. And Amazon Bedrock AgentCore Identity, meanwhile, gives each agent its own identity, letting it act on a user’s behalf or independently, without borrowing anyone’s login.

So while there is a clear push toward giving agents their own identity, Meta is keeping the human firmly in the loop here, The agent can act only within the authenticated user’s existing access, keeping permissions bounded by a known human account and making sensitive changes easier to attribute and control.

It’s also worth noting that this isn’t Meta’s first attempt to put its developer tools within reach of AI agents. In June, the company launched Developer Tools MCP, later rebranded as Meta Social Technologies MCP, which works across Meta’s developer platform — including integrations built with the WhatsApp Business API.

There is some overlap between the two, but they operate at different levels. Meta Social Technologies MCP is the broader developer tool: an agent can use it to discover Graph API endpoints, search Meta’s documentation, inspect the app behind an integration and troubleshoot errors. That can absolutely include a developer building with WhatsApp.

WhatsApp Business Tools MCP, meanwhile, is much more specific to operating WhatsApp Business itself. It gives the agent tools for working with WhatsApp Business accounts, onboarding and verifying phone numbers, creating and managing message templates, configuring and testing webhooks, and sending test messages.

“They’re complementary — install both if you need both,” Lieberman writes.

It’s early days for the new WhatsApp server. Meta says it is rolling out gradually, meaning it may not be available to everyone immediately, while the interface and tools themselves remain in beta and are subject to change.

The post Meta lets Claude and Codex configure WhatsApp Business via MCP. But the agents don’t get their own identity. appeared first on The New Stack.

Amazon Web Services (AWS) has released a new open-source application dubbed Pizza Bot, which gives developers an email-style inbox for managing AI agents that run in the background.

The problem that Pizza Bot is designed to address, ultimately, is that a chat interface is a poor fit for agents whose work continues after the (human) user has clocked off for lunch or bed.

And so Pizza Bot leans on the age-old mechanics of email: completed jobs arrive as unread threads, while anything that needs a human decision is surfaced for action. An Activity panel also exposes jobs handed off to specialist agents, including their tool use and progress.

“Scheduled agents run autonomously in the background and surface updates directly into your inbox for review and triage.”

Writing about the new project in a LinkedIn post on Thursday, co-creator Joseph Dolivo, principal technologist at AWS Startups, notes that Pizza Bot shifts the burden of monitoring agent work firmly away from the user.

“Instead of you having to initiate every conversation or wait on a prompt, scheduled agents run autonomously in the background and surface updates directly into your inbox for review and triage,” he writes.

As if to emphasize that point, in the accompanying blog post for the project’s official launch on Thursday, the creators note that user absence is, in fact, a core tenet of the design brief.

“The interface assumes you are not watching.”

“The interface assumes you are not watching,” they write. “Nothing else we’ve seen starts there, and that one assumption is what buys you pauses that outlast the session that created them, notifications worth acting on, and scheduled work that produces threads instead of logs.”

A community project

Despite its Amazon roots, Pizza Bot is in fact now a standalone community project rather than an AWS service. It lives in its own GitHub organization, separate from Amazon, and comes with no AWS support or service-level agreement — it’s entirely self-hosted.

Pizza Bot itself is a desktop app for macOS, Windows, and Linux, with browser and terminal clients available too. By default, the app starts a local Pizza Bot server on the machine, while developers choose the model behind it — including Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter or a local model via Ollama.

It can also be extended through MCP servers and Agent Skills; the bundled browser-automation skill, for example, uses Playwright MCP to navigate and interact with websites.

The server can also run on an always-on host or in a container, letting scheduled agents keep working while the laptop is closed and their threads be picked up later from another device.

Under the hood: LangGraph and ambient agents

Pizza Bot’s agent runtime is built with DeepAgents, LangChain’s open-source harness for long-running agent tasks, which itself runs on LangGraph, its runtime for stateful agent execution. The important part in all of this is persistence: LangGraph checkpoints an agent’s state as it works, allowing a run to stop for approval, survive a disconnected client and resume later without starting again from scratch. Pizza Bot stores those checkpoints, along with threads and other application data, locally in SQLite and ordinary files.

It’s worth noting that AWS has its own open source agents SDK, Strands Agents, out since May 2025 — but evidence suggests, including text in this sample repository, that AWS considers Strands as a “lighter-weight alternative to LangGraph for agents that don’t need explicit graph control flow.”

In response to a question posted on LinkedIn by The New Stack, Dolivo says that they very well could have used Strands for Pizza Bot, particularly as Strands supports TypeScript and workflows now. But they ultimately went for LangGraph “due to the maturity of the tooling and breadth of the exosystem,” he explains.

“It’s also more familiar to many developers, and we wanted to reduce friction for community adoption since we knew we’d be open-sourcing it,” he adds.

Pizza Bot is also fairly close to an idea LangChain introduced way back in January 2025, when CEO Harrison Chase introduced the term “ambient agents” for agents that could respond to events, work concurrently and involve a human only when needed. LangChain’s reference implementation was an email assistant built on LangGraph. It also developed what it called an “Agent Inbox”: a standalone interface inspired by email and customer-support software for keeping track of open interactions between people and background agents.

From ‘JoeBot’ to Pizza Bot

The genesis of Pizza Bot can be traced back to April 2025, when Dolivo kicked off what he calls a “side-of-desk passion project” dubbed “JoeBot” that automated repetitive CRM logging. He later teamed up with colleague Igor Fil to turn that script into Pizza Bot, an MCP server that could execute parameterized, deterministic “recipes” across its internal systems.

The appeal soon spread beyond the engineers building it into less-technical domains. As the project evolved, Dolivo says it would eventually grow to more than 30 contributors and over 2,000 users inside Amazon, and so Pizza Bot needed a front end that people could open and use.

“An MCP server requires an MCP client, and expecting non-technical users to work out of an IDE or terminal was never going to cut it,” Dolivo adds. “We had to meet people where they actually work and own the experience end to end.”

The result was the version of Pizza Bot released this week: a desktop app built around an inbox rather than a terminal.

The post AWS open-sources Pizza Bot: email-style inbox for background AI agents appeared first on The New Stack.