Record a project decision that another agent can find

Write the decision, reason, scope, and affected work in a shared record.

Guide · Updated 2026-10-20 · 3 min read

A current decision card connects participants with an older record.
AI-generated illustration. Conceptual artwork, not a product screenshot.

Write the decision, reason, scope, and affected work in a shared record. Then ask the next agent to read it before acting. Tinovio stores that context outside the original session's private conversation.

Suppose the project keeps guest checkout because purchasing must not depend on registration. The code may show how checkout works today. The decision explains which behavior later changes must preserve.

Record the conclusion rather than the whole discussion

A decision record should state what the project chose and why. Include the condition or scope that makes it apply. Link supporting material when the reasoning needs more detail.

Do not replace the conclusion with a transcript of every alternative. The receiving agent should identify the controlling requirement without reconstructing the discussion. Keep unresolved questions separate from the confirmed decision.

Name the affected work

Identify the feature or task that depends on the decision. For guest checkout, link the relevant implementation and review tasks. An otherwise clear statement can still be misapplied to an unrelated project area.

If the decision is temporary or environment-specific, state that boundary. A preview-only choice should not silently become a production rule. The context needs enough detail to prevent that expansion.

Save the decision in Tinovio

Ask the responsible agent to share the decision and reason in the project Space. Tinovio records the shared text with its source information and time. Other participating sessions can find the record through search and read tools.

For example, tell the builder to record that registration remains optional during checkout. Ask it to include the reason and the relevant task. This is more useful than merely saying “remember this” in one private conversation.

Connect it to the next action

When creating the review task, instruct the reviewer to read the saved decision first. Include the version and expected output. The task now connects the requirement to a responsible inspection.

Ask the reviewer to state which decision it used when reporting findings. This checks that the record actually entered the work. A decision stored but never read cannot guide an inspection.

Keep changes explicit

If the requirement changes, record the new decision and identify what it replaces. Tell the owners whose active work depends on it. Do not leave a correction in an unrelated chat and expect every agent to infer its priority.

Tinovio supports records that distinguish current context from replaced context. The responsible agents still need to make the change explicit and read the applicable scope. The workspace does not settle an unclear product decision by itself.

Verify retrieval with a fresh session

Ask another session to find the decision, explain its reason, and name the affected work. Compare the answer with the record. Correct missing information at the source before that session acts.

Try a new-session continuation when the current owner stops work.

Sources

  1. Tinovio shared-context tools
  2. Tinovio spaces and discovery
  3. Tinovio tasks