Why we replaced Slack, Notion, and Granola with TalentOS

We replaced Slack, Notion, and Granola in our team’s working setup because we wanted conversations, documents, meeting notes, and AI contributions to stay with the same project. TalentOS Rooms became the place where we do that work together. This is our team’s experience using the product we build, rather than a claim that every team should make the same switch.

We are still collecting evidence from external teams. We are not presenting a measured time saving, a cost comparison, or proof of feature parity with three mature products.

The reason for the move is easier to explain through the work than through a list of features.

We wanted the discussion and the work beside each other

A familiar project starts in a conversation. Someone takes notes, someone writes a document, and someone asks their AI to improve it. The next decision depends on all three, so the team passes links and explanations between them.

Each tool can be good at its own job. The repeated task is reconnecting the parts: which notes explain this draft, which decision changed it, and what should happen next?

Our preference is to keep a project’s working conversation and outputs in its Room. A Room is a shared place for the people and agents involved in that project. Members can read the conversation shared there. The context needed to continue the work has a recognizable home.

That is the unit we designed around: a project people are doing together.

Rooms also keep shared memory. TalentOS can update it automatically after substantive agent exchanges, using what was discussed in that Room. Members can inspect and correct the page. The next conversation can start with useful project context already available, instead of asking someone to paste the same explanation again.

If Slack and Claude had a baby

That is a quick way to describe the intuition: the social context of a team conversation, with AI able to contribute useful work inside it.

The analogy only goes so far. Slack already offers AI search across connected applications. Claude supports shared projects and project knowledge. We are not claiming that one lacks AI or the other lacks collaboration.

Our design choice is to make people and their own agents participants in the same Room. Each AI acts for a person, and AI-written replies remain attributed to that owner. People can also bring Claude Code or Codex into the work. The team does not have to abandon an agent it already likes to share a project.

Personal chats, personal memory, private runs, and approval decisions remain owner-only. The shared project does not require everyone’s private preparation to become company-visible.

Documents and meeting notes need a next step

We now keep documents and meeting notes with the work they belong to. The point is that a useful note can lead to a revised brief, a proposal, or a decision without a teammate having to reconstruct its context elsewhere.

An illustrative project loop looks like this:

1. Keep the project brief and intended outcome in its Room.
2. Add the relevant meeting notes and confirm the decisions they record.
3. Ask an agent to update the working output using those decisions.
4. Have the responsible person review it and name the next action.

This is a suggested way to work, not a claim that every step happens automatically. Capturing a meeting and agreeing on what it means remain separate jobs. A note that says “discussed a launch date” should not become a confirmed launch commitment.

Notion Agent can work with pages, databases, and connected context. Granola specializes in meeting capture and notes. If those are the parts of your workflow you most depend on, test them directly before replacing anything. Keeping meeting notes in TalentOS does not imply that every capture feature works identically across products.

Repeating work should keep its method

Some work repeats. A weekly brief should not depend on remembering the exact prompt from the last successful run.

In TalentOS, a skill preserves a reusable method: what inputs to bring, how to do the job, and how to check it. A routine gives repeating work a standing schedule. We use routines as part of how we work; the important question for each one is whether its output helps someone do the next thing.

Together, those features close a useful loop. The project accumulates context in its Room. A correction can become part of a better skill. The next routine can use the reviewed method once its version is updated. That is the compounding value we want from the workspace: everyday work leaving a better starting point for the next job.

This is also where the workspace has to earn its place. Putting conversations and files together is useful only if teammates can find the method, understand the result, and continue without another private briefing.

Test one project before moving your stack

Moving a team’s habits has a cost. People need to know where the current work lives. A new workspace can become one more place to search if the old and new systems both appear authoritative.

Choose one bounded project. Name the working home for its conversations, source notes, and accepted output. Keep your old tools available while you check what the new workflow covers and what it does not.

At the end, ask a teammate who missed the latest discussion to find the current decision and explain the next action. Count the links, explanations, and corrections they still need. Also test the functions your team relies on, such as finding an older document, capturing a meeting, and handing a file to someone outside the project.

That test is more useful than deciding which product has the longest feature list. Our team wanted people and their AI working beside the same project. If you have the same problem, start with one shared workflow and judge the result for yourselves.