Tana: turn meeting decisions into actions you can approve and track
Tana is an AI meeting platform for teams, connecting calls, transcripts, documents and tasks. Discussions can become proposed actions that you approve, send to connected work tools and follow through to their results.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
After an action partly succeeds, what should the approval panel show?
Scenario
Design a post-meeting “pending actions” panel for a team. It can create Linear issues and send Slack notifications. This is your own product proposal; you do not need to reproduce Tana or send real messages.
Known conditions
- The meeting identifies a mobile login bug, with reproduction steps and screenshots recorded. The target team is Web, but no owner is confirmed. “Maybe redesign the entire login page next month” is discussion, not an agreed task.
- AI drafts two actions: A creates the Linear issue; B notifies #ops in Slack and references the issue link produced by A. Each action has its own ID, destination service, content version and execution state. B depends on A's link.
- Before approval, the user changes A's team from Web to Mobile. Require confirmation of the final destination and content: approval for an old version must not authorize the modified action automatically. Make the unknown owner visible; design how to fill it in or explicitly allow an unassigned issue.
- A then succeeds and has a real issue link. B definitely fails without sending. A later variant is that B times out and whether it sent is unknown. This differs from confirmed non-delivery. The panel must neither repeat A nor display an unknown result as sent.
Deliverables
Sketch four states: awaiting review, changed and awaiting renewed approval, partly complete, and outcome unknown. Explain how discussion differs from commitment, and approval from execution results. Write the message and disabled-action conditions for handling B again. Use two observation tasks to check whether users duplicate A or mistake unknown for unsent; do not assume test results.
Explore the reasoning
- Separate discussion from an executable commitment. Keep the identified bug separate from the possible future redesign. Show reproduction evidence and the missing owner. An AI draft does not replace a team decision.
- Bind approval to a visible version and destination. After A changes to Mobile, show the final content and version again and invalidate the old approval. B needs A's actual output link; an invented example URL cannot make it ready to send.
- Show each actual result in the same place. Keep A's successful link and destination. For B, show confirmed non-delivery and its reason. Partial completion must not erase completed work; any retry entry concerns only the unfinished part.
- When the result is unknown, first check whether the action ran. The external service may have completed it before the request timed out. Look up the original request or actual result before deciding to retry. If the backend supports a fixed request ID for recognizing repeated submissions, reuse that ID on retries so the service can recognize the same request and avoid running it again. This ID is often called an idempotency key. Do not create a new request; changing a button label alone cannot prevent duplicates.
- Observe understanding under failure. Ask a user to continue from A successful/B failed, then introduce B's unknown timeout result. Watch whether they can identify existing objects, missing evidence and the next step rather than relying on a single status color.