The next web could be a network of agents giving each other tasks

I imagine a link in an email. I open it, and my assistant understands that I need to arrange a shipment. It retrieves the data I have allowed it to use, finds the available services, and puts together a small interface with prices, delivery times, and terms. I choose, authorize it, and the work begins.

That interface might exist only for as long as it takes to complete the task. Behind it, three agents from different companies could be working together. I would still see a single operation, with a receipt and someone to ask for an explanation if the parcel disappears.

I have been thinking quite a lot about scenarios like this lately. I started looking back through the history of the Internet and the web, trying to understand which developments might reappear in the AI world. Common protocols, search engines, marketplaces, social networks, authorization between applications. Looking at them together, I am starting to see quite a few possibilities.

These are ideas I am still sorting out. Some pieces already exist; others are thoughts about how we might combine them.

The Internet allowed different networks to communicate. The web made publishing and linking documents simple. On top of that foundation, services grew that nobody could have designed all in advance. A shared protocol allowed someone on the other side of the world to add a piece without asking permission from the people who had built the others.

I see something similar in AI with MCP, which offers a common way to connect AI applications to tools and data. For collaboration, there are initiatives such as A2A, designed to let agents built with different technologies communicate.

The parallel that interests me is the possibility of building something that others can find and use. A small, specialized service could become useful to thousands of assistants without having to be built into every one of them.

And that gets me thinking about how a website might change.

A restaurant could publish its menu for us and, alongside it, a description of the operations available to agents: check for a table, ask about allergens, propose a booking, cancel it under certain conditions. A shipping company could do the same with quotes and shipments.

The agent would have an explicit entry point, with structured data, terms, and permissions. The website would still tell people about the business, but it would also become a place that other systems can work with.

And perhaps the link itself could evolve: from a connection to a page into a connection to an intent.

“Arrange this shipment.” “Compare this quote.” “Help me attend this event.”

Opening the link would give my assistant a prepared request. It could find the capabilities needed and build the most suitable interface for me. Authorization would remain a separate step: whoever sends me a link can suggest a task, but cannot decide on my behalf which data to use or how much to spend.

This is one of the combinations I find most intriguing: links to intents, small reusable capabilities, and temporary applications. I could end up with an app made for that one problem, assembled from different services and then archived along with the result.

At that point, the marketplace would take on another meaning too. I could look for a very specific capability: comparing technical documents, checking whether an application is complete, finding out whether a spare part is available. My agent could find it and suggest using it for a task.

Choosing would require concrete information: what data it needs, how much it costs, what results it promises, and how we can verify them. A convincing description would only be the starting point.

Then there are social networks. Moltbook already presents itself as a space where agents post, discuss, and vote. I naturally wonder how a space like that might evolve if it also became a place for collaboration.

One agent could post a request for help. Another could flag that a particular source has changed. A group could share a procedure that worked, along with the conditions under which it was tested. Specialized communities could form around problems, tools, and activities.

This is where reputation would become interesting. I would want to know which tasks an agent has completed, who verified the results, and how it behaved when something went wrong. And I would want to know which version of the agent that history refers to: changing the model, tools, or rules could change its behavior quite substantially.

I imagine reputation tied to verifiable experience in a specific area. Being reliable at classifying documents should not automatically translate into credibility for managing a budget.

But the further I take these scenarios, the more I come back to the same point.

How do we distribute authority within a network of intelligences?

OAuth has already given us a way to authorize applications to access certain resources. MCP already uses OAuth in its authorization system, and mechanisms such as OAuth Token Exchange also support delegation scenarios. So there are foundations to work with.

What I would like to explore is how to bring these ideas down to the individual task, as the work changes and passes between different parties.

Imagine I authorize an agent to organize a small event. It can look for a venue, compare suppliers, and spend up to a certain amount. It decides to bring in a catering specialist.

That collaboration should carry a readable, verifiable mandate: you may request quotes, you may share this information, you may commit this part of the budget, and your permission expires on Friday. Confirming an order above a certain threshold requires another approval.

If the specialist involves a third agent, the delegation must stay within the limits it received. The budget has to be accounted for along the entire chain. Creating five collaborators cannot create five copies of the available money.

And whoever receives the task must be able to accept it under their own rules. My agent should not be able to commit someone else's time or resources simply by sending them a request.

This is how I start to imagine a network of mandates, acceptances, and responsibilities, where every collaboration has a traceable origin.

People and organizations decide which powers to grant. The systems that control the resources verify those powers before carrying out actions. Agents can find solutions and propose new collaborations; when the scope of the task changes, the authorization must change explicitly too.

Services could emerge specifically to manage these delegations between organizations: verify who represents whom, enforce limits, propagate revocations, and keep receipts. Each organization would retain its own rules while sharing a common language for working with the others.

Above all, I want that control to remain usable by an ordinary person. I would like to open a screen and see: these agents are working for me, this data has been shared, these amounts have already been committed, and these decisions are waiting for an answer.

If I withdraw a task, the system should stop future activities that depend on that mandate and show me what has already happened. An order that has already been confirmed might require a separate cancellation. Revocation needs a precise meaning, understandable even when it cannot undo the past.

That brings me to another idea I am exploring: groups of agents able to present themselves to the outside world as a single point of contact.

Ten agents might work on organizing the event, perhaps using different models. I give a task to the group and receive a result from the group. Inside, they can divide the work, replace a component, or bring in a specialist.

This is a direction I connect with the Governed Holon Model: an entity can be a collection of parts and, in turn, participate in a larger whole. Making that work requires clear boundaries around who can commit the group and which obligations remain open when its composition changes.

If I replace the model coordinating the work tomorrow, the accepted quotes must still be there. If a process restarts while waiting for an order confirmation, that uncertainty must survive. Someone still needs to deal with it.

A handover to a person should preserve that continuity too. I would want an operator to receive the documents, previous attempts, open issues, and authorizations that are still valid. Having to start again with “can you explain what happened?” every time would be a real missed opportunity.

To make all of this verifiable, I imagine records tied to actions, with receipts from both sides. I authorized this request, you accepted these terms, and the service returned this outcome. If the accounts do not match, the difference stays visible and has to be resolved.

This is also where I see a possible role for blockchain.

Across different organizations, it could be useful to anchor evidence of authorizations, agreements, and receipts to a shared ledger. I would keep conversations and confidential documents off the chain; what goes on it could be the cryptographic fingerprints needed to verify that certain records have not been changed.

I would choose it where that shared verification is actually needed. In other cases, a signed log would be enough. And in both cases, one practical distinction remains: a receipt can prove what was recorded, but permission to act has to be checked before the action. Even a mistake can be recorded perfectly.

Before granting those permissions, I would also want a preview. Some kind of task simulator: which agents would be involved, which data would leave, what budget would be committed, and where my intervention would be needed.

The actual plan could change, of course. But that preview would help me understand what I am authorizing. And if the work turns out to require going beyond the agreed limits, the system would have a specific reason to come back to me.

The same would apply to goals that last over time. I could ask an agent to follow an issue for weeks, preserving state, decisions, and open questions. The goal would continue to exist even when I close the chat. Its permissions, meanwhile, should have their own expiry dates and conditions.

This whole set of possibilities is making me look at AI differently. I can imagine search engines for capabilities, applications that assemble around a task, communities of agents, temporary groups, and services that make their collaborations verifiable.

With Spectre and the Governed Act Model, I am trying to work on one part of this problem: the transition between what an intelligence proposes and what it has the power to do. Extending that thinking to a network of different parties opens up quite a few more questions.

One of them keeps coming back to me: if, a few years from now, my assistant hands work to an agent I do not know, hosted on a system I have never used, what evidence will I need to accept that collaboration?

I would like to reach a point where I can do that as naturally as I open a link today. Knowing where my authorization leads, how far it can travel, and who still owes me an answer when something is left unfinished.