Why we built a second interface for machines, not just people

For most of software history there was exactly one kind of user: a human with a mouse, a keyboard, and patience. Everything — the layout, the confirmation dialogs, the little undo toasts — was shaped around that person. When teams first started pointing assistants at their tools, they pointed them at that same human interface, driving it through screenshots and simulated clicks.

It works, right up until it does not. A button moves. A modal you did not expect steals focus. A number renders a frame late and the assistant reads the old one. The failure modes are exactly the ones that make UI automation brittle, and they get worse the more the assistant is trusted to do.

One system of record, two front doors

Sillops resolves every action server-side against a single source of truth. That gave us a clean seam: the console is one front door onto that core, and the API is another. Neither is a wrapper around the other — they are peers, and they share the same permission checks, the same validation, and the same audit trail.

The practical consequence is that an assistant never has to see a screen. It authenticates as a member, asks for exactly the resource it needs, and gets back structured data or a structured error. No pixels, no polling, no guessing whether a save actually landed.

Trust is the whole product

The reason this matters is not speed — it is trust. Because the assistant travels the same permission path a click does, there is no separate god-mode key to leak and no shadow surface to audit. The role you grant a person is the role you grant their assistant, and every action either front door takes lands in one shared, signed log.

That is the bet: the systems that let AI operate them safely will not be the ones with the cleverest agent, but the ones whose rules an agent literally cannot route around. We built the second interface so those rules are the only path in.