How to Capture Slack Decisions in an AI Decision Log

A decision exists in your log only when a named owner confirms its outcome, its scope and the date it takes effect. Agreement, enthusiasm, silence, an emoji reaction and a model's confidence score are evidence for review, not approval. So have the owner invoke the agent in the thread, let it draft the record from that thread alone, and publish only after the owner confirms specific fields. Log two dates, when it was decided and when it takes effect, and when a later decision changes it, supersede the old record instead of editing it.

A decision made in Slack can disappear while everyone still remembers that one happened. Weeks later an operations manager rereads a long thread, asks who approved the change, and guesses whether the reasoning still applies. This is for business operations and knowledge-management owners who want that record without the reconstruction work.

What a decision record has to answer

A durable record has to answer six questions after the people involved have forgotten the conversation:

1. What was decided?
2. Who had authority to decide it?
3. What evidence and constraints shaped the choice?
4. Which alternatives were rejected, and why?
5. When did the decision take effect?
6. What later record changed or replaced it?

A thread rarely answers all six cleanly. One person proposes an option near the top. Another adds a constraint ten replies later. The owner approves a narrower version with "yes, do that," and the antecedent is ambiguous outside the conversation. A later reply may reopen one part without replacing the whole decision. A generic transcript summary is unsafe here because it compresses language before establishing authority and state, so it can turn a popular suggestion into the accepted outcome or drop the condition that made approval valid.

One GitHub issue asks for a workflow that reads a specific Slack thread, saves a decision with the thread permalink as its source, and flags ambiguous extraction for review instead of pretending certainty. That is an author-reported implementation need, not a universal rule, but its acceptance criteria expose the right failure mode: ambiguity must stay visible.

Four boundaries for the agent

Trigger: the owner asks for it

Do not scan every channel and convert likely discussions into records. Start with an explicit trigger in the relevant thread: the operations owner mentions the agent and says, "Draft this as a decision record for review." That narrows the source conversation, establishes intent, and keeps casual brainstorming from turning into policy. It also gives the agent a stable thread identifier. Slack's developer documentation explains how apps retrieve conversation history, identify threaded messages, and retrieve replies, subject to the scopes granted to the app. Use those primitives to read the selected thread, not unrelated channel history. See Slack's guide to retrieving messages.

Authority: verify the owner

The agent should extract the apparent decision owner, then verify that person instead of inferring authority from who spoke most. Your rule may use a process owner listed in an existing SOP, a project owner in the project brief, or an admin-maintained responsibility map. If the thread names no accountable owner, the output stays a draft and the agent asks for one. It must not assign authority to the requester merely because the requester invoked the workflow.

If your team already documents decisions with DACI, the approver is the person who confirms the record, and the driver, who makes sure the decision gets made, is the natural person to invoke the agent. Atlassian's template assigns a single approver who makes the final call, which is the same rule applied to a Slack record.

Evidence: only what the requester can open

The record may cite only evidence the requester can open and the agent actually read. A link posted in the thread is not evidence by itself: the agent opens it, confirms that it supports the attached claim, and preserves the direct source link. Restricted evidence creates a second rule. Do not copy sensitive text into a broadly visible decision page. Record the permitted conclusion, link to the restricted source, and say that supporting evidence is restricted, instead of paraphrasing material readers are not allowed to read.

Write: draft, confirm, then publish

Extraction and publication are separate steps. The agent drafts the record in the thread, highlights uncertainty, and waits for an authorized person to confirm the fields. Only then does it create or append the governed page.

The Kipwise Agent product page describes this thread-native pattern: a teammate mentions the agent once, replies continue in the same thread, the agent can search permitted knowledge, cite sources, write a page, and avoid creating a duplicate when an existing page already covers the topic. Those capabilities support the workflow, but your operating policy still decides who may approve a record and where it may be written.

Use a schema that survives later change

A prose-only page makes later search and supersession unreliable, so start with a compact structure such as this:

{
 "decision_id": "DEC-2026-042",
 "title": "Use weekly customer-risk review for enterprise accounts",
 "status": "active",
 "outcome": "Review enterprise risk signals every Monday",
 "scope": "Customer Success, enterprise accounts only",
 "owner": "Head of Customer Success Operations",
 "decided_at": "2026-09-09",
 "effective_at": "2026-09-14",
 "source_thread": "permalink to the Slack thread",
 "evidence": ["direct source link"],
 "alternatives": ["daily review", "monthly review"],
 "constraints": ["no automated customer contact"],
 "review_trigger": "risk model or account segmentation changes",
 "supersedes": null,
 "superseded_by": null,
 "confirmed_by": "authorized owner"
}

Keep both dates. Teams usually log when something was agreed and then get asked when it starts applying, and the second date is the one a reader needs. A record with only decided_at cannot tell anyone whether the rule is in force yet, and the decision in this example is agreed on one date and starts on a later one.

Do not let the agent omit fields silently. Missing evidence, owner, scope, or confirmation should produce a visible validation failure. One automation-governance issue makes a related practitioner case for an append-only record containing trigger, reasoning, alternatives, attribution, and reversal information before an automated mutation occurs. Its proposed design is specific to that project, but the core concern is useful here: a failed log must not leave a consequential change with no explanation. See the decision-log and operator-alerting issue.

Use three statuses:

• proposed: extracted but not confirmed
• active: confirmed and currently applicable
• superseded: replaced by another identified decision

Avoid a vague closed state. It does not tell a future reader whether the decision expired, was reversed, or was replaced. When a decision changes later, create an amendment or a new decision, link both directions, and mark the old one superseded. Never rewrite history so the old rationale disappears.

From thread to saved page

Capture one explicit thread. Require a thread permalink or a stable channel and thread timestamp, and store it before extraction. If the agent cannot retrieve the full thread, it stops and reports the missing range, because a partial transcript must not produce an apparently complete record.

Then classify each relevant message as a proposal, constraint, evidence, question, objection, or apparent approval, keeping links to the messages that support the outcome and the rejected alternatives. This is an extraction aid, not a final judgment. Open the attached evidence and mark inaccessible or stale sources. If the decision relies on a dashboard, file, or ticket that cannot be opened, the draft says exactly which claim remains unverified.

Draft the narrowest outcome the thread supports. Do not improve the decision, add rationale nobody stated, or infer a wider scope, and quote only when exact wording matters and the source can be shared at the destination. If the outcome is ambiguous, produce a proposed record with the competing interpretations and ask the owner to choose.

Before writing, search the existing knowledge base for the same process, policy, system, or project. The result can be:

• no related record, so create a new page;
• an existing active record, so draft an amendment or superseding record;
• a duplicate record, so append evidence rather than create another page;
• a conflicting record with unclear authority, so stop and route the conflict to the owners. Recency alone does not decide which rule wins.

A blank template leaves this step undefined. The DACI template has fields such as decision status, impact, participants, due date, outcome, background, options, and an approver, but a Slack automation still needs rules for finding an existing record, handling uncertainty, and preserving replacement history.

Post a compact preview in the source thread and ask the owner to confirm outcome, scope, effective date, evidence, alternatives, review trigger, and destination. Do not ask "Does this look good?" A generic confirmation encourages skimming and leaves ambiguity hidden. If the owner changes a field, keep the correction in the thread and update the draft. If a different person approves, verify that person's authority before accepting it.

Create or update the decision page only after confirmation, post the final page link back into the thread, then read the saved page and compare its required fields with the confirmed preview. A successful API response is not proof that the right content was stored. If the write fails, mark the Slack preview as not persisted and retry through an idempotent operation keyed by the decision ID, so a delayed response does not create duplicates.

Worked example for customer success operations

Suppose a customer success operations team debates how often to review enterprise account risks. The thread contains three options: daily, weekly, and monthly. A manager favors weekly review, provided the workflow never sends customer messages automatically. The head of customer success operations confirms Monday morning as the schedule and names a dashboard as the evidence source.

The agent should not produce "The team decided to automate enterprise risk management." That statement is broader than the thread. A defensible record says:

• Outcome: review enterprise account risk signals every Monday.
• Scope: enterprise accounts owned by Customer Success.
• Owner: Head of Customer Success Operations.
• Constraint: findings may be drafted in Slack, but customer contact requires a human action.
• Evidence: the opened dashboard definition and the source Slack thread.
• Alternatives: daily review was rejected as too noisy; monthly review was rejected as too slow for the stated operating need.
• Review trigger: account segmentation or the risk model changes.

If the dashboard cannot be opened, the record stays proposed. If an older page says reviews happen monthly, the new record must supersede it explicitly after approval. The old page remains available with a link to the replacement.

Test it against the awkward cases

Run threads that are harder than a clean demo:

1. A thread with three proposals and no approval must remain proposed.
2. A short approval such as "go with the second option" must resolve the correct antecedent or ask for clarification.
3. A linked source outside the requester's permissions must not leak text into the record.
4. A decision matching an existing page must update or supersede it instead of creating a duplicate.
5. A failed page write must not be reported as complete.
6. A reader searching by project, owner, or affected process must find the active decision and its source.

Track operational outcomes, not model fluency: median capture time, the percentage of records missing an owner or direct source, the number of duplicate records prevented, retrieval success for active decisions, and cases where a superseded decision was still followed.

Then put one recent decision through the whole contract. Choose an operational Slack thread that has a clear owner, at least one rejected alternative, and a source link, and run it through the steps above. Do not expand the pilot until the saved record matches the confirmed outcome, respects source permissions, links back to the thread, and can be superseded without deleting history.