The phrase "AI watches how your team works" sounds either very useful or a little unsettling, depending on how you come to it. Both reactions are reasonable. The question worth asking is: what is actually being observed, and what does the system do with it?
For Sauna Labs, observation means recording the sequence of tool interactions your team members perform when completing recurring tasks. Not the content of what they type, not screen recordings, not keystrokes. The sequence: which tool was opened, which object was acted on, which tool came next, and what kind of action was performed at each step. The goal is to understand the structure of recurring work, not to monitor individuals.
Sequence Is the Signal
The insight behind the observation layer is that recurring work has a shape. When your ops team runs a sales handoff, they follow a sequence. When they prep for QBR, they follow a sequence. Those sequences are not written down anywhere. They live in muscle memory, accumulated over months of doing the same type of work. The sequences vary slightly person to person, and they evolve over time as tools change or team preferences shift. But the core shape is stable.
If you want to build automation that reflects how a specific team actually works, you cannot design it from scratch on a whiteboard. You need to observe the actual sequences first. Process documentation is usually a sanitized description of how work is supposed to happen. The observation layer captures how it does happen, including the detours, the workarounds, and the steps that no one thought to document because they feel too obvious to write down.
When we connect Sauna Labs to your tools, the observation layer starts logging events: a CRM record is opened, a Notion document is updated, a Slack message is sent in a channel associated with an account, a contract is accessed. These events are tagged with the tool they came from and the type of object they involve. Over time, patterns emerge: certain sequences of events happen repeatedly, across multiple instances, in a consistent order.
What the Observation Layer Does Not Do
This is worth being precise about, because confusion here is where legitimate concerns arise.
The observation layer does not read message content. It knows that a Slack message was sent in a channel associated with a specific account, but it does not process what the message said. It does not read the text of a Notion document, only that a document in a certain category was opened or edited. It does not log keystroke data, cursor position, or screenshots.
It also does not track individual performance. The observation layer is not a productivity monitoring tool. We built it to understand workflow patterns at the team level, not to generate reports on how quickly specific people complete tasks. The patterns it surfaces are about recurring work structures, not about individual behavior.
We are not saying that all observation tools behave this way. The market includes tools that do log content, do monitor individuals, and do generate productivity scores. We do not do those things, and we think those approaches get the problem framing wrong. A system designed to surveil workers creates a different kind of team dynamic than one designed to understand and automate the connective tissue of their work. We chose the second approach deliberately.
From Events to Patterns
The raw event log from the observation layer is a time-ordered sequence of tool interactions, tagged by tool type, object type, and action type. To be useful, that sequence needs to be chunked into recognizable workflow instances.
The pattern recognition process looks for clusters of events that co-occur repeatedly, in a similar order, often triggered by the same kind of initiating event. A deal closure in the CRM is a common initiating event. The events that follow in the next 24 to 48 hours tend to form a cluster: CS platform record update, contract document access, Slack message in account channel, email activity. When that cluster appears consistently across many deal closures, you have a pattern: the post-close handoff workflow.
The pattern is represented as a directed sequence of steps, each step associated with a tool, an action type, and the conditions under which it typically occurs. That representation is what becomes a playbook draft.
What a Playbook Draft Is and Is Not
A playbook draft is a proposed formalization of a pattern the observation layer has identified. It describes the sequence of steps, the tools involved in each step, and the typical trigger condition. It is not a finalized automation. It is a starting point for a human to review.
The review step is not optional and it is not a concession to human anxiety about automation. It is how the playbook becomes accurate. The observation layer is good at identifying that a sequence happens. It is not a substitute for human judgment about why the sequence happens the way it does, which parts are load-bearing, and which parts are artifacts of individual preference that should not be locked in as requirements.
When a team member reviews a playbook draft, they are doing the work of translating a behavioral pattern into an intentional process. They confirm that the sequence is correct, adjust steps that were captured imprecisely, add conditions the observation layer did not have enough signal to detect, and decide where the automation should stop and hand off to a human. That review is real work. It typically takes 30 to 60 minutes for a workflow the team knows well. For workflows that are more complex or less consistent, it takes longer.
The Compounding Effect Over Time
One thing that took us a few months of building to appreciate fully is how much the quality of the observation improves with time.
In the first weeks after connecting Sauna Labs to a team's tools, the observation layer is accumulating events without much pattern signal. It sees individual instances of work but does not yet have enough repetition to identify the shapes of recurring workflows. This is normal and expected. Recurring workflows, by definition, repeat over time. A workflow that happens monthly takes at least two or three months to appear as a confident pattern.
After three to four months, the signal improves substantially. The observation layer has seen enough instances of the major recurring workflows to produce confident pattern representations. The playbook drafts generated at this stage reflect real team behavior rather than tentative guesses.
There is also a compounding effect from corrections. Each time a team member reviews and adjusts a playbook draft, that correction feeds back into the system's understanding of that workflow. The next draft for a similar workflow starts from a better baseline. Over six to twelve months, the observation layer builds a detailed picture of how a specific team actually coordinates work across their tools, and the playbooks it generates get progressively more accurate with less review required.
The Limitation Worth Naming
Observation-based automation has a real limitation that we want to be direct about: it can only automate what it has seen. If your team has a workflow that happens infrequently, or that is performed inconsistently enough that the pattern never crystallizes, the observation layer will not produce a playbook for it. You would need to either wait for more instances to accumulate or describe the workflow manually.
There is also a class of workflows where the steps are observable but the sequencing depends on conditions that are not visible in the event log. A workflow where the next step depends on the content of a Slack message, for example, cannot be fully automated from observation alone, because the decision logic requires reading content that the observation layer intentionally does not process.
These are real constraints, not edge cases. The observation-first approach is well suited for recurring mechanical workflows where the sequence is mostly stable. It is not the right approach for workflows where the primary work is the judgment call, not the coordination steps around it. For those, the right answer is probably better tooling for the judgment itself, not an attempt to observe and automate it.
The distinction between automating the steps and automating the judgment is the core design principle behind Sauna Labs. Observation is how we learn the steps.