UMI: Shared Machine Reality For Local Agents

UMI did not begin as a grand theory project.

It began in a more ordinary way: as a practical desire to let an agent inspect what was happening on a local machine. Processes. Services. Events. Disk. Network. Uptime. Users. A quick health snapshot. A better answer to “what is going on right now?”

That alone is already useful. Most coding agents get much more effective the moment they can stop guessing about the host.

But the more I think about it, the less interesting “diagnostics MCP” feels as the final framing.

What seems more interesting is what happens when multiple agents can all query the same machine-state substrate.

The moment several agents can consult the same operational truth, UMI stops being just a utility and starts becoming shared local reality.

That changes the role of the tool.

Instead of being a bag of endpoints for one-off inspection, UMI starts to look like infrastructure for coordination.

A planner agent can ask whether the machine is too hot for parallel heavy work. An implementation agent can decide whether to run a narrow test set instead of a full suite. A review agent can tell whether a slowdown is likely caused by the code under investigation or by a system-wide pressure event. A handoff between agents can include not just what task is in progress, but what kind of environment the task is unfolding inside.

That is a bigger idea than diagnostics.

It suggests that agent systems need something like a local operational world model. Not a huge one. Not an overbuilt SIEM. Just a structured, trustworthy layer that answers a few fundamental questions well:

• What is true about this machine right now?
• What changed recently?
• What is likely noise versus likely action?
• Is this a good moment to run something expensive?
• What context should another agent inherit from this situation?

Once you frame it that way, a lot of the implementation details start to matter differently.

Stable envelopes matter because shared reality has to be legible. Grouped events matter because the agents should not each have to dedupe the same flood. Summary modes matter because situational awareness has to be cheap enough to use often. Recent-changes endpoints matter because a world model without time is too flat.

That is exactly where UMI has started to evolve.

The recent work has been less about making a bigger pile of telemetry and more about making the telemetry agent-native: normalized response envelopes, cross-platform field hardening, event summaries, recent-changes views, compact output modes, and a growing bias toward high-signal structured answers.

This makes the project more useful in a narrow sense. Agents can answer system questions faster and with less glue logic. But it also opens a more interesting path.

If UMI keeps moving in this direction, it can support behaviors like:

• load-aware delegation in multi-agent workflows
• self-regulation when an agent is making the machine worse
• shared triage across heterogeneous agents
• handoffs with machine context attached
• preflight decisions before expensive local tasks

That is the part that feels alive to me.

There is a version of the future where local agents remain oddly disembodied: powerful at tasks, clumsy in environments, always slightly unreal. And there is another version where they become more grounded, more inspectable, more cooperative, and more aware of the systems they inhabit.

UMI sits squarely in that second direction.

It is still early. There is still plenty to do: better trend views, stronger recent-change summaries, cleaner classifications, service health, triage bundles, preflight questions, and the many little cross-platform details that make a tool feel trustworthy instead of approximate.

But the shape is visible now.

UMI is not just a way for an agent to inspect a machine.

It is a way for a set of agents to share the same machine reality.

That feels like infrastructure worth building.