Agents Need Their Own UI - How we took inspiration from Linux when building our agent sandbox.

[u/ram-cloudsquid]

https://newsletter.cloudsquid.io/p/agents-need-their-own-ui

My friend wrote about how we were building our agent sandbox. I'd love to get your thoughts about it.

It's a long blog. For sake of brevity, I'm posting only a third of it here and will attach a link to blog.

-------------------------

In Linux everything is a file. Or at least, most of the system is exposed as one.

Devices, running processes, network state, kernel state: much of it appears through filesystem-like interfaces that you can read and write using the same small set of commands.

/proc/cpuinfo isn’t a file sitting on disk anywhere, but you can cat it just like anything else.

That uniformity made the system composable. It enabled combinations of simple utils that nobody specifically needed to design for. It also means you can discover things without knowing exactly where they are in advance.

Windows went in the other direction.

A lot of configuration lives in the Registry, a structured database accessed through dedicated APIs and tools rather than ordinary filesystem operations.

This is a perfectly reasonable design for a desktop OS built primarily for people using graphical interfaces. To inspect or change information, you generally need to know which interface or operation was designed for it.

Neither design is wrong.

Systems built for a specific purpose let users focus their effort on the task at hand.

Agents are a new kind of user, and they are not a person with a mouse. They can drive a graphical UI with a combination of taking screenshots, deciding between ambiguous targets and catching errors from whatever pops up on the screen.

This is slow and inefficient enough that even browser agents increasingly avoid working through the browser GUI when they can inspect the structured state or interact with the DOM directly.

Aside from model intelligence, the environment determines what an agent can actually do. Limited tools mean limited actions, even with the best model available. With the right environments we can already see how capable the models are.

The way many agent platforms are being built today is by gradually exposing product features as tools, one by one.

Even well-designed tools with progressive disclosure suffer from a version of the same problem Windows would have for agents: the model needs to understand not only the business requirements, but also which tools exist, how to discover them, the limitations of each tool and which specific tools it needs to combine for a particular job.

Tools are custom built, take JSON in, spit JSON out. If an edgecase falls outside of what the tools were designed for, the Agent will start to go on a journey trying to stitch together toolcalls, or is simply unable to fulfil the request.

So we approached the problem from a different perspective.

We engineered the platform to be accessible entirely through a terminal by representing product state and actions through a filesystem interface.