AI Agents Need Tiny, Trusted Operations

Cloudflare is building infrastructure for an Internet used by AI agents. We think those agents also need a simple way to find and run tools they can trust.

AI agents are moving beyond chat.

They can browse websites, write code, call APIs, update databases, and make changes to real systems.

That creates a new problem: what happens when one agent has hundreds or thousands of tools?

The common answer is to describe every tool to the AI model and ask it to choose. But every description uses context. Similar tools are easy to confuse. Larger prompts cost more. And a wrong choice can cause a real action.

Agents do not only need more tools. They need a better way to:

1. Find the right tool.
2. Understand what it can do.
3. Check who published it.
4. See what data and credentials it needs.
5. Run it under clear limits.

This is the problem we are exploring with Picoo.

Why Cloudflare’s agent push matters

Cloudflare’s recent launches make the agentic Internet feel real.

Its Agents platform now brings together agent state, scheduling, browsers, sandboxes, MCP connections, AI models, and payments. Cloudflare describes the larger direction in its Agents Week recap.

Cloudflare is also working on the money layer. Its planned Monetization Gateway will let websites charge agents for content, data, APIs, and MCP tools. Cloudflare Wallets gives agents a controlled way to spend money.

The basic flow looks like this:

Find a tool → check it → run it → pay if needed → keep a receipt

Cloudflare can provide global compute, identity, connectivity, and payments. But agents still need a portable way to find and run small, trusted operations.

That is where Picoo fits.

Too many tool descriptions become noise

MCP, the Model Context Protocol, gives AI applications a common way to connect to tools. It is a useful standard.

But a large tool catalog still has to be shown to the model somehow.

If every tool description is added to every request:

• The model reads lots of text it does not need.
• Similar tools compete with each other.
• Smaller models have a harder time choosing.
• Every request becomes more expensive.
• It becomes harder for people to review permissions.

Many possible schemas create noise. One selected contract gives the model a smaller decision.

Cloudflare uses a similar idea in its own API MCP server. Instead of placing more than 2,500 API tools into the prompt, it gives the model two tools: search() and execute().

Cloudflare says this interface needs roughly 1,000 tokens. Loading all native schemas would need more than one million. The details are in Cloudflare’s MCP server guide.

The lesson is simple:

Search first. Show the chosen contract second.

How Picoo works

Picoo is a small, local-first operation runner for AI agents.

An operation, or op, does one clear job. It might create a GitHub issue, resize an image, query a service, or publish a draft.

Instead of showing the model a whole registry, Picoo:

1. Searches for the operation that matches the task.
2. Shows the model one small input and output contract.
3. Checks the allowed operation, network, and authentication rules.
4. Runs the operation locally.

Operation names are easy to read:

publisher/application/operation

picoo/github/create-issue

Each operation has a small program and a picoo.toml manifest. The manifest says what the operation needs and what it returns. It names required secrets, but never stores their values.

The model can understand the action without seeing unrelated tools or credentials.

What our first test found

We ran a generated 1,000-task test.

In the Picoo condition, the model received one selected operation contract. In the comparison, it received all 13 tool schemas.

We found:

• 73.6% fewer total tokens with Picoo.
• 86.0% fewer input tokens.
• 89.8% strict success with Picoo.
• 35.3% strict success with the full tool registry.

We also compared eight models. Picoo used fewer tokens with every model in that smaller matched test.

You can read the method and full limitations in What smaller tool prompts change.

This test does not prove that Picoo beats every modern MCP client. The tasks were generated. The main run used one local model. We did not compare every kind of dynamic tool loading.

The result supports one clear claim:

When the alternative loads a full tool registry, selecting one small contract first uses far fewer tokens.

Trust matters more than token savings

Lower token use is helpful. But trust is the bigger long-term problem.

Imagine an agent finds ten tools that all claim to create an issue or return a shipping price. Before using one, it should know:

• Who published it?
• Is this the exact approved version?
• Which websites can it contact?
• Which credentials does it need?
• Can it change outside systems?
• Can an organization block or remove it?
• What did it actually run?

A small contract is useful only when the package, publisher, and permissions can be checked.

Picoo’s Registry supports fixed versions, package hashes, publisher signatures, and operator-controlled trust labels.

Picoo’s security model separates three things:

• The agent’s own login.
• Access to the Picoo Registry.
• Credentials needed by an operation.

Operations declare the network hosts and secret names they need. Unrelated secrets are not passed to them. An MCP server can require separate allowlists for the operation, network, and authentication provider.

A signature does not prove that code is safe. It does prove that a package matches what a known key signed. That gives people a stable version to test, approve, and later block if needed.

Why local execution helps

Many operations are best run where the user’s files and credentials already live.

Local execution can mean:

• Less private data sent to another service.
• Direct access to approved local files.
• No cost for an idle cloud machine.
• Workflows that run offline with fixed versions.
• A clearer boundary between the AI model and secret values.

Some tasks still need a remote computer or a full Linux environment. Cloudflare Computer and Sandboxes are useful examples.

Picoo does not need to force one choice. An operation could run locally by default and move to an approved remote sandbox when the job needs it.

The future: operations that can be paid

Once an operation is easy to find, check, and run, it can also connect to a paid resource.

The operation package might be free and open source. The API or dataset behind it could charge for each useful result.

An agent may pay for one useful result instead of opening an account and buying a large subscription.

For example, an agent could find an operation that returns a verified shipping rate. Picoo could show the price and permissions. The company could apply a spending limit. After the call, Picoo could keep the operation version and payment receipt together.

Cloudflare’s payment tools could support that transaction. Picoo would remain independent: its job would be discovery, trust, policy, and portable execution.

We are not starting with payments. First, the ecosystem needs useful operations that behave as promised.

What we are building next

Our next steps are practical:

1. Add more small, useful operations.
2. Make Picoo easy to connect to popular AI agents.
3. Test it against modern MCP tool-loading systems.
4. Improve verification, sandboxing, and permission review.
5. Explore private registries for teams.
6. Add payment rules only when users need them.

We believe agents need something like a trusted package manager and policy layer for actions.

Cloudflare’s recent launches make the timing clear. Software is starting to read, discover, call, and pay for things on the web.

The next question is whether those actions will also be easy to understand, portable, and safe to trust.

That is where we want Picoo to help.

Try Picoo

• Follow the Picoo quick start.
• Learn how operations work.
• Read the research and limitations.
• Review Registry trust and operation security.

Picoo is an independent open-source project and is not affiliated with Cloudflare.