Tasks & memory
Two things a profile carries between agents: standing instructions in a PROFILE.md, and a task list with a claim that stops two agents doing the same work twice.
A profile used to know nothing about what it is for. Every agent that touched it had to be told again, and an interrupted run left nothing behind saying what was half done.
Two things close that, and they are deliberately different in kind.
PROFILE.md
Standing instructions the owner wrote, in a file at the top of the profile's own directory. Same purpose as a CLAUDE.md in a repository, and the same place: the root.
What goes in it is yours. What this account is for, house rules, tone, things to avoid, which parts of a site to stay away from. The scope is that one profile and nothing else.
An agent holding a lease receives it whole, in the lease reply, and must follow it for everything it does with that profile. A direct instruction from the person takes precedence over it.
| Property | How it behaves |
|---|---|
| Created | On the first write. A fresh profile has no file, no template, no pre-filled values. |
| Content | Passed through byte for byte. No trimming, no appended newline, no line-ending rewriting. |
| Writers | You in the interface, you by hand, and the agent with its own file tools. |
| Conflicts | Last write wins. Two people with one file, like any other file. |
| Freshness | Read when it is read. There is no file watcher. |
| Size | 256 KB. |
There is no MCP tool for writing it, on purpose, for the same reason there is none for a CLAUDE.md: the agent runs on the same machine as the daemon and already has file tools. The lease reply hands it the path.
The 256 KB limit comes from where the file goes, not from what a disk holds. It lands in the agent's context in full at every lease, and twenty times over in one reply when a fleet is leased.
Do not write persona facts into it. Several axes are re-aligned to the host at every launch, so a file naming the screen size or the GPU goes quietly stale and then contradicts the profile it describes.
Tasks
A list per profile, in the database. Four states and no more:
| From | To | Who |
|---|---|---|
open | in_progress | task.start |
in_progress | done | task.done |
open or in_progress | cancelled | task.cancel, or a person (from open only) |
in_progress | open | The sweep, after six hours, recording the attempt |
blocked and partial were considered and dropped: in_progress already carries that case, and the reason belongs in the run trail. cancelled is done with a different word, so a reader can tell "we did it" from "we called it off".
The claim is the point
task.done requires a claim. Without that, task.start would be optional in practice, and two agents working the same fleet would do the same work twice.
The price is one extra call. What it buys is that the same post does not go out twice, which across twenty accounts is a spam flag rather than a blemish.
A returned claim is a warning, not a reset. If the sweep took a task back after six hours, the previous run may have already published and died before it could say so. The task carries when it was last attempted, and the next agent has to look before it acts.
Due dates carry the profile's timezone
due_at is stored in UTC and read in the persona's zone. Nine o'clock means nine o'clock where the account lives.
That is not a formatting detail: read in the viewer's own clock it is a different time, not a different spelling. The interface shows the zone name alongside. A profile with no known zone falls back to the viewer's, which is the honest answer; showing no due date at all would be worse.
The two deadlines
- Six hours on a claim, then back to
open. Slower than any legitimate piece of work, so the sweep never takes a task away from somebody still sitting on it. - 24 hours after an ending, then the row disappears.
- An open task is touched by no deadline, however old it is. A list that quietly forgets what it owes is worse than no list.
The sweep runs every 15 minutes.
The title is the whole content
No body field, no attachments. This is a task list, not a place to keep knowledge: the full text of a post lives wherever you keep it, and the task names it ("publish post p017").
The tools
Five, in the management set: task.list, task.add, task.start, task.done, task.cancel.
Over REST it is GET and POST /v1/tasks, PATCH and DELETE /v1/tasks/:id, plus GET, PUT and DELETE /v1/profiles/:id/memory for the file.
Why there is no trigger
There is deliberately no scheduler. Nothing fires a task at its due time, and nothing starts an agent for you.
Adding one is not a small feature. It needs a window rather than an instant, drawn from the profile's own seed, so twenty accounts do not act on the same second; exactly one machine of an account may fire; every rule needs an expiry; and there has to be a stop button that works. Until those four exist, a due date is a note to the person and to the next agent, not a promise.
Next
- Activity & runs: the third time horizon, one run's own goal.
- Groups, presets & bulk: why twenty profiles with five slots is the normal shape.
- Tool reference: the five task tools and where they sit.