Silo tool

silo_recall

The single tool for retrieving information — the user's stored memory AND their connected live data. Pass `scope` to choose the kind of data (a SHAPE: memory, message, file, note, task, event, transaction, account, contact, code, space), `query` to search, `since`/`until` to bound a date range, `filters` to narrow, or a `handle` from a previous recall to open one item (optionally expanding a `facet` like .content). Results are paged: when more remain, the response includes a `cursor` — call silo_recall again with just that `cursor` for the next page. Returns provider-blind slices with opaque handles — you never learn or need which service backs a result.

Input

{
  "scope"?: "memory | message | file | note | task | event | transaction | account | contact | code | space",
  "query"?: "string",
  "since"?: "YYYY-MM-DD  (inclusive start of date range)",
  "until"?: "YYYY-MM-DD  (inclusive end of date range)",
  "filters"?: { "date"?: "...", "source"?: "...", "space"?: "...", "status"?: "..." },
  "handle"?: "opaque handle from a prior recall",
  "facet"?: ".content | .comments | .diff",
  "silo_id"?: "uuid | 'default'  (only for scope=memory)",
  "max_results"?: 10,
  "cursor"?: "opaque page token from a prior recall — pass alone for the next page"
}

Output

{
  "shape": "message",
  "items": [
    { "handle": "slc_…", "title": "...", "participant": "...",
      "preview": "...", "date": "..." }
  ],
  "matched": 42,
  "returned": 10,
  "cursor": "rcr_…  (null on the last page)"
}

Policy

Reads are always available. Live shapes require the relevant service to be connected; memory requires recall access on the silo. Pages are cached server-side for 5 minutes; an expired cursor transparently re-fetches.

Any silo_id parameter accepts either a UUID or the reserved alias "default" — see how the default alias works.