# How to Share an Informal Decision with People Who Missed It > Turn an informal agreement into an update for colleagues who missed it. Share the accepted scope, conditions, current instruction, and unresolved decisions. - URL: https://www.hemory.com/blog/searchable-memory/share-informal-decisions/ - Language: English (en) - Author: Hemory Team - Published: 2026-11-04 - Last updated: 2026-11-04 - Summary: A communication workflow for an accepted informal decision, distinct from choosing a storage tool. A fictional internal onboarding experiment yields a project-thread message and a brief update for an absent designer. Hemory retrieves captured reasoning; posting, access and current instructions remain part of the team’s workflow. - Tags: informal decisions, project communication, decision updates, shared context A product manager and an engineer agree to try a shorter onboarding flow between meetings. A designer who missed the conversation continues preparing assets from the unchanged brief. The agreement exists, but the instruction has not reached the person whose work it affects. Share the accepted choice, what it applies to, what stays unchanged and what colleagues should do differently. Preserve the supporting exchange, but put the applicable instruction where those colleagues already work. An accessible update is more useful than a personal source link on its own. ## Establish what can be communicated as a decision An informal setting does not make a decision invalid. Nor does a chat message make a proposal approved. Check what the participants accepted and whether the choice was within their authority. Distinguish a local experiment from a wider rollout, an investigation from implementation, and a request from an accepted undertaking. Keep the accepted part clear while leaving the open part open. If the exchange does not settle the choice, communicate the proposal and the decision still needed. Do not turn it into a current instruction simply to make the update sound decisive. ## Identify who needs a different instruction Ask who will act differently because of the choice. That might be the designer preparing assets, the colleague handling an exception or the new owner reading an old plan. Then identify the record they use. For immediate coordination, a project thread may be enough. If the decision changes a specification or task elsewhere, update that instruction too and use the message to point to it. You do not need to copy the whole discussion into every location. For deciding whether the outcome creates a tracked action, use [conversation memory versus task trackers](/blog/searchable-memory/conversation-memory-vs-task-trackers/). This guide focuses on telling affected colleagues what changed. ## Recover the explanation without reconstructing the conversation The source may already be in a thread, note or project document. If the spoken exchange was captured in Hemory, built-in Q&A can recover the scope and reason across relevant conversations: > What did we agree about the shorter onboarding experiment? Find the accepted scope, what stays unchanged, and any later accepted revision. Separate the experiment from a proposal for wider rollout. Hemory preserves the discussion while you participate, including qualifications that might be reduced to “try shorter onboarding” in a quick note. You can use those details when someone who was absent needs a usable explanation. A compatible AI agent connected to Hemory can draft the notice from accessible context. Give it the current brief if that is outside its access, and ask it to separate accepted changes from suggestions. Review the message and apply it through your normal team workflow; retrieving the context does not itself post an update. If the exchange was not captured, ask the participants a focused clarification. Identify that later account as the source rather than present it as a recording of the earlier words. ## Example: a message that changes the right work This fictional example illustrates communication, not a customer case or Hemory output. The product manager and engineer have authority to run an internal experiment. They accept the shorter onboarding flow for internal test accounts to gather feedback. Existing customer onboarding remains unchanged; a wider rollout and its date have not been decided. The designer is preparing test assets from the existing brief. A project-thread message could read: > **Update for the onboarding test assets:** We agreed to use the shorter flow for internal test accounts to gather feedback. Existing customer onboarding stays unchanged. Please use the internal experiment scope when preparing the test assets; this does not authorize a customer rollout. A wider rollout and its date remain open. The experiment scope also needs to be reflected in the test brief so it does not conflict with this update. The last sentence identifies a needed update; it does not claim someone has already made it or accepted ownership. The message explains the practical effect without inventing a launch date or asking the designer to infer the scope from a transcript. The corresponding brief entry could be shorter: ```text Internal experiment: Use the shorter onboarding flow for internal test accounts to gather feedback. Existing customer onboarding remains unchanged. Wider rollout and timing are not approved. Basis: Product manager/engineer experiment agreement. ``` Keep a recognizable source reference when available. The shared entry itself must carry the limits the designer needs; access to a personal Memory should not be required to understand them. ## Check that the update can be used After sharing, check the point of coordination that matters. Can the affected colleague find the current brief? Is the unchanged customer instruction still clear? Is any ownership or implementation question still unresolved? A posted message is not evidence that assets were changed or that a task was completed. Use the normal work record for those results. If a later accepted decision changes the experiment's audience, update that part of the instruction and tell the affected people. For a reusable update, adapt this short structure: ```text Accepted choice or proposal: Applies to: What changes for the reader: What stays unchanged: Condition or decision still open: Current instruction and useful source reference: ``` Include only fields that help the reader act. Keep dates, owners and approvals unresolved when the agreement does not establish them. [Hemory](/features/) reduces the work of preserving and retrieving the spoken background. The shared update makes that context useful to the people doing the next task. ## FAQ ### Can an informal decision stay in chat? Yes, when the thread is accessible, clear and appropriate for the affected work. If a separate specification or task also directs that work, keep its instruction consistent. ### Do I need to share the full transcript? Usually a concise explanation of the choice, scope and conditions is more useful. Share supporting material when it helps and access is appropriate. ### What if someone challenges the decision? Distinguish a missing explanation from new evidence or a genuine authority issue. Recovering the reason can answer the first; the others may need a new decision. See [why project decisions keep reopening](/blog/searchable-memory/why-decisions-keep-reopening/).