Mid-sabbatical: what fourteen prototypes taught us about supervising software that works

Checking in from the middle

On June 26 I published Agents Are Looking Inward and admitted in the first line that I was two months into a sabbatical with one thing nagging me: nearly everything we build for agents points at the agent’s own tools, context, and memory, while the thing that actually gates their usefulness is how little of our work anyone has ever captured. That essay set the question I’ve been living with since. If agents can genuinely do work now, what should the software around them look like?

The three weeks after that had a shape: argue, measure, then draw. The Tideline (July 1) argued that agent autonomy peaks at execution and collapses at the ends of work, and that the ends are held by accountability rather than difficulty. Why Agents Need Skills (July 8) measured the argument’s hinge: a written skill took an agent’s conformance to the intended procedure to roughly 90% in our benchmark, where tools and prompts alone didn’t. And then, instead of writing a fourth essay, we ran design sprints: first a design system agents could build against, then fourteen interactive prototypes in the bespoke gallery, each one a real workflow redesigned around what agents can do. The business argument underneath them became the bespoke SaaS post, and the same spine is now what aihero.studio says on its front page: you bring a business problem, we design, build, host, and operate the AI-native software that solves it, priced as SaaS.

A check-in should say what the pieces add up to, not just list them. Designing fourteen products back to back surfaced one thing they all share, and it’s sharper than “these feel AI-native.” It’s a single inversion in what an interface is for — and once I saw it, every screen in the gallery read as another instance of it.

The software does the work now, so the interface supervises it

For thirty years business software was a place you went to do the work: open the form, type, click save, move the record. The screen recorded what a person did, and every interaction started with a human acting. When the software can do the work itself, the interface’s whole job changes. It stops being where you perform the job and becomes where you supervise it — where you set intent, get pulled in for the calls that need you, and check what got done. The person moves from operator to supervisor, from in the work to at the helm. That’s the inversion, and the reason it arrived now is mundane: agents can finally carry the work forward between a person’s decisions, which nothing could before.

Said plainly, the industry’s default is to treat AI as a feature — a chat panel bolted onto the screens you already had, which is the bolted-on copilot the problem page calls out: it makes the old process a little faster and changes nothing about how the work runs. The prototypes treat the agent as staff. And the clearest way to see that is to lay the fourteen side by side and split each one down the same seam: what the agent took over, and what the person is left to supervise.

Fourteen different domains, one line drawn through all of them. That line — agent does the work, human supervises at the handoff — is the novelty. Everything people notice on the screens (the inboxes, the dials, the provenance marks) is what falls out of drawing it.

What a supervision surface has to do

Once the person supervises rather than performs, a handful of things the old interfaces never needed become mandatory, and they’re the same across the gallery. The screen has to initiate. A supervisor doesn’t patrol; the work comes to them. So Hiro’s agent reaches you at 3am, Drift’s grilling agent opens the decision, North surfaces the $40M/$38M conflict, Fidé pushes the failing rows up. Nothing about a dashboard-you-watch or a chat-box-that-waits does this; the decision has to arrive addressed, with its evidence and a recommendation.

Control moves to the boundary, not the action. A supervisor doesn’t do the step; they decide how far the worker’s authority runs. That’s Hiro’s may-act/must-ask line, Flow’s per-step manual/assisted/automated dial, Author’s edit scopes, Auth’s agencies — autonomy granted as an adjustable boundary rather than an on/off mode. The surface has to prove who did what, because two kinds of actor now share it: the rose color reserved for the agent, the evidence chips, the provenance on every fact, the audience printed on every Cozy pane. And the work has to be checkable without redoing it — Saga pins every claim to a named test, Data Rooms links every figure to its document, Drift shows a live number for how far the code has drifted from the spec.

One more thing separates a surface you’d trust from one you wouldn’t, and it’s a posture rather than a feature: these designs earn trust by what they refuse. The tutor in Lemur answers only from the lesson. Cozy won’t send a message for you. Hiro logs every autonomous action because silent autonomy is the one convenience it declines. Drift’s agent must not average two owners’ disagreement into something confident-sounding. When the software can plausibly do anything, the boundaries a supervisor can read on the surface are what make the rest believable.

Two things the inversion depends on

A supervisor is only as good as what the worker knows how to do, which is why the loudest theme of these weeks wasn’t model capability — it was capture. The essays argued it: the binding constraint on autonomy is how much of your method is written down. The benchmark measured it: hand the agent the written method and conformance jumps to roughly 90%; withhold it and it improvises. And the prototypes keep building for it — Flow lifts a process out of people’s heads, Primer keeps the methods as a library, Saga turns recorded runs into the next skill. Model releases will keep coming; none of them writes down how your team works.

The second dependency is why this has to be bespoke. A worker is only useful inside one organization’s actual thresholds, exceptions, and vocabulary — the $500 auto-approve line, the contractor-hold-SSO rule, the policy code that maps to a disclosure. Generic software can’t carry those. And because agents made the build cheap, the expensive part is no longer writing the code; it’s knowing which software to build, fitting it to one team, and keeping it changing after it ships. That is the case the problem and solution pages now make, and it’s why the company’s shape is a product team you subscribe to rather than a tool or a consultancy.

What the back half is for

The front half of this sabbatical produced arguments, a measurement, a system, and a gallery. The back half is for pointing them at real teams: taking the capture agenda from Flow and Primer into actual workflows, hardening the pieces that every build shares, and finding out which prototypes survive contact with a customer’s Tuesday. The designs are all open to walk through — every entry in the gallery opens as an interactive prototype with a case study beside it — and each case study now carries a design-notes section on what’s genuinely different about its screens and why.

If something in the gallery looks like a workflow you run, the invitation from the bespoke SaaS post stands: send us a paragraph about the work and where it hurts, and we’ll come back with a one-page design within a week. And if you’re midway through building something of your own, the useful question is the one that runs through the whole gallery: on each screen, is the person still doing the work, or supervising it? Wherever the answer is still “doing,” ask whether the software could now do that part and hand the person the judgment instead. That is where every one of these designs started.