The Internet of Agents

We connected the devices. We did not connect the decisions.

That is the gap I keep running into. A city installs air-quality monitors, traffic sensors, transit telemetry, surveillance cameras, citizen-report apps. An enterprise installs a CRM, an ERP, a ticketing system, a logistics platform, and lately a different AI assistant bolted onto each one. The data exists. The wiring exists. What does not exist is a layer where those systems talk to each other, reason together, and act in concert without a human stitching the reports by hand at 9pm.

The Internet of Things gave us the nodes. The Internet of Agents is the missing layer above it: a network where the nodes are not just data sources but intelligent agents that perceive context, communicate, and collaborate to get something done. This is a blueprint for that layer. More structure, less story.

The problem is coordination, not data

Most “smart” deployments fail in the same place, and it is not for lack of information. It is the opposite.

In a typical city, transportation, utilities, public safety, and planning each run on separate systems that do not speak. Traffic cameras, transit cameras, and private retail cameras sit in isolation, each useful, none combined. A leader who wants a holistic view of what is happening across the city has to assemble it manually, department by department, which means the view is always late. Meanwhile the sensors keep producing more raw data than anyone can filter into a decision. The result is reactive governance: the intervention always trails the problem.

Enterprises break the same way along different lines. Sales reads the CRM, finance reads the ERP, support reads the tickets, and aligning those three views is somebody’s full-time job. Surveys keep finding the same thing. In Oracle’s global Decision Dilemma study, 86 percent of people said the sheer volume of data was making their decisions more complicated, and 70 percent admitted they had, at some point, simply given up on a decision because the data felt too overwhelming. More information made the decision harder, not easier.

We did not have a data problem. We had a coordination problem wearing a data problem’s clothes.

There is a newer failure mode on top of all this, and it is worth naming because it is arriving fast. Call it agent sprawl. As AI assistants get embedded into every tool, organizations are ending up with dozens of isolated agents, one per application, none of which talk to the others. Each is only as smart as its own app’s slice of data. A sales assistant reports glowing satisfaction from pre-sale chats while a separate support assistant is drowning in post-sale complaints, and because nothing connects them, the organization gets two confident, contradictory answers. Adding more disconnected agents does not add intelligence. It adds noise.

What the architecture actually is

The Internet of Agents proposes one structural move: instead of isolated systems and single-task bots, you put a web of communicating agents on top of the infrastructure you already have.

Every major subsystem (a traffic-signal network, a sensor grid, a CRM, a legacy database) gets an autonomous agent that can sense, decide, learn, and, critically, talk to other agents through a shared protocol. The agents are not standalone. They are interlinked, which is the whole point. The design rests on three principles:

• Decentralization. Many specialized agents work on parts of a problem in parallel and share results, instead of funneling everything to one monolithic brain. Decisions stop bottlenecking at a single point.
• Interoperability. Heterogeneity is treated as a feature, not a defect. Agents built in different languages, by different vendors, for different jobs still understand each other through an agreed interaction standard. You do not rip out and replace existing systems. You give them voices.
• Collaboration. This is more than orchestration. An agent can open a conversation, form an ad-hoc coalition to chase a goal, negotiate to resolve a conflict, and reconfigure a workflow on the fly when conditions change.

The cleanest analogy is the original internet. TCP/IP let disparate networks exchange data through common protocols. The Internet of Agents lets disparate AI and automation systems exchange knowledge through agent-communication protocols. Traditional automation handles a workflow inside one system. A conventional model is trained for one domain. This layer composes tasks and knowledge across domains, dynamically.

The practical consequence is the inversion of agent sprawl. Instead of five assistants pelting a user with five disconnected alerts, the assistants reconcile their findings with each other first and present one coordinated insight. The sales agent learns from the support agent that complaints are spiking, and it is the sales agent that proactively flags the product manager. That cross-application insight either required manual integration before, or it never happened at all.

One more property matters at the architecture level: the value compounds. Like the original internet, the worth of a connected agent network rises with each node added, closer to Metcalfe’s Law than to the diminishing returns you get from bolting on yet another isolated point solution.

How it behaves in the field

Two domains make the behavior concrete.

A city that coordinates itself. Take traffic. In the conventional setup a signal runs on a timer or reacts to its own local sensor, blind to everything past the intersection. Give each intersection an agent that adjusts locally and talks to its neighbors and talks to a city-wide flow agent, and you get genuine city-scale optimization. Multi-agent control of traffic signals has cut average vehicle wait times by more than half against fixed-timing systems in simulation studies. Fewer idling cars, less wasted fuel, lower emissions, all from coordination rather than new hardware.

Now extend it. An accident lands on a main artery. An incident agent in the traffic system detects it and tells nearby signal agents to divert flow, while a transit agent raises bus frequency in the affected zone and an emergency-services agent clears a corridor for ambulances. That entire sequence runs in seconds through agent-to-agent collaboration, faster than any human-mediated chain could move.

The same shape covers situational awareness. An environmental agent notices air quality dropping in a district, consults a traffic agent, finds the correlation with congestion, and together they nudge a planning agent toward a temporary low-emission zone while a public-health agent puts hospitals on alert. Public safety follows the same logic: in one large American city, police linked to live video feeds from hundreds of private businesses through a central real-time crime center, an arrangement associated with reported drops in crime, though independent evaluations have been more cautious about how much the cameras themselves changed violent crime. That was a primitive version of this architecture, cameras feeding an aggregator. The full version lets the cameras run their own detection and hand off to dispatch agents automatically.

An enterprise that notices. The headline use case is making the business self-aware. Instead of discovering a problem at the quarterly review after someone manually collates the reports, each domain runs an agent that continuously generates insight and shares the relevant signals sideways. The sales-pipeline agent spots an unusual drop in conversions, queries the support agent, learns complaints for that product are spiking, and the two of them escalate to a product agent in real time. The enterprise behaves like an always-on analytics team that correlates across silos and surfaces the narrative that matters.

Supply chains are the other natural fit, because they are coordination problems by definition. Give every node an agent. A flood closes a supplier’s plant; that plant’s agent alerts every downstream agent instantly, an alternate-supplier agent offers available stock, and logistics agents reroute shipments through a web of machine-to-machine agreements. A global e-commerce giant already runs this kind of networked automation inside its own walls. The architecture’s promise is extending that coordination past the corporate boundary, to suppliers and distributors, on a shared protocol.

The same pattern is showing up in early multi-agent deployments. Agent-based handling of insurance appeals has been reported to compress case-processing time, and multi-agent analysis of earnings calls has been used to speed up report generation. These are not magic. They come from specialized agents handling parts of a workflow in parallel and aggregating the result.

None of this replaces the human. It augments. The agents absorb the grunt work of digestion, cross-checking, and first-line decisions, which frees people for the creative, strategic, and ethical calls. The mature picture is a command center where officials supervise a swarm doing the heavy lifting underneath.

The layers, from the inside

If you are going to build this, you build it in three layers. Keeping the concerns separate is what lets it scale.

Agent layer (intelligence). The top layer is the agents themselves, each carrying its own logic, goals, and a model of the slice of world it owns. In a smart building you might have an HVAC agent, a lighting agent, a security agent. Each senses its data, runs its rules or models, executes actions, and emits messages to others. This is where digital twins live. An agent typically holds a twin, a synchronized model of the physical asset or system it represents: a traffic agent with a live twin of densities and signal states, a machine agent with a twin of its temperature, load, and maintenance history. Twins give agents a consistent way to reason about reality and to run safe “what-if” simulations before acting. Agents can also be hierarchical, with low-level device agents reporting to supervisory agents above them. That hierarchy has to be designed per domain, not assumed.

Communication layer (the narrow waist). This is the defining piece, and it is worth borrowing the internet’s own term for it: the narrow waist. It is the agent-communication platform that connects every agent regardless of how each one is built internally, the way TCP/IP connects machines that share nothing else. This layer carries three functions:

• Discovery. A registry where agents advertise their capabilities so others can find the service or data they need, conceptually close to DNS or service discovery.
• Messaging and routing. Delivering messages from one agent to another, across networks, including group conversations and broadcast.
• Semantics. Shared languages or ontologies so the content of a message means the same thing to sender and receiver.

The discipline here is that this layer separates how agents talk from what they do. An accounting agent and a traffic-light agent use the same messaging fabric even though their domains share nothing. That separation is exactly what lets the network absorb heterogeneous systems and survive agents joining, leaving, or spiking in volume. Any teaming and negotiation logic (electing a lead agent, forming a coalition, reaching consensus) lives here too.

Infrastructure layer (compute and trust). Underneath sits the enabling foundation: cloud and edge compute, storage, networking, and security. Heavy agents (a city-wide traffic optimizer running simulations) want accelerators in the cloud. Time-critical agents (a single signal making real-time calls) want to run at the edge for low latency. This layer also carries identity, access control, and audit logging, which together form the backbone of trust. It answers the uncomfortable question: can any agent just join and start talking, and if not, how do we keep impostors out and eavesdroppers blind. Serious designs lean toward zero-trust, where every agent continuously authenticates and no message is trusted by default, often paired with reputation systems that score agent behavior over time and, given the time horizons involved, quantum-resistant cryptography for anything that has to stay secret for the long haul.

Trust is a first-class problem

When agents take autonomous action over traffic, power, or money, security is not a feature you append. It is load-bearing.

The framework has to cover authentication (proving an agent is who it claims), authorization (bounding what it is allowed to touch), confidentiality and integrity (encrypting messages, preventing tampering), and resilience (detecting and recovering from a compromised or buggy agent). The wrinkle unique to this architecture is churn: agents representing devices or third-party services join and leave constantly, so trust has to be validated continuously, not granted once at the door.

The interesting designs borrow from biology and from distributed systems. Self-healing means the network can isolate or repair a faulty agent automatically. If an agent starts behaving erratically, a monitoring agent flags the anomaly and quarantines its access, an autonomous immune response. Self-protection means agents collectively vet a dangerous instruction before any one of them executes it, a kind of multi-party consensus for high-stakes actions. Sitting alongside all of this is governance: policy engines that intercept agent actions to enforce rules, so a health-data agent anonymizes before it tells a planning agent anything about hospital admissions. Ethics and compliance, in this architecture, are just another layer of security in the broad sense.

The rollout

This is not a switch you flip. It is a phased transformation, and the phasing is what de-risks it.

• Explore and scope. Map the real pain points and pick a high-impact one. Inventory the data sources, existing sensors, and AI capabilities an agent could stand on. Set a concrete pilot objective, for example “cut incident response time by 20 percent,” and form a small steering group that includes business, IT, and, for public deployments, a public representative.
• Pilot. Build a narrow proof of concept: one district, one department, five to ten agents. Stand up the real plumbing (a message broker, a directory service, a sandbox) and design security in from day one with agent credentials and encrypted channels. Build the digital twin the agents will reason over. Put real users in the loop and iterate on the agents’ decision rules against test scenarios.
• Evaluate. Run it for weeks, then measure against the criteria you set. Collect the hard metrics and the human feedback. Stress-test scalability and let the security team run penetration tests now, while the blast radius is small. End on an honest go or no-go.
• Expand. Scale deliberately, one district or one department at a time, never everything at once. The non-negotiable here is interoperability: every new agent must speak the established protocol so it plugs in cleanly. Build adapters that let legacy systems join as agents. Watch the ROI sharpen as small gains across many areas compound.
• Integrate and optimize. Once agents reach into most systems, the work shifts to monitoring, maintenance, and governance. Stand up dashboards for agent health and activity. Consider a thin layer of oversight agents that enforce global policy, the way the internet has backbone routing and root servers. Define exactly when and how a human overrides the swarm.
• Evolve. Treat the whole thing as a living system. Retrain learning agents on fresh data, add new agent types as needs appear, track the emerging standards bodies, and keep patching the security posture as threats move. Done right, the agent layer becomes infrastructure, as unremarkable and as essential as the cloud.

The throughline across all six phases is the same: start with a clear value objective, secure executive sponsorship, think big but start small, prove value before you scale, and treat the human factors (training, trust, comfort with autonomy) as seriously as the technical ones.

Why now

The original internet did for information what this layer can do for action. We are about to deploy generative AI almost everywhere: Gartner projects that more than 80 percent of enterprises will have used generative-AI APIs or deployed generative-AI applications by 2026, up from under 5 percent in 2023. Those deployments will return far more if they are not standalone bots but nodes in a connected agent network, because that is where the value compounds instead of fragmenting.

The honest framing is not hype. It is a warning and an opportunity in the same breath. A city that runs this layer anticipates and responds where a siloed one reacts and lags. An enterprise that runs it moves with an integrated intelligence that disconnected competitors cannot match. The blueprint is firming up fast: the layers are understood, early frameworks exist, the protocols are converging.

We already connected the devices. The next build is connecting the decisions. That is the whole job.

---

Related reading: Perspective AI - the same decentralization instinct turned on intelligence itself, a marketplace of models where no single company holds the off switch.

References

1. Oracle (2023). “The Decision Dilemma” (global study of 14,000+ employees and business leaders across 17 countries). https://www.prnewswire.com/news-releases/global-study-70-of-business-leaders-would-prefer-a-robot-to-make-their-decisions-301799591.html
2. Mahato, S. (2025). “Multi-agent Reinforcement Learning vs. Fixed-Time Control for Traffic Signal Optimization: A Simulation Study.” arXiv 2505.14544. https://arxiv.org/abs/2505.14544
3. National Institute of Justice (2023). “Program Profile: Project Green Light Detroit.” CrimeSolutions, Office of Justice Programs. https://crimesolutions.ojp.gov/project-green-light-detroit
4. Gartner (2023). “Gartner Says More Than 80% of Enterprises Will Have Used Generative AI APIs or Deployed Generative AI-Enabled Applications by 2026.” https://www.gartner.com/en/newsroom/press-releases/2023-10-11-gartner-says-more-than-80-percent-of-enterprises-will-have-used-generative-ai-apis-or-deployed-generative-ai-enabled-applications-by-2026