Designing agent products: Delegation, memory and autonomy, from three years on Deva and 10Planet

Agent products are delegation products

An agent product asks someone to hand over work they used to do or supervise. Whether they do it depends less on the model than on three things the interface controls: how well they can predict what the agent will do, check what it did, and change it afterwards. Most agent UX decisions come back to one of those.

On Deva the work being handed over was unusually personal. A Deva answered in its owner’s name: anyone could @mention it and get a reply, and later it could post for its owner on X and Telegram. People only let it do that once they could see what it knew, who had taught it and what it would do next. Every section below follows from that.

What Deva was, and how often it changed

Deva changed shape several times, and the designs record each version:

• Genie, a task agent. You made a wish, it wrote a task list and worked through it, with current and completed tasks on screen. It ran on GPT-3.5 for free, or on your own OpenAI key with GPT-4 and a warning to set spending limits.
• A custom AI that anyone can @mention. You claimed your X username, taught your Deva how to answer, and earned Karma each time it replied and each time you trained it.
• A social layer on top: group chats with people and Devas together, a feed, channels, a leaderboard and referrals.
• Wallets and on-chain assets: Karma balances, a Deva wallet, external wallets.
• Notes, by 2024: daily notes and voice notes as the place a Deva learns from.
• An agent that posts: a character, a style and a posting setup, connected to X and Telegram.

Each change rebuilt most of the screens. The objects under them changed much less: an agent with a character, the sources it learned from, the people allowed to talk to it, and a record of who contributed what. That is the practical case for the next section. The first version of your model will be wrong somewhere, and the screens will be wrong more often. Write the model down, keep it modular, and a change of direction rebuilds one layer instead of all of them.

Define the objects before the screens

Deva started with three questions, about what an agent is, how it stores memory, and what long-term use looks like. The screens came after the answers. I mapped the first journeys around creating, training and deploying agents, then widened them to memory management, agent discovery and social interactions.

The object model is a strategy document more than a design artifact. It decides what the product can charge for, who can be given permission to what, and what the team can measure. If a task is an object, you can count tasks started, finished and corrected. If it lives inside a chat log, you cannot, and neither can your customer.

On 10Planet I took the same approach further: models for long-term memory containers, hierarchical logic flows and modular agent behaviors, then schemas for how agents are built, changed and connected to each other and to external tools. Everything designed later was checked against them.

Teaching is part of the product

An agent that answers in your name has to be teachable by someone who is not an engineer. Deva gave its owner four ways in, each for a different kind of knowledge: upload data (documents, Dropbox, Google Drive), reply to questions the system asked, publish variants by picking the best of several replies, and free text for stories and opinions. A playground let the owner try the result before anyone else saw it.

Two decisions here carry over to any agent product. First, teaching came before publishing: an owner could invite trusted people to talk to a private Deva, train it and give feedback before it went public. That is a staging environment for behavior. Second, other people could propose a better reply to someone else’s Deva, and the owner decided what to publish. Contributions earned points and Karma, so the record of who taught what was part of the product, not a log nobody reads.

Treat memory as the asset and the risk

Memory was the hardest idea to make tangible. People had to grasp that an agent remembers, what it remembers, and that they have a say in it. Memory is also where an agent product builds value: the longer someone works with an agent, the more context it holds and the harder it is to replace. The same accumulation is the main trust risk. People keep delegating only while they believe they can see what the agent remembers, correct it and remove it.

My rule is that every piece of memory needs a place in the interface, a visible source and a way to change it. In the 2024 notes design that became three switches on every note: Use for Responses, Show in Retrievals and Publish. The owner decides, one note at a time, whether the Deva may answer from it, cite it, or show it to others.

Group chats needed the opposite control. With Ephemanon messages on, messages in a group disappear after a set time, and the owners of the Devas in that group see the people in it only as Anon A and Anon B. An owner still sees what was asked of their Deva, without knowing who asked. Memory design is as much about what the agent should not keep as about what it should.

Autonomy belongs to the action, not the agent

Teams often ship an agent at full autonomy because the demo looks better. People extend trust in steps, and the product should let them. Researchers describe these steps by the role a person plays, from operator to approver to observer (Feng, McDonald and Zhang, 2025), and automation research has used levels since the 1970s. The levels are not the hard part. Deciding where each action sits is.

Deva never had one autonomy setting. It had a setting per action. Auto posting to X was a switch, off until the owner turned it on. Karma transactions over an amount the owner chose needed their approval. External wallets were connected for tracking only and could never pay for anything. Apps got a list of permissions, from seeing the username to spending Karma. The same Deva could reply to strangers on its own and still ask before it moved money.

Today I set it up the same way, with four settings for each kind of action: the agent suggests; it drafts and a person sends; it acts after approval; it acts and reports. A new kind of action starts low and moves up as the record of good outcomes grows, and drops a step the first time someone has to undo it. Each setting is also a design brief, because each needs its own screen: a review queue for drafts, an approval step for actions, an activity log with undo for autonomous runs. Deciding the setting per action early saves rebuilding the interface later.

Separate execution, governance and interface

10Planet became the backend intelligence and agent management layer, and Deva the place where people talk to their agents, train them and work on them together. Inside 10Planet there were three layers. The system layer ran agents and managed tasks. The governance layer handled voting, permissions and identity. The interface layer hid both from developers and end users. Keeping them apart let each one change without dragging the others along, and the same architecture later carried Deva and Yappers.

The split pays off commercially as well. Governance is where business buyers look first: who can run an agent, who approved an action, where the record is. A team that designs permissions and identity as a layer of their own can answer those questions without rebuilding the product around them.

Reveal complexity in the order people need it

An agent platform has a lot of depth: training, memory, Karma, wallets, voting. Put all of it in the first session and people leave. A large part of the Deva work was deciding when each part shows up. Small patterns carried most of it, tooltips and subtle animation during onboarding, with the deeper parts opening only when someone needed them.

Decide what a person must understand in the first session, what can wait until the tenth, and what only matters to the few who build on top.

Measure delegation

Deva’s beta was measured the way most consumer products are, by daily active users and retention. Those numbers say people came back. They do not say whether people trusted their Deva to speak for them. The numbers I would add first describe delegation:

• Time to first accepted output. From sign-up to the first reply or task a person accepts without changes.
• Correction rate. The share of agent outputs a person edits, replaces or reverts.
• Repeat delegation. Whether the same person hands the same kind of action to the agent again within a week.
• Autonomy in use. How many kinds of action an account has moved up a setting, and how many have dropped back.
• Memory in use. How much of what a person taught the agent it actually draws on.

All five depend on the object model. They are hard to add once outputs exist only as chat history.

Tie the design system to the domain logic

Every element of the 10Planet design system mapped to protocol logic as well as to a component. Memory had a type, a task had an execution route, a vote had a scope. New features started from rules the system already knew, which kept logic, hierarchy and UX consistent across the modular tools. The same idea, decisions written down where both people and machines can read them, is what I now test with coding agents in Design systems for coding agents.

Where agent products usually go wrong

• Chat is the only interface, so every task, setting and result is buried in a transcript.
• Memory is hidden. The agent remembers things the user cannot see, scope or remove.
• Autonomy is one switch for the whole agent, so the riskiest action sets the level for all of them.
• There is no undo and no log, so people stop delegating anything that matters.

The case studies

Deva and 10Planet are written up in full, with the screens: Deva, 10Planet.