There is a particular kind of promise that shows up often in workflow automation: the idea that eventually, with enough data and enough model capability, the system will be able to make the decisions too. Not just run the steps, but decide what to do. That promise is worth examining, because it obscures something important about what makes ops work hard and what makes automation actually useful.
The assembly problem is simpler and more tractable than judgment automation. It is also where most of the friction in recurring ops work actually lives. Understanding the distinction is the starting point for building automation that helps rather than creates new problems.
What Assembly Means in Recurring Work
Consider what a customer success manager does when preparing for a QBR. They pull usage data from the product analytics tool. They pull renewal dates from the CRM. They check the open support tickets in the help desk. They look at the Slack channel for the account to find recent context about what the customer has been asking about. They pull the previous QBR notes from Notion. They synthesize all of this into a presentation or document that frames the conversation.
Most of the time in this workflow is spent on assembly: collecting the right information from the right places and organizing it into a form that supports the decision-making. The judgment comes at the end, when the CS manager reads the assembled picture and decides how to frame the conversation, which risks to name, which wins to highlight, and where to push for expansion.
If you built automation that handled only the assembly, the CS manager would spend almost no time pulling data and almost all of their time on the part that actually requires their expertise: reading the picture and deciding what it means for the account relationship. That is a meaningful shift. The assembly in this workflow typically takes 60 to 90 minutes. The judgment typically takes 15 to 30 minutes once the information is in front of you.
Where the Automation Hype Goes Wrong
The dominant framing in the automation space for the past several years has been that the goal is autonomous agents: systems that do not just assemble information and run steps but actually make the downstream decisions. The CS manager does not just get the QBR prep assembled; the agent decides which accounts need a health intervention, drafts the email, and sends it without human review.
This framing is appealing because it sounds like the highest form of automation. It also tends to generate significant investment and press. But the promise does not match the reality of how judgment works in ops and revenue contexts.
Judgment in these contexts is not a classification problem with a correct answer that can be trained on historical outcomes. It is a contextual decision that involves information that is not in any tool: the history of a specific relationship, the nuance of a recent conversation, the sense that a particular account is heading somewhere good or bad that has not yet manifested in any metric. The CS manager deciding how to frame a QBR is drawing on things that are not logged anywhere.
Automation systems that attempt to handle judgment in these contexts do not actually automate the judgment. They substitute a mechanical approximation for a contextual decision, which is a different thing entirely. The output may look similar on the surface, but the quality and appropriateness of the decision degrades in exactly the cases where human judgment matters most: the non-standard situation, the relationship that has unusual history, the account that is technically healthy by every metric but about to churn for reasons the numbers do not capture.
The Cost of Over-Automation
When automation attempts to handle judgment and gets it wrong, the cost is not just an incorrect output. It is the loss of the human context that should have caught the error.
A CS manager who reviews assembled QBR data and decides how to proceed is in the loop. They see the picture, they apply their contextual knowledge, they make a call. If the automated assembly produced something incomplete or misleading, they will likely notice, because they are doing the judgment work and they know the account.
A CS manager who reviews an automatically generated QBR email before it goes out is in a weaker position. They are reviewing someone else's decision rather than making their own. Research on automation-assisted decision-making consistently finds that humans in review mode over-trust automated outputs, catch fewer errors, and perform worse than humans making decisions independently with the same information. The review illusion is a real problem: the human feels like they are checking the work, but the cognitive posture of reviewing is different from the cognitive posture of deciding, and it catches far fewer errors.
This matters practically. An ops workflow that automates judgment and hands humans a review step is not a conservative version of full automation. It is often worse than giving humans the assembled information and asking them to make the call, because it degrades the quality of human oversight while only partially reducing the time cost.
What We Automate Instead
Sauna Labs is built around a specific claim: the assembly problem is real, it is where most of the time in recurring ops workflows actually goes, and it is tractable to automate reliably. The judgment problem is also real, it requires human expertise and contextual knowledge, and automating it creates risks that are disproportionate to the time savings.
This means Sauna Labs handles the steps: collect the data from the relevant tools, organize it in the relevant format, execute the sequence of tool actions that constitute the mechanical work of the workflow. It hands off to the human at the point where judgment is required, with the assembled context in front of them so the judgment can be high quality.
The contract renewal workflow is a good illustration. The mechanical steps are: identify accounts approaching renewal, pull current ARR and usage data from the relevant tools, check for open support issues, draft a renewal timeline, create or update the renewal record in the CRM, and set up the notification sequence. These steps are entirely mechanical. They do not require judgment. They require navigating several tools in a specific order with specific data from each.
Sauna Labs runs these steps. When they are done, the account executive or CS manager gets a notification with the assembled picture: here are the accounts in your renewal window, here is the current health data for each, here is the support history, here is the timeline. Now they decide: which accounts need a call this week, which should get an email, which are at risk and need escalation. That decision is judgment. It belongs to the human.
When Judgment Is Itself Repetitive
There is a category of decisions that look like judgment but are actually consistent enough to treat as rules. If your team always escalates support tickets older than 72 hours to the senior tier, that is not judgment: it is a policy. If a renewal with health score below a certain threshold always triggers a call from the account executive, that is a rule, not a decision.
These policy-like decisions can be automated, and they should be. Sauna Labs can represent them as conditions in a playbook: if X, then take step Y automatically without requiring human review. The distinction from judgment automation is that these conditions are explicitly defined by the team, reflect a deliberate policy, and apply consistently to a well-characterized class of situations.
The error to avoid is treating judgment calls as if they were policies. A system that decides which renewal accounts need escalation based on a health score threshold is enforcing a policy. A system that decides which renewal accounts need escalation based on a complex reading of relationship history, recent sentiment, market signals, and the account executive's read on the relationship is attempting to automate judgment, and it will make the wrong call in the cases where judgment matters most.
The Design Choice Behind Sauna Labs
We spent a significant amount of time early on debating whether Sauna Labs should try to do more on the judgment side. The market expectation for AI tools in this space is that they will eventually handle decisions autonomously. There is pressure to position in that direction.
We decided against it, and the reason is not caution or a lack of ambition. It is that the assembly problem is large enough, and the judgment automation problem is risky enough, that doing both well is harder than doing one well. Teams that automate assembly reliably get measurable, consistent returns: faster workflows, less time on mechanical coordination, more time for the work that requires their expertise. Teams that attempt to automate judgment get mixed results that are hard to evaluate and create new oversight burdens.
We would rather solve the assembly problem cleanly than partially solve a more ambitious problem and create new risks in the process. That is the design choice, and it is the one we stand behind.