CONTEXT

The graph is the memory

A thirty-shot project does not fit in a context window and should not have to. Expose slices as MCP resources and let the server stay the source of truth.

RESOURCE SLICES

01SummaryA few hundred tokens read at session start.
02Shot contextOnly what one shot needs, and its neighbours.
03SearchVector query across shots, dialogue and critiques.
04DecisionsAppend-only log of what was chosen and why.
The agent pulls the slice it needs. Nothing is re-summarised into the prompt on every turn.

Calls

picx://project/{id}/summary
Logline, cast, look, board status. Cheap to read often.
picx://shot/{id}/context
Everything needed to shoot one shot, nothing else.
picx://search?q=
Vector search returning shot and take IDs.
picx://project/{id}/decisions
The decision log. Survives context resets.
RequestGET picx://project/{id}/summary
// resource read, no body
Response200 OK
{
  "logline": "A barista discovers…",
  "cast": ["char_maya"],
  "look": "look_a1",
  "board": { "shots": 14, "shot": 9 }
}
From the CLI
$ picx memory summary prj_4a81b
$ picx memory search "maya holding the mug"

  shot_007 · take tk_31a  (0.91)
  shot_011 · take tk_44c  (0.78)

For users

Come back a week later and the agent still knows the project. Nothing lives in a chat that can be lost.

For developers

Register these as MCP resources, not tools. Clients cache resource reads and will not burn a tool call on a summary they already hold.

Gotchas

  • The decision log is append-only. Corrections are new entries, never edits.
  • Search is scoped to one project by default. Cross-project search requires an explicit workspace scope.