One kernel for agents, robots and devices

A rule that says who may release a pallet should hold whether the pallet is released by a person tapping a screen, by an agent reconciling an order, or by a machine lifting it off a rack. Today those three paths run through three different systems with three different permission models, and the rule exists three times — which means it is wrong in at least one of them.

Three bodies, one set of questions

Software agents, physical robots and personal devices look like different engineering problems, and at the bottom of the stack they are. Motion planning has nothing in common with invoice reconciliation.

But every one of them has to answer the same four questions before it does anything that touches the business:

Who am I acting for? What am I permitted to do right now? What are my current limits? And what evidence do I leave behind?

Those are not robotics questions or agent questions. They are operating system questions, and answering them separately in each domain is how organisations end up with a warehouse robot that respects safety limits but has no idea about the customer’s credit hold.

What “one kernel” actually means

Not one binary running on a picking robot and a server. The parts that must be shared are narrower and more important than that.

Identity. One notion of who an actor is, human or otherwise, and on whose authority it operates. A device in someone’s pocket acting as their delegate should be as legible to the system as their login.

Policy. The rule about who may release a pallet is written once, evaluated by the same engine, whichever body is asking. Local enforcement can be cached for autonomy at the edge, but the source is one.

The audit trail. One record of what happened, in one place, with the same shape, whether the actor was a person, an agent or a machine. This is the part that turns three subsystems into one system you can actually explain to an auditor.

The state model. All three act on the same entities. The robot moving stock and the agent promising a delivery date are talking about the same pallet.

Everything below that — motion control, sensors, drivers, real-time guarantees — stays domain-specific, and should.

Why the edge case is not an edge case

The usual objection is that robots and devices work offline, so central policy is impractical.

That is true and it is a design constraint, not a refutation. The pattern is familiar from every distributed system: policy is distributed to the edge, evaluated locally, and the decisions are reconciled when the link returns. The device keeps working on the cached envelope; it just cannot exceed it while disconnected.

What you get is autonomy with a boundary rather than autonomy with a gap — and the gap is exactly where incidents live.

The organisational argument

There is a version of this that has nothing to do with architecture.

When robots, agents and devices live in separate systems, they get separate owners. Different teams, different vendors, different review processes, and no single place where someone can answer “what is this actor allowed to do”. Responsibility follows system boundaries, so a fragmented stack produces fragmented accountability.

Putting them on one kernel is partly a technical decision and mostly a decision about who can answer that question in one query.

Where this is going

The interesting part is not that a robot and an agent share a permission model. It is what becomes possible once they do: work that moves between bodies without a handover.

An order arrives, an agent checks it against credit and stock, a robot on the floor stages it, the device in the picker’s hand shows the exception and takes their confirmation — one process, one policy, one audit trail, four actors, no integration project.

That is not a robotics roadmap or an agent roadmap. It is an operating system roadmap, and it is the reason to build the layer underneath before building anything on top of it.