How do you turn a developer's AI agent into something anyone can run?

Agents work well. They are built for technical users.

An open-source agent like Hermes can browse, write files, run code and call on dozens of skills. It opens with a version string, a session hash, a runtime path, and every capability named the way the code names it.

QHover anything underlined on the right. The count at the bottom is how many concepts stand between a person and their first task.

Nothing here is badly built. It assumes a reader who knows what a commit hash is and that plain English will not work at this prompt. The technology is ready for students, founders and working professionals. The interface shuts them out.

Both agents do the job. NoInfra makes the answer readable.

Send the same request to both. Both find the five jobs and both get them right.

Hermes writes the results to a file, prints the path, then prints the contents as one comma-separated line. NoInfra returns a sorted table and asks whether to draft the applications.

The answer is the same. The Hermes version needs a person to open a file and read across it before they can use it.

Friction 1: people cannot picture what an agent does

A non-technical visitor has no model of what an agent can do. Faced with an empty prompt they have nothing to type, because nothing has told them their kind of problem is one an agent can take on.

I interviewed students, builders and working professionals about how their weeks actually run: the jobs they repeat, the ones they put off, the ones they end up doing late at night. Six patterns came back often enough to build for, and those became the skills.

Insight: Every card is a task someone already has, written in the words they used for it. A visitor recognises their own week on the marketing page, before anything has been set up.

Behind each card is a real skill file holding the sources, filters, steps and tools. The card surfaces three lines of it and a button, which is what a person needs in order to decide.

Friction 2: doubt, until something actually works

Running an agent normally means a server, an API key, a runtime, an environment and a model choice. NoInfra removes all five. Nothing gets installed, pasted or named.

The sequence on the right is built for speed to a first result. Somebody who has never run an agent has one doing a real task in about a minute. Watching it work settles the doubt; reading about how it works does not.

Insight: The account is asked for as a benefit. The same two fields every product asks for, under save this chat instead of register to continue. By that point there is a conversation worth keeping, so the ask describes what you get.

Friction 3: the agent narrates itself to an engineer

Left alone, an agent reports container images, tool calls, token counts and exit codes. Every one of those is a place a non-technical user stops and wonders whether something went wrong.

I rewrote everything it says while it works. Same events, same order, addressed to the person who asked. Watch the three moments on the right rewrite themselves.

Insight: Renaming beat explaining. A definition of a runtime spends attention a new visitor has very little of, and leaves them no keener on the product. A word they already know needs no paragraph.

Friction 4: an agent with an inbox, a phone and a wallet

The agent holds real authority. It can read your mail and send as you, call people as you, and spend your money. For a non-technical owner that raises three questions at once: what can it see, what can it do without me, and how do I stop it.

A permissions screen answers none of them well. It grows with every feature and it asks the person least equipped to answer.

Authority is defined per class of action rather than per feature. Four classes cover everything the agent can do: creation, deletion, outgoing and payment. Each class has one fixed rule, so the behaviour is predictable before you meet it. The tree on the right is the whole model.

Insight: Asking about everything is not safer. On Vani, an earlier agent I designed, ten users ran real tasks against prototyped approval cards. They stopped reading by roughly the third interruption and started clicking yes, matching the documented habituation effect in security warnings. An approval nobody reads is fake safety.

Insight: The line people draw is identity and permanence. Anything that goes out with your name on it, or cannot be undone, was where every tester wanted a hard stop. That finding is what sorts the four classes: creation runs, deletion and outgoing stop, payment runs to a ceiling you set.

Batching follows from the same evidence. Five sends in one task arrive as one approval, because five identical cards in a row is exactly how you train someone to stop reading them.