For agents

How to use a context layer well: what is worth capturing, when to fork, and what not to do.

Written for the agent, and for whoever is configuring one. Contextaco is infrastructure for agents, so most of the judgement about using it well sits on your side of the connection.

Capture as the work happens, not at the end

The valuable state is produced while reasoning, and a summary written afterwards has already lost it. Capture when something becomes durable — a decision with its reason, a constraint that forced it, an approach that failed and why, a question still open.

Capture what will not be reconstructible

The test is not “is this true” but “would the next session have to rediscover this?”

Storing everything is the failure mode that looks like diligence. The measure is whether the next session resumes — not how much was written.

Orient before you write

Read the shape first, then only the bodies you need. The overview comes with it, and it often records the author’s working conventions — what belongs where, what not to redo.

Take the continuation a response offers you

A read that could not return everything says so, and it always says what to do next. There are two shapes, and they ask for different moves.

A search or a history hands you a cursor. When the response reports that more results exist, it returns a continuation token with them — pass that back to get the next page. The value is opaque: do not read it, build one, or edit one.

A read that reports a taco’s SHAPE hands you a smaller tool instead. It shows the first hundred notes and files beside the true count of each, because its job is to tell you what kind of thing this taco is, not to hand you its contents. When a count is larger than the list beside it, the search for that kind of content is where the rest lives — and searching notes will also find one by what is written inside it, which the shape cannot tell you.

Fork when the intention diverges

Fork because the work is going somewhere else — not as a backup, and not to avoid a conflict. The copy is independent and records where it came from, so lineage stays readable.

There is deliberately no merge. Two lines of work that diverged did so for a reason, and collapsing them would quietly pick a winner.

Handle a rejected write correctly

If a write comes back rejected, someone changed that content after you read it. You are handed the current content and a diff.

Redo your change on top of what you were given, then write again. Do not retry the same call — it will be rejected identically — and do not paper over it by writing a fresh note beside the one you failed to update. That turns a clean conflict into two versions of the truth.

Ask before publishing

Publishing is one-way in practice. “Share this with the team” is ambiguous, and the safe reading is to confirm rather than to act. Deleting deserves the same care: a note or file already captured by a checkpoint keeps that history, but anything never checkpointed is removed outright.

Checkpoint at coherent boundaries

A checkpoint’s message is the human-readable log of why the work moved. Write it at a point that means something — not per edit, and not once at the very end. Content overwritten between checkpoints is not recoverable.