CC: @Eric Vicenti

After the today's demo of agents, I can see that the amount of state stored on the agent server is substantial. And lots of it is quite mutable. I hope we won't need to store the full history of it all forever. Some of it is also private apparently.

I'd indeed appreciate a document describing which parts of that state do you think need to be stored on the network vs. owned by the server. At least in broad strokes. Because I'm worried about the required scalability if we wanted to put this all into the permanent data, and managing the permissions around also looks pretty crazy.

I disagree with your statement that we must have schemas first in order to reason about this. We can use pseudocode or any other form of notation to reason about data, like we've been doing up until this point. So please, use whatever approach you feel more comfortable with to describe these shapes of data at least in broad strokes in a document.

Feel free to directly update this doc.

# Agent Server Data to be migrated

The agent server owns lots of state, and almost all of it is mutable or deletable. I believe all of this should move to the network data.

- list of agents

- for each agent:

- permissions of each agent: owner, public reading and public chatting, collaborators list

- system prompt

- memory (files+folders)

- custom tools, mcps, tool enablement, account access

- triggers

- sessions

session attachments

tool calls and workflows

sub-sessions

chats from users and agent

# Agent Server data stays private

Some data will stay private to the agent server

- API keys and subscription auth sessions

- Account signing keys

- Ephemeral data: streaming responses from models, tool calls in-flight, trigger runs in-flight