The next big opportunity in AI agents isn't building better agents

It’s building the infrastructure that lets them actually do work.

I’ve been digging into Pi Durable on Cloudflare, and it’s changed how I think about agent architecture.

Most agent demos follow the same pattern:

1. Spin up an agent
2. Give it a model
3. Connect a few tools
4. Send it a prompt

But what happens when you want 1,000 agents running across different customers? Each one needs to:

• Remember previous work
• Execute code
• Talk to other agents
• Pick up where it left off

That’s a very different engineering problem. I think the combination of Pi Durable, Cloudflare and open agent protocols is an interesting way to solve it.

1. Stop treating agents like always-on processes

Traditionally, running Pi as a service looks like this:

pi --mode rpc

How it works:

• Your application starts the Pi process
• It sends JSON commands over stdin
• It receives events over stdout

This works well when you control the machine. But on a multi-tenant platform, you also have to manage:

• Processes
• Sessions
• Persistence
• Crashes
• Scaling

Pi Durable takes a different approach:

• The agent loop runs inside Cloudflare Durable Objects
• Conversation history and execution state are persisted in SQLite
• No permanently running Linux process is needed just to remember previous work

Conceptually, the architecture becomes:

User
  |
Cloudflare Worker
  |
Durable Object
  |
Pi Durable
  |
SQLite session state

The key difference: compute and persistence are no longer tied to one long-running process.

2. Give the agent a computer without running it inside one

An agent needs more than an LLM. It needs to:

• Read files
• Write code
• Execute commands
• Install dependencies
• Test its work

That’s where Cloudflare Sandbox comes in. Instead of running the entire agent inside a Linux container, Pi Durable calls a sandbox through registered tools.

For example, Cloudflare’s Sandbox SDK exposes command execution:

import { getSandbox } from "@cloudflare/sandbox";

const sandbox = getSandbox(env.Sandbox, "gtm-workspace-123");

const result = await sandbox.exec("npm test");

console.log(result.stdout);

To wire it up:

1. Configure the sandbox binding and workspace in the Worker
2. Expose the operation to Pi as a custom tool

The result is a clean separation:

• Pi Durable → reasoning and conversation state
• Cloudflare Sandbox → code execution
• Your application → permissions and isolation

What this buys you:

• A sandbox can be restarted or replaced without losing the agent’s saved conversation
• But workspace files still need persisting separately: sandbox storage is not automatically permanent

3. Protocols make the agent interoperable

This is where ACP, MCP and A2A get interesting. They solve three different problems:

Protocol	Connects	Job
ACP	Application → agent	Controls the agent
MCP	Agent → tools	Gives it tools
A2A	Agent → agent	Lets it delegate work

ACP: application to agent

Zed’s Agent Client Protocol defines how an application controls a coding agent. For example, an ACP client can send:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "session/prompt",
  "params": {
    "sessionId": "gtm-agent-123",
    "prompt": [
      {
        "type": "text",
        "text": "build a hubspot enrichment workflow"
      }
    ]
  }
}

• You could build an ACP adapter that maps this request to a Pi Durable session
• Your own app, Zed or any other compatible client could then talk to the same agent runtime

MCP: agent to tools

MCP standardises how agents discover and invoke external tools. Say your GTM agent has access to a CRM integration. A tool call might look like:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_company",
    "arguments": {
      "domain": "example.com"
    }
  }
}

• The agent doesn’t implement the CRM API itself
• It calls a tool through a standardised interface

A2A: agent to agent

A2A handles delegation between independent agents. For example, your Pi agent might ask a LangGraph research agent to investigate a company. A simplified A2A JSON-RPC request:

{
  "jsonrpc": "2.0",
  "id": "research-1",
  "method": "message/send",
  "params": {
    "message": {
      "messageId": "msg-1",
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "research example.com's buying signals"
        }
      ]
    }
  }
}

• The remote agent does the research with its own models and tools
• Then it returns the result

The takeaway

• These aren’t interchangeable protocols. They’re different interfaces around the same runtime.
• None of them are built into Pi Durable. You need compatible adapters or integrations.

4. Agent memory and business memory are different problems

Where does context actually live?

Pi Durable persists conversation history and execution state in Durable Object SQLite. That’s useful for remembering what an agent did.

But a GTM engineering platform also needs to remember:

• Which companies match your ICP
• Who works at those companies
• Which technologies they use
• What buying signals you’ve detected
• Which campaigns you’ve already run
• What actually converted into pipeline

That shouldn’t all live inside an agent’s conversation history. I’d use Neon Postgres as the shared business database:

create table accounts (
  id uuid primary key,
  domain text unique not null,
  name text not null,
  icp_score integer,
  created_at timestamptz default now()
);

create table buying_signals (
  id uuid primary key,
  account_id uuid references accounts(id),
  signal_type text not null,
  description text,
  detected_at timestamptz default now()
);

Now multiple agents can access the same structured business data:

• Pi Durable remembers the work
• Postgres remembers the business

If relationships get complicated enough, you could add Graphiti for temporal knowledge graphs. But I’d start with Postgres before adding another memory system.

5. The real opportunity is agents that build workflows

This is where it gets particularly interesting for GTM engineering.

Today, most AI sales tools focus on:

• Researching accounts
• Enriching leads
• Generating outreach

Useful, but fairly constrained. What if a persistent agent could build the workflows themselves?

Imagine telling it:

“Find UK fintech companies hiring fraud engineers, enrich them, identify relevant decision-makers and create a campaign for approval.”

Instead of just returning a spreadsheet, the agent could:

1. Research the target market
2. Identify relevant data sources
3. Write an enrichment script
4. Execute and test it in Cloudflare Sandbox
5. Save qualified accounts to Postgres
6. Build a reusable workflow
7. Prepare outreach for human approval
8. Track results and improve the next experiment

Step 3 is the interesting part. The agent isn’t limited to workflows someone already built into the product. It can write code to create new ones.

A simple enrichment step could look like:

async function enrichAccount(domain: string) {
  const response = await fetch(
    `https://api.example.com/company?domain=${encodeURIComponent(domain)}`,
    {
      headers: {
        Authorization: `Bearer ${process.env.ENRICHMENT_API_KEY}`,
      },
    }
  );

  if (!response.ok) {
    throw new Error(`enrichment failed: ${response.status}`);
  }

  return response.json();
}

The API endpoint is illustrative, but the workflow is real:

1. Generate integration code
2. Test it in isolation
3. Validate the output
4. Only then promote it into a reusable automation

That’s a different product from an AI SDR. It’s closer to an autonomous GTM engineer.

6. Why Cloudflare matters

The main advantage isn’t faster LLM inference. Most of the latency in agent workflows comes from models, external APIs and tools.

Cloudflare is interesting because of how it handles the infrastructure around the agent:

• Durable Objects → persistent, individually addressable agent instances
• Sandboxes → isolated execution environments
• Workers → globally accessible APIs
• Queues and scheduled Workers → background workflow triggers
• R2 → storage for research artifacts and workspace snapshots

And you don’t need a permanently running server for every inactive agent.

The trade-offs:

• Pi Durable is still experimental
• Sandbox lifecycle management needs careful handling
• You’ll need proper authentication, tenant isolation, authorization and observability

But the architecture is compelling.

7. What I’d actually build

I’d start with a small GTM engineering platform built around four components:

                  Web app
                     |
              Cloudflare Worker
                     |
                Pi Durable
              Durable Object
                     |
          +----------+----------+
          |          |          |
       Sandbox      MCP       Postgres
          |          |          |
       Code       CRM/APIs    GTM data
       execution
                     |
               A2A agents
              (optional)

The first version wouldn’t need every protocol or a complex multi-agent system. Just one persistent Pi agent that can:

1. Research an account
2. Retrieve and update shared context
3. Write and test an enrichment workflow
4. Save the result
5. Resume the task later

Once that works:

• Add ACP for standardised clients
• Add A2A for delegating specialised tasks to external agents

The bigger picture

We’re moving from AI agents that complete individual prompts to agents that operate persistent systems.

The model is only one part of that. You also need:

• Memory
• Execution
• Recovery
• Tools
• Interoperability
• Governance

What makes Pi Durable on Cloudflare interesting is that it starts to separate those concerns into infrastructure you can actually build on.

For GTM engineering, that opens up something much more useful than automated prospecting: agents that can build, run and continuously improve the systems responsible for generating revenue.

That’s what I’m interested in building.