The agent asks who owns the launch. Somebody answers. Later, the agent asks again in another channel. Eventually a person pastes the same answer into a document so the next agent can find it.

Give the task an address#

A channel name is a starting point. A thread needs the channel identifier and the parent message timestamp, and a particular answer needs its message reference. Keep those identifiers together when the task moves to another agent or surface.

A release-preparation task arrives with a channel, a thread, and a question about the launch owner. The agent reads that thread first. If it needs a broader search, it searches for the missing fact and returns to the original conversation with the result.

This prevents a common failure: the agent searches broadly, finds a familiar phrase, and replies to the wrong discussion.

Separate an answer from a mention#

Search results contain suggestions, questions, superseded decisions, and jokes. A person's name appearing near "launch owner" does not establish ownership.

Have the agent return a small answer record:

Field	What it should establish
Question	The specific decision the task needs
Proposed answer	What the agent believes the conversation establishes
Message reference	Where the answer came from
Scope	The launch, account, project, or period it applies to
Conflict	Any later statement that changes or disputes the answer
Missing fact	What still needs a person's decision

If the thread contains conflicting owners, the agent shows the conflict and asks the narrow question that resolves it. It does not average the two answers into one confident sentence.

Carry the answer across the seam#

Suppose the owner was agreed in email and later mentioned in Slack. A Slack-only lookup cannot establish the contents of an email it has not read. The handoff needs the authorized source reference, the scope of the decision, and the result of the earlier task.

Shared reviewed memory is where an approved, reusable fact goes, saved with enough context to know when it applies. Keep a changing launch assignment separate from a stable procedure for finding the launch owner. The assignment needs refreshing. The procedure belongs in a skill.

Not every message is a permanent company instruction. Conversation history is evidence of what people said, and review decides what a later task relies on.

Choose the message operation deliberately#

A new channel message, a thread reply, and an ephemeral message have different audiences and effects. Review the destination alongside the text.

Slack's message-posting documentation describes using thread_ts to reply in a thread. It also explains the top-level text fallback for messages containing blocks.

A task instruction that works:

Read this thread before drafting a reply.
If the question is already answered, return the answer's message reference.
If a reply is needed, show the channel, parent thread, and proposed text.
Do not create a separate channel message unless that is the requested action.
After posting, retain the resulting message reference.

The Slack operation reference shows the inputs for replies, message updates, search, and other operations. Enable only the tools the task needs.

Handle uncertain delivery without posting twice#

If a posting attempt times out, inspect the conversation before repeating it. If a successful answer needs a correction, update the existing message through an authorized operation instead of adding a competing answer.

An incoming message also needs interpretation before it becomes a new task. A repeated notification, a quoted old request, and a genuinely new follow-up should not all start the same work again. Preserve the source message identity in task intake and decide which changes deserve a fresh attempt.

Rehearse the failures people already recognize#

Test a thread with these cases:

An answer in the first reply.
A later correction.
A similarly named project in another channel.
An interrupted posting response.
An answer the connected identity cannot access. The agent should state that access gap instead of implying the answer does not exist.

Use the action history to inspect repeated calls through Deixic and review their targets and inputs. Keep the successful answer reference with the task.