Edge and cloud IoT responsibilities

Put at the edge what must keep working when central services are unreachable; run centrally what can wait for a connection. Apply the method by naming the continuity requirement, separating inference from agent authority, and recording the result as a responsibility table with normal, disconnected and recovery states. "Edge" and "cloud" name locations, not responsibilities.

Name the continuity requirement

List the functions that must survive a lost connection: collecting measurements, running the accepted control logic, maintaining defined safety behaviour, buffering data for delivery. For each, state its dependencies and their failure behaviour. Mainstream runtimes follow this division: AWS IoT Greengrass lets devices act locally on the data they generate and react to local events AWS IoT Greengrass; Azure IoT Edge exists because not all analytics need to be in the cloud — anomaly detection runs next to production-line equipment, and raw telemetry is cleaned and aggregated locally Azure IoT Edge.

What stays central

Analysis over aggregated data. Fleet-scale operations — deploying, configuring and monitoring devices; Azure documentation is explicit that these can't be done on a per-device basis and must be done at scale Azure IoT Edge. And agentic engineering work: investigation, code changes, integrating new components. Waiting work should stay visible and recoverable, not disguised as a successful run.

Separate inference from agent authority

A model evaluating an input and an agent holding tools are different capabilities. Inference answers a question about a measurement; an agent can investigate, write software or request changes — granting that authority to an unattended edge node is a different kind of decision. A defensible default keeps edge nodes deterministic with fixed reviewable behaviour and agent orchestration central; model packs run on nodes only where latency, privacy or offline operation justify them. Treat it as a choice to evaluate, not a rule.

Draw the failure boundary

For every responsibility, write down three states: normal, disconnected and recovery. Public documentation shows why the last two deserve care. Azure IoT Edge buffers upstream messages and delivers them in order after reconnect, but storage depends on a time-to-live setting and disk space, and a disconnected device cannot update its reported status — the console may keep showing the last "OK" Azure IoT Edge offline capabilities. Two rules follow: connectivity and freshness are different health conditions — a returned heartbeat must not clear a stale-data alarm; and expiry during an outage is a design-time decision, because a command issued while the operator believed the system was connected may be unsafe after reconnect.

The deliverable is the table: functions as rows, the three states plus each function's authority as columns. Reviewed by operating and engineering owners, it turns architecture talk into checkable statements instead of hosting preferences.

Placement, connectivity and authority are separate choices

"Central" describes a control-plane role, not a data-centre address: a central service can itself be site-local or remotely hosted, and in a small installation one box can hold both roles. Keep three questions apart: where the code runs (placement), where the service physically lives (hosting), what the code is allowed to do (authority).

How MIND AIoT applies this split

MIND AIoT is designed around exactly this division: deterministic local operation — collection, accepted control, safety behaviour, buffering — continues at the edge, while agentic engineering work runs centrally; local inference runs from model packs without general agent authority. That is a design principle, not a performance or availability promise. Servers can be hosted by Manna or deployed on your premises MIND AIoT. To have this boundary drawn and reviewed for your installation, discuss your project.

Prepared with AI assistance for Manna Insect Oy.