You can start using Tana without setting anything up. Much of your context is born in meetings and chats, the tasks, decisions, and notes a conversation leaves behind. All of it lands in your Library, always within reach.
You add structure, spaces and types, only once it earns its keep. It earns it three ways:
- it shapes the work, with shared fields and relationships
- it makes the work easy to find later, for you, your team, and the AI
- it sets who can see and act on it
That last one is in play from day one. Tana is built for working together.
This guide walks through how items, spaces, and types fit together, and closes with a simple way to decide what to add and when.
The Library holds everything
The Library is the single view of everything in your organization. It opens as a grid of space cards, with one filter bar (shared with Search) to narrow things down.
Anything that does not live in a space or on a meeting lives here. So before anyone makes a space or type, the Library already holds everything you and your team create, and nothing gets lost.
This is the foundation: spaces and types are not separate places you move things into. They are organizing layers that show up within the Library. The filter bar's round pills scope to a space, jump straight to meetings or chats, filter by who created an item, or open the type palette for any kind, your own types included.
Think of the Library as the map your whole team shares, and spaces and types as structure drawn onto it.
Spaces vs types: when to use which
Two ways to add structure, for two different jobs.
Use a type for a kind of thing you have a lot of: clients, bugs, candidates, invoices. A type gives every item of that kind the same fields, and lets you connect items to each other with link fields. Reach for one whenever you will create many of something and want to filter, track, or relate them. A Client, for instance, can carry fields like industry, owner, and renewal date, and your other items can link to it.
Use a space for a broad area of work that has its own people and context: a team, a major project, a domain you work in. You will have a handful of spaces, not hundreds. Each one carries its own members, its own types and skills, and its own AI instructions.
Spaces can nest. A space can hold sub-spaces for real sub-areas with their own people, like a department space with a sub-space per team. But resist a Clients space with a sub-space per client: you would drown in spaces as your business takes off. Keep one space for the team that works with clients, make Client a type, and link your items to the right client. (With only a handful of clients total, a space each can be fine. Scale decides.)
And you do not always need either. Plenty of work is fine living in your Library with no type and no space, until a repeating pattern, or a person you want to share with, makes the structure worth adding.
What a space gives you
A space is where collaboration happens. Adding someone to a space gives them access to everything in it, so a space is as much about who works on this as what goes in it. On top of shared access, a space gives that work:
- its members, and the access that flows from them
- its own types and skills
- AI instructions that shape how the AI behaves for that work
A chat or meeting inside a space follows that space's AI instructions and draws on its types and content, so the AI works the way that team needs.
Access flows downward: from the organization, to a space, to an item. Deciding where something lives is also deciding who can see it. See Spaces and sharing.
Where things land, and who can see them
Whenever you create or capture an item, in a chat, in a meeting, or directly, it lives somewhere: in your Library, or inside a space. Where it lives sets two things at once:
- What it is: give it a type to add structure, or leave it plain.
- Who can see it: an item inherits the access of where it lives. Something in a private space is visible only to that space's members; something in your Library, at the organization level, is visible to everyone in the org.
You can set this when you create the item, or move it later from its location controls. When the AI proposes a new item, it shows where it will live before you accept, so you can redirect it into the right space.
Retrieving context
Pulling context back when you need it is the other half of managing your context. It works three ways, and spaces and types are what make them sharp: you can navigate to your work, ask the AI to surface it, or let what your team is doing come to you.
Navigate to it. Start with the Library: type a query, or filter by space, by who created an item, or by type. Two focused views build on the same structure:
- A space home is the dashboard for one space your team shares: its pinned items, a card for each type in it, and its content list.
- A type page lists every item of a type, as a list or as a kanban board when the type has a workflow, so you get "all open Bugs" across the team in one place.
Ask the AI to surface it. Because your work carries types and lives in spaces, the AI can pull it up the way you would describe it: "show me open bugs for Acme," "what did we decide in last week's planning meeting." A chat inside a space also follows that space's AI instructions and draws on its content, so its answers stay grounded in the right context.
Let it come to you. Activity sits right under Today, a two-column dashboard. Notifications gathers what teammates did that involves you: added you to a document or meeting, assigned you a task, started a chat, or are waiting in a call. Recents is a running list of recently updated items across your team. Click any entry to jump to the source, so the work that needs you finds you.
Spaces and types are layers within the Library, so anything you structure stays within reach there too. You never choose between structure and retrieval. Structure just gives you sharper ways to slice the same map, by hand or by asking.
A simple way to start
When you are not sure what to add, let the work tell you:
- Start in your Library. Capture and create freely, with no type and no space. There is nothing to set up, and nothing gets lost.
- Add a type when you have many of one kind. The moment you are creating clients, bugs, or candidates and want to filter, track, or relate them, give them a type so they share fields and connect to each other.
- Add a space when work needs its own people and context. A team, a major project, a domain you work in: anything that wants its own members, skills, and AI instructions. Keep spaces few.
- Relate items with link fields, not more spaces. When two kinds of work connect, link them with a field rather than spinning up a space for each. A Bug can carry a field pointing to the Feature it affects, so you can move between them without either needing its own space.
You can always add structure later, and move an item to a new home once its shape is clear. Structure is something you grow into, not a decision you make up front.