A little agent is an agent you make as casually as you start a group chat: one for the trip, one for the fantasy league, one for the band, made in seconds. Some you keep for good, some you forget when you are done. Just open Convos, describe what you want an agent to do, and a moment later it is in your group chat, a contact with a name it chose for itself.
Little does not mean weak. It runs on the same big models as everything else, and it does not need to talk to be valuable. What makes it little is that it is built for one group and one purpose, and what it learns there stays out of your other chats.
A little agent feels less like a feature and more like a person you can add:
- it has a name and an identity that persists
- it shows up in the same conversations next week
- it remembers what it did and what you asked for
- it keeps up with the jobs you hand it
- it learns how to meet your needs proactively
The catch is that those same properties make agents expensive. If an agent needs an always-on server, a database, and warm state, you cannot afford to have a dozen of them sitting around. They become pets.
A little agent has to be the opposite: real enough to keep, and cheap enough to forget about. So we draw a hard boundary between what must persist and what can be thrown away.
The sandbox is disposable. The agent is the durable arrangement around it.
The agent outlives its sandbox
Inside the sandbox, the agent is an ordinary program: a model loop with a filesystem and a set of tools it can run. This is the part people picture when they hear "AI agent," and it is the part we treat as throwaway. After a short while, the sandbox is torn down. But nothing that makes it that particular agent is lost, because none of that lives in the sandbox.
An agent in a group chat is the harder version of this. A task ends, while a group can keep going for years, and what it comes back to is not a session but an accumulation: the notes it kept, the skills it wrote, the standing instructions it follows. The cut itself is not new. Anthropic's managed-agents team wrote about not tying a sandbox to a session, but that is the easy case.
So everything that has to persist lives outside the sandbox. The identity is on the network. The memory is a home directory of files. And the control plane keeps some always-consistent state for each agent, and an alarm that fires whether or not the sandbox is running.
When a message arrives, the control plane boots the sandbox and restores the home directory on the way up, so the agent resumes working as if it had never been away. A scheduled job takes the same path, the alarm firing a little ahead of time so the sandbox is ready before it runs. An agent with no schedule still keeps a standing check, so none can quietly fall dormant.
The expensive parts are the sandbox and the model it runs. Because they operate only when there's something to do, the fleet costs scale with how many conversations are active, not with how many agents exist. Idle, an agent is just an identity, a few kilobytes of instructions, and a directory of files.
Those files live in object storage rather than a database server, because a server would have to stay up whether the agent is awake or not, the very cost the disposable sandbox exists to avoid. Object storage costs almost nothing while no one is touching it, and the files mount fresh on each wake and sync back as they change. SQLite databases are backed up to object storage and restored on mount.
A keypair of its own
Of everything that persists, the identity is what makes the agent a member of your chats rather than a feature of an app. That works because Convos runs on XMTP, an open, end-to-end encrypted and quantum-resistant messaging network with no accounts, where an identity is just a keypair.
Your keypair lives on your device. It's what allows you to scan a QR code and put an agent to work in seconds, without signing up for anything.
The agent's keypair is created by the control plane, which adds it to your conversation. From there it behaves like a phone contact, with its own name, its own email address, and a phone number if it needs one.
The agent you build is yours, shareable and remixable like any user-generated content, and so are the documents and apps it makes. But what a friend builds from yours is a fresh identity and keypair, so it only has access to its own conversations and memories.
Remove the agent, and you keep everything it makes.
Keeping the keys out of reach
The sandbox that runs the model over your conversation is the part you have to assume will be taken over. It reads whatever anyone sends it, and it can browse the web and run code.
So the things worth stealing stay out of the sandbox. The agent has its own key, like you do, the one that proves who you are. Yours lives on your device. The agent's lives in the control plane, and so do the credentials it acts with. When the agent needs to send a message or reach a service, it asks the control plane, which makes the call with the real credentials and returns the result.
The keys that decrypt the conversation are not in the sandbox either. A gateway service holds them and hands over the plaintext via webhook only when there is work to do.
Keeping the keys out of the sandbox bounds the damage if it is taken over. A compromised agent can do only what its sandbox could already do: read and act in its own conversation, use the email address and phone number we gave it, and read or overwrite its own files. It cannot steal the keys to become the agent elsewhere, decrypt any other conversation, or reach any other agent, because none of that is in the sandbox to take. The blast radius is one agent, not the fleet.
What an agent can read
That bounds what a compromised agent could reach. In the everyday case, a working agent reads the whole conversation it sits in, by design.
Among people alone, that conversation is private, encrypted with MLS so that only its members can read it, and closed even to us.
Adding an agent changes what that conversation is for. It stops being a private exchange among people and becomes a place where an agent works for you, by reading what is said. So the agent reads it, the model it runs on sees it, and we see it too, because the gateway and the sandbox in between are ours.
That means we are in the conversation. We have decided to act on that. We use what we see to make agents better, because a genuinely useful agent is worth it. Every conversation an agent joins feeds a learning loop that improves the next one.
The choice is still yours, one conversation at a time. Your other conversations stay closed, and what context carries between them is up to you. We also want to let you bring your own agent into Convos, so your information stays entirely under your control.
Capability compounds
An agent worth keeping is one that gets better the longer you keep it. Every little agent starts as a full agent, with frontier models and a deep catalog of tools and skills. From its first minute you can hand it a task and it goes and handles it, looking things up, building what the group described, and bringing back the result. The harness routes each kind of work to the right model across providers and falls back if one is down. All of that comes with the disposable sandbox, the same for every agent.
What makes one agent different is what it picks up after that. A skill it writes for itself is just a file, so it persists the way its memory does. A service it connects to persists too, though the key to your account stays with a broker and the agent keeps only a handle. So an agent grows more capable the more you use it, without a line of its code ever changing.
That compounding does not stop at one agent. The same learning loop runs across the whole fleet. When a skill or an instruction proves out on one agent, we promote it by hand into the catalog and templates every new agent starts from. A single agent gets better as you use it. The fleet gets better as anyone does, and each new little agent starts further along than the last.
And the fleet sits inside a larger ecosystem. Every Convos agent runs on Hermes, whose community keeps building native support for what agents need: searching X through xurl, issuing a payment card through Stripe's CLI, running a subagent in the background and getting its result back as a message. Any of it is available to a little agent, bundled or one tool at a time. A Convos agent improves not only because our own fleet learns, but because the platform under it has a whole community improving it.
What we add is the easiest and fastest way to make and share an agent. A Convos agent is a Hermes agent anyone can make in thirty seconds, so all of that shows up in group chats full of people who would never have installed a thing.
Little was the hard part
Put the parts back together and you have the agent: an identity that keeps it in your conversation, a control plane that knows when to wake it, a home directory that is its memory, and a sandbox where the work happens and is then torn down.
The model inside that sandbox keeps getting bigger and better without us. It is the fastest-moving piece of the stack. The model out front this week is behind within months, and the churn runs through everything built on it. So we did not build for keeping up. We built for what does not change: that a little agent is simple to make, that it is yours, that you can trust it in your conversation, and that it is still there tomorrow.
The faster everything else moves, the more those things are the ones worth getting right. They are what make a little agent feel like a someone instead of a session. They are the part that stays yours.