Designing agent platforms: Notes 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.

Deva made this concrete. Users were asked to treat agents as collaborators that learn, so they needed to see what an agent knew, how it had been trained and what it would do next. The rest of this piece follows from that.

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.

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

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.

So write the objects and their rules down before anything else. On 10Planet they were agents, memory, tasks, tools, votes, permissions and identity. Name what each one can do and who can change it.

Separate execution, governance and interface

We split the product in two. 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.

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. So memory management got its own flow, next to creating, training and deploying agents, instead of living as a property of the model.

Memory is also where an agent product builds value over time. 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 now is that every piece of memory needs a place in the interface, a visible source and a way to change it. Training tokens and voting on Deva had the same requirement. Neither made sense to people until they could see what it changed.

Autonomy is a dial

Teams often ship an agent at full autonomy because the demo looks better. People extend trust in steps, and the product should let them. I use four settings. The agent suggests. The agent drafts and a person sends. The agent acts after approval. The agent acts and reports. Each task type starts low and moves up as the record of good outcomes grows.

The dial is also a design brief. Each setting needs different screens: a review queue for drafts, an approval step for actions, a report for autonomous runs. Deciding the setting per task type early saves rebuilding the interface later.

Reveal complexity in the order people need it

An agent platform has a lot of depth, from modular agents to voting, memory and training. 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

Message counts and session length say little about an agent product. The numbers I would look at first describe delegation.

• Time to first successful task. From sign-up to the first task a person accepts without changes.
• Correction rate. The share of agent outputs a person edits or reverts.
• Repeat delegation. Whether the same person hands the same kind of task to the agent again within a week.
• Autonomy in use. How many task types an account has moved up the dial.
• Memory in use. How much stored context an agent draws on in a typical task.

All five depend on the object model. They are hard to add once tasks 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 visual language followed the same rule. 10Planet was greyscale by default, and highlights came from context, never from decoration. Layouts were schema-driven, components atomic, accents close to code syntax.

Plan for the pivots

Deva changed direction several times. We redefined flows, rethought the architecture, restructured the platform and rebranded as the vision matured. Each round showed blind spots.

The first version of your model will be wrong somewhere. Keep it written down and modular, so a pivot changes one layer and leaves the rest.

Where agent products usually go wrong

• Chat is the only interface, so every task, setting and result is buried in a transcript.
• State is hidden. The agent remembers things the user cannot see or change.
• Autonomy arrives before trust, and one bad action ends the relationship.
• There is no undo, so people stop delegating anything that matters.
• The team measures conversations instead of finished work.

The case studies

Deva and 10Planet are written up in full, with the screens: Deva, 10Planet. If you are building an agent product and want a second look at the decisions behind it, email me or see Product Diagnosis.