Main idea

Representing a context in Google Drive left two options: one Google Doc per type of information — sources, state, knowledge, tasks — or a single Spreadsheet with one tab per type. The two structures are equivalent from the point of view of the information; they are not from the point of view of access. The first forces the assistant to find and hold as many Google IDs as there are documents, the second only one, the Spreadsheet's, inside which tabs are named at no cost.

So the decisive criterion was neither readability nor the elegance of the split: it was how many objects you have to locate before you can read or write anything at all. A Context became a Spreadsheet, and each type of information a tab.

Why it matters

This introduces a criterion you forget when designing a tree by hand: a human finds files by visual navigation and pays almost nothing for their number; an agent finds them by resolving identifiers, and pays for each object in calls and latency. A structure that is comfortable on screen can be hostile to the machine that has to write into it.

The choice of medium then becomes a two-term trade-off — the shape of the information and the cost of addressing it — instead of a single one.

Nuances and limits

Grouping has its own limits: a single Spreadsheet concentrates contention risk, caps out in volume, and makes every permission coarser — you share the whole context or nothing, where separate documents could be shared one at a time.

And the criterion weakens as soon as resolving an identifier becomes cheap: with caching or an index kept up to date, having many documents stops being costly, and the trade-off reverts to the shape of the information.

Open questions

• Beyond what volume should a context held in a single Spreadsheet be split, and on what signal rather than on what published limit?