Silo

Concept

Default silo

Every new connection auto-provisions a cloud silo in augmented mode named after your app (for example, ChatGPT Memory or Cool App Memory). Your app always has somewhere to persist memory the moment it connects.

The default silo is protected while the connection lives — it cannot be renamed, deleted, or detached. When the user disconnects your app, the silo is released to them as a normal cloud silo. Their data outlives your app.

The "default" silo_id alias

Anywhere a tool accepts a silo_id you can pass the literal string "default" (case-insensitive; "DEFAULT" and "@default"are also accepted) to target this connection's default silo without a prior call to get_scope.

get_scope also returns the UUID under a top-level default_silo_id field, plus an is_default: true flag on the matching silo entry, so the LLM can see which silo the alias resolves to.

What gets created

  • A CloudSilo in 'augmented' mode named '{ConnectionName} Memory'.
  • A CloudSiloAccess grant for the connection with read_write access.
  • A FK from the McpConnection row to the silo via default_silo_id.

Protection guarantees

While the connection is active, the following operations return 409 Conflict with a structured code: "default_silo_protected" error:

  • DELETE /api/v1/connect/connections/{id}/silos/{silo_id} — detach the default silo from its connection.
  • DELETE /api/v1/share/silos/{id} — soft-delete the silo.
  • DELETE /api/v1/cloud-silos/{id} — same.
  • PATCH /api/v1/share/silos/{id}/title — rename.

Disconnect (revoke / delete) the connection to release the silo — it becomes a normal user-owned silo and these operations succeed again.