Tana: turn meeting decisions into actions you can approve and track

Move meeting decisions to where the work happens

The Tana discussed here is an AI meeting platform for teams, separate from the company's Tana Outliner note-taking product. It brings calls, transcripts, documents and tasks together, and uses connected services to turn discussions into proposed actions.

Imagine a product team discovers a mobile login bug during a demo. A summary saying “fix login” still leaves an engineer looking for reproduction steps, confirming the responsible team and creating a Linear issue. Operations may also be waiting for a message. The meeting recorded what people said, but the work has not reached their tools.

Tana makes that handoff reviewable: draft the issue and outgoing message, let someone approve them, then keep showing the execution results. This article focuses on the path from discussion to action draft, approval and external outcome.

Connect the service that will actually receive the work

Imagine finding a mobile login bug during a meeting. Following the Linear connection guide, connect the account through personal integrations in Settings → Integrations and check the authorized scope. Connections are per account; mentioning a tool during a meeting does not give the system access to it.

Discussion can first become a document or task inside Tana. Here the focus is creating issues or sending messages in connected services. Those actions are drafted for acceptance; internal automatic summaries follow different rules.

Turn discussion into a draft people can inspect

1. State the goal. For example, find an existing mobile-login issue, or create one in the Web team with reproduction steps if none exists. Searching and creating are separate actions; “log it” can hide an unclear destination.
2. Open the action details. Check the service, team, description and information to send. Meeting actions can carry transcript and screenshot context to help the recipient understand the original problem.
3. Revise the content. The action guide allows editing sending instructions. The service scope is set when the action is drafted; mentioning another service in the text does not automatically grant access to it.
4. Accept to execute. Confirmation applies to specific content and a destination, rather than general trust in AI. Ideas that are not yet commitments can stay in the discussion.

The action draft makes spoken intent inspectable before it changes another tool, giving people a chance to catch missing information or a wrong destination.

Stay with the card and check the external result

After acceptance, inspect the action card and its result links. States include running, sent, partially complete, waiting for the user and failed. Open the actual issue to confirm the team and content.

If issue creation succeeds but a message fails, the issue already exists. Do not retry as if nothing happened. Establish which parts are complete and continue with what remains. Approval decides whether to start; actions across several tools are not automatically all-or-nothing. Keeping the approved content and actual results on the original card helps the team finish the right work.

Make approval refer to something people can inspect

“Register this for me” may not specify a team, reproduction steps or an owner. An action draft makes these gaps visible before sending. People approve the content about to reach their colleagues, not merely a general permission for AI to act.

For the login issue, adding reproduction steps improves the description. Adding access to a service that has not been authorized changes what the action may use. Writing both requests in the same text field does not make them the same kind of edit. Separating content from permitted services helps people understand what their approval can actually cause.

A useful confirmation page answers three concrete questions: where will this go, what will it say, and what is missing? An idea that has not become a commitment can remain in the discussion. Every sentence need not become a task.

Preserve the connection from approval to outcome so people continue the right work

After approving task creation, a person wants to know whether that task now exists. A separate, unrelated result list forces them to match titles and times again. Keeping results on the original card lets them follow the decision they just made.

This matters especially when some actions succeed and others fail. The created issue has its own link; the unsent message still needs attention. Calling everything a failure can invite duplicate issue creation. Calling everything complete can hide unfinished work.

The useful principle is to keep approved content and each later outcome findable. Starting an action, finishing it and establishing a correct result each need their own evidence.