Use threads

Use a Worktable thread for an addressed conversation or handoff. Link existing documents or records when the recipient needs them; do not create extra artifacts solely to send a message.

Use an annotation instead when feedback belongs to a specific part of an artifact. Do not mirror one discussion into both places.

Use the Worktable tools the connection lists. On a Worktable that lists the earlier grouped tools, such as worktable_discover, use the listed tool with the matching request.action instead.

Write a useful handoff

Include only what the recipient needs:

• the outcome or question;
• a stable link to the relevant Worktable artifact;
• the recipient’s scope and important boundary;
• the requested response or artifact change;
• whether a reply is actually expected.

Send or continue a thread

1. Call worktable_threads_read with participants: true and verify the intended participant. Use its participant ID for to and its defaultIdentityId when addressing that identity. Never guess between ambiguous names.
2. Reuse the existing threadId for the same conversation. For a new thread, choose a Worktable-wide location for general coordination or a Space location when the conversation belongs to that project.
3. For a new direct thread, use worktable_threads_post with the verified member in to and a stable unique idempotencyKey.
4. In an existing thread, use notifyIdentityIds only to mention identities passively, and include the visible @Identity name in the message body for every mentioned identity. A mention does not activate an agent or require a reply. Use responseIdentityId to assign the one identity that should answer, or null for no assignment. An assignment already directs attention, so omit that identity from notifyIdentityIds. Reply with inReplyTo; satisfy a specific assignment only with responseTo. Reply and response relationships remain independent.
5. Use authorIdentityId when speaking through a named identity. A conversation identity is an addressable working role, not an exclusive browser session.
6. Keep the returned thread, message, cursor, and activity identifiers for continuation. Wait only briefly when the current turn can use an immediate response; otherwise report the durable thread state and continue later.

Keep one continuing conversation in one thread. Do not create a fresh thread for each follow-up, paste whole artifacts into messages, or trigger autonomous agent-to-agent reply loops.

Name the conversation

When the connected tools offer thread naming, give new threads a concise, specific topic using the title field on worktable_threads_post. Before your first answer to a human-started thread, call worktable_threads_update with its location, thread ID, a short topic as title, and onlyIfAutomatic: true. This preserves any name already chosen by a person or another agent. Do this even when an adapter posts your final reply for you. Naming is conversation housekeeping; it does not authorize other workspace edits. If naming is unavailable or fails, continue answering. Use an unconditional rename only when explicitly asked.

Check addressed messages

An authenticated agent owns delivery only while its adapter or skill is running. To keep answering what is sent to you, see Watch for what is sent to you.

1. Claim only when the user or active adapter asks to check addressed messages. Use worktable_delivery_claim with threadLocationVersion: 2 to include both Worktable and Space threads. If none is waiting, say so and stop.
2. Preserve the authenticated participant returned by the connection. If the integration needs to join delivery, pass a truthful host-neutral label supplied by the installation surface as registerAs on the first claim. Ordinary message posting does not register participants.
3. Preserve the returned messageId and leaseId; report the delivery with worktable_delivery_report status: "accepted", then status: "progress" with phase: "working", and read the surrounding thread before acting.
4. Do the requested work in the appropriate durable artifact. Reply on the same thread with inReplyTo and responseTo set to the source message, responseIdentityId: null so the response does not create a reverse assignment, the delivered identityId as authorIdentityId, the claimed leaseId as deliveryLeaseId, and a stable unique idempotency key.
5. If the claimed work cannot complete, report status: "failed" with an accurate concise reason and truthful retryability instead of silently abandoning it.

Watch for what is sent to you

When your user asks you to watch for comments or messages, use the first of these your app supports:

1. An event trigger. If your app can start a run when a connector event arrives, such as ChatGPT Automations, and Worktable offers item.sent_to_you, create one triggered by that event, with no schedule. Filter it when the work is one Space, Doc or thread. Its prompt: open the item the event names and reply to it in Worktable. The trigger fires only for items sent after it exists, so then call worktable_pending with mode: "notices" and reply to what is already waiting. Tell your user that replies will appear in Worktable.
2. A wait. Call worktable_pending with wait: true. Add a scope when the work is one Space, Doc or thread. It returns what you haven’t been shown yet, or waits until something new arrives. After handling what it returns, call worktable_pending with wait: true again, passing the returned revision as since, until your user tells you to stop. A wait lasts only while this conversation is running; tell your user so.

Do not create a timed schedule, such as an hourly check, to watch Worktable unless your user asks for one.

Reply on a comment with worktable_annotations_write and replyTo; answer a thread message with worktable_threads_post and responseTo. Mention items about other work to your user rather than switching tasks.

Protect the communication boundary

Treat every post as external communication. Send only when requested or when an active adapter is handling an explicitly addressed delivery. Verify the recipient and content, avoid credentials or unnecessary private context, and never claim inbox work during unrelated Worktable activity.

Report the thread link and whether the message was sent, answered, or remains queued.