The Internet Was Never Supposed to Stop at Devices
Devices are connected. The work still isn't.
The architecture running most IoT deployments today looks like this:
device → cloud → deviceThe plot: three plots, one cooperative, a shared irrigation borehole.
In Manicaland, a plot is typically one to three acres of land, worked by a family and often pooled into a cooperative. The infrastructure serving it needs to match that reality.
Plot A's soil sensor in Odzi in Manicaland reads critical moisture deficit at 6am. The reading travels to a cloud platform in Frankfurt. The platform processes it and returns an irrigation instruction, unaware that Plot B's sensor triggered the same sequence three minutes earlier. The borehole can't serve both simultaneously. The cloud platform doesn't know that. Neither instruction knows the other exists.
By the time a cooperative member notices, two hours of morning irrigation window are gone.
This isn't a connectivity failure. The connectivity worked fine. It's a coordination failure, and it's baked into the architecture itself.
The question worth asking is not how to make this pattern more reliable. The question is whether it's the right pattern at all.
Coordination Has Always Evolved
The internet has never been static. Its fundamental unit of coordination has shifted before, and may be shifting again, before the last shift has even fully settled.
┌─────────────────────────────────────────────┐
│ PHASE 1 — HOST INTERNET │
│ │
│ Computer ◄──────────────► Computer │
│ │
│ Focus: networked machines │
│ Technologies: TCP/IP, DNS, HTTP │
└─────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ PHASE 2 — SERVICE INTERNET │
│ │
│ Service ◄──────────────► Service │
│ │
│ Focus: APIs and cloud functions │
│ Technologies: REST, microservices, OAuth │
└─────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ PHASE 3 — THING INTERNET │
│ │
│ Device ◄──────────────► Device │
│ │
│ Focus: connected physical infrastructure │
│ Technologies: MQTT, CoAP, edge nodes │
│ Research direction: IRTF T2TRG │
└─────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ PHASE 4 — CAPABILITY INTERNET │
│ │
│ capability: soil_moisture_reading │
│ ◄──────────────► │
│ capability: water_delivery_control │
│ │
│ Focus: discoverable functions │
│ coordinated by autonomous systems │
│ Technologies: MCP (emerging) │
└─────────────────────────────────────────────┘Phase 1 connected machines. Phase 2 abstracted machines into services. Phase 3 pushed services out to devices.
Phase 4 is the architectural thesis this article is making: the coordination unit shifts again, from devices to capabilities.
This is not a prediction. It's a design direction, one that becomes easier to imagine when read alongside the Thing-to-Thing Research Group's work on constrained-node communication, REST/pub-sub interaction models, lifecycle management, and multi-stakeholder operation, and one that becomes practically necessary the moment autonomous agents need to operate across distributed infrastructure they didn't design and don't fully control.
What Changes When Capabilities Are the Unit
In a device-centric model, a system asks:
Which device should I contact?In a capability-centric model, it asks:
Who can perform this function?The difference is subtle but architectural. Device addresses are fixed. Capabilities are discoverable. Any node that can perform soil.moisture_reading can respond, whether that's a sensor network in one field or a different one three kilometers away.
This matters most when infrastructure spans organizational boundaries, where an agent coordinating across three plots in a cooperative shouldn't need to know each plot's specific device topology. A capability-oriented system scales across that heterogeneity without requiring custom integrations at every boundary.
The functions that matter at the agricultural edge look like this:
soil.moisture_reading
pest_detection
weather_analysis
water_delivery
crop_health_assessment
drone_navigationEach is a capability, a thing a system can do, not a device identifier. The network becomes a registry of functions, not just addresses.
This pattern is already working at the software layer. The Model Context Protocol (MCP), an open standard now governed by the Linux Foundation under the Agentic AI Foundation, is a live software-layer example of capability discovery and invocation: servers expose named tools, prompts, and resources, and clients discover and call them at runtime without knowing the underlying implementation. The protocol is not without its critics: Perplexity CTO Denis Yarats announced Perplexity is moving away from it citing context overhead at scale, and OpenClaw creator Peter Steinberger put it bluntly: "MCP were a mistake. Bash is better." Their objections are real, schema loading is expensive and security vulnerabilities in naive implementations are well documented. But the critics are arguing about the transport layer, not the model beneath it. Whether the mechanism is MCP, a CLI, or something not yet built, the underlying shift is the same: agents discovering and invoking capabilities they weren't explicitly programmed to call. MCP shows that this style of discovery-and-invocation can work at the software layer, even as the protocol and its security practices continue to mature. The question EdgeChain is asking is whether the same model can extend downward, from AI tool integrations into physical infrastructure, where the capabilities aren't data queries but real-world actions: water delivery, soil sensing, crop analysis.
The Agent as Orchestrator
Here is where the architecture becomes interesting.
Consider a smallholder farm in Chipinge, Manicaland, during the onset of the rainy season. An edge node running local AI has been tasked with a single objective: maintain optimal soil moisture across three plots during the transition period.
Under a device-centric model, achieving this requires pre-programmed integrations, fixed routes between specific sensor IDs and specific pump controllers. When the hardware changes, the integrations break.
Under a capability model, an autonomous agent works differently:
1. Query: who can provide soil_moisture_reading for plot_A?
→ Sensor cluster 3 responds. Capability confirmed.
2. Query: who can provide weather_forecast for next 48hrs?
→ Local edge model responds. Capability confirmed.
3. Analysis: moisture at 34%, rain probability 71% by day 2
→ Decision: delay irrigation, re-assess in 6 hours.
4. Query: who can provide water_delivery for plot_A if needed?
→ Pump controller responds. Capability registered.
→ Standby instruction issued.The agent didn't need to know the device addresses in advance. It discovered what was available, reasoned across the inputs, and made a bounded decision.
None of the individual steps here are exotic. What is new is the infrastructure model that makes them composable across heterogeneous edge systems. The novelty is in the infrastructure model, not the AI.
Edge nodes stop being passive data collectors. They become capability providers, active participants in a distributed coordination network.
The Governance Layer Is Not Optional
This is where most architectural discussions about autonomous systems quietly look away.
If agents are discovering and invoking capabilities across organizational boundaries, across different plots, cooperatives, and infrastructure providers, three questions become non-negotiable:
Who can access a capability? Not every agent should be able to invoke water_delivery. Access control likely needs technical enforcement, not just policy documents. In resource-constrained environments, unauthorized invocations aren't just security failures, they're physical ones.
How do systems trust each other without revealing what they're doing? A cooperative sharing crop health data with a regional water authority has legitimate privacy concerns. The authority needs to verify the data is valid; the cooperative needs to ensure its field conditions aren't exposed to competitors. Many common identity systems make privacy-preserving verification awkward or operationally expensive. That's a bad tradeoff for agricultural communities where data asymmetries already disadvantage smallholder farmers.
How are resources allocated when multiple agents compete for the same capability? water_delivery is a finite resource. An allocation model that works at human timescales doesn't necessarily work when agents are negotiating in milliseconds.
These aren't governance questions that can be deferred until the infrastructure matures. They shape what infrastructure gets built.
Midnight is relevant here because its zero-knowledge and selective-disclosure model is designed to support privacy-preserving verification without full data exposure, a capability provider can verify that a requesting agent is authorized without learning who the agent is or what it's doing. That makes it an interesting candidate substrate for capability authorization in systems like EdgeChain. In the EdgeChain design, a registration-and-claims layer manages capability advertisement and access rights. NIGHT and DUST tokens separate governance rights from operational transactions, which could make operational costs more separable from governance and capital exposure in machine-to-machine settings.
This matters specifically for agricultural edge infrastructure. A smallholder cooperative shouldn't need to expose its operational data to participate in a shared capability network. Privacy-preserving access control isn't a luxury feature, it's the condition under which the network becomes trustworthy enough to use.
EdgeChain: Building Toward It
The EdgeChain project is a practical attempt to instantiate this architecture for agricultural infrastructure in Southern Africa.
In the target EdgeChain model, a plot node exposes capabilities, not just data streams:
soil.moisture_reading → available, verified, priced in DUST
pest_detection → available, model v2.1, priced in DUST
water_delivery → available, capacity: 40L/min, priced in DUST
crop_health_assessment → available, requires drone_data inputAutonomous agents, local or remote, discover these capabilities through the network, negotiate access via the Midnight layer, and coordinate actions without requiring a central cloud intermediary.
The goal isn't to replace the farmer's judgment. It's to give that judgment better inputs, coordinated faster, from infrastructure that the farming community controls.
The Architectural Argument
The shift from device-centric to capability-centric coordination isn't inevitable. But it is necessary if autonomous systems are going to operate reliably at the edge.
Fixed device integrations are brittle. Cloud dependency is a single point of failure for communities where connectivity is intermittent. Centralized control is a governance model that concentrates power away from the people the infrastructure is meant to serve.
Capability-oriented systems may reduce many of these constraints by design, while creating new requirements around discovery, semantics, security, and governance worth taking seriously.
The Internet of Things gave us connected devices. The next layer gives us connected functions.
The infrastructure that matters most, in Manicaland, in rural Mozambique, in every place the cloud abstraction has never quite reached, needs to be built on that foundation.
Not eventually. Now.
Solomon Kembo explores Physical AI/Edge AI infrastructure for the agentic economy. Follow the journey at disruptiveiot.org or connect on LinkedIn.