Back to blog

Your agent wasn’t in the meeting

When people disagree about the plan, giving each of them an agent gives the disagreement somewhere new to go.

I was in a pricing meeting while three people from my company were having the same argument eight meters away, through a thin wall. We reached different answers. Neither room knew about the other.

People from both rooms shipped different things into the product. Our billing broke.

By then, the disagreement was running in production. We had to deal with the broken billing and work out how two groups of people had walked away believing they knew what we were doing.

I've spent enough time doing that reconstruction to resent it. You hire people for their judgment and then spend part of the week figuring out whether they're disagreeing with you or just working from something you said last month.

Now give everyone an agent.

One room can leave with a new pricing page, a sales sequence, and an updated forecast. The other can leave with a different set. Each agent might have followed its instructions perfectly. We would still have two versions of the plan, with considerably more work attached to each.

This is the part of multiplayer AI I care about. When my agent does something that affects your work, how do we find out whether we're working from the same decision?

The work loses the argument behind it

Imagine a sales lead testing the idea of a longer free trial. She asks her agent to think it through, pushes back on its first answer, and asks for a draft proposal. That conversation contains hesitation, objections, and a few things she hasn't checked yet.

Then she shares the proposal.

A colleague picks it up while preparing a launch. His agent reads it as background and writes the announcement around the longer trial. The hesitation was in her conversation. The trial length is in the document. Unless the status travels with the document, he has to know to ask.

Giving his agent access to more material might help. It could find the existing policy and notice the difference. But somebody still has to say whether the new document is an experiment, an approved replacement, or an idea we abandoned on Tuesday.

We already do this work for one another. “Ignore that deck.” “Ask Maya before you use those numbers.” “Yes, we discussed it, but we didn't agree to do it.” These are useful instructions. They rarely survive into the files an agent reads.

And once an announcement repeats the proposal, the next person has two documents saying the trial is longer. Both may trace back to the same unapproved idea. We have created more apparent agreement without making another decision.

What I want to borrow from Git

Software teams have a useful convention: a main branch. People can work on separate versions, but there's an agreed version that everyone else builds on, and a process for accepting changes into it. Git supports this kind of workflow; the team decides who gets to accept what.

Our billing incident shows the limit of keeping that discipline inside the codebase. You can review the implementation of a decision without discovering that another team is implementing a different decision. We need the distinction between proposed and accepted changes to survive in the rest of our work too.

The sales lead should be able to explore a longer trial without accidentally changing company policy. Her proposal should stay attached to the current decision, so a colleague can see both. If the pricing owner accepts it, the record should say when it takes effect and which customers it applies to.

There is a limit to the analogy. Two teams can make incompatible promises without editing the same file. One changes a sales deck; another changes the checkout. Comparing the text won't necessarily tell you whether the business still makes sense.

Even an apparent contradiction needs investigation. Seven days and fourteen days might be different offers for different customers. A system that flags every difference as a crisis will become another inbox people ignore.

The useful question is specific: these two instructions appear to apply to the same customers, during the same period, and they promise different things. Is that intentional?

An agent could bring that question, with the relevant sources, to the person responsible. That's a much more useful interruption than asking a founder to reread everything the company produces.

Deciding is only half the job

Suppose we approve fourteen days.

Updating the policy is easy. Finding the work that still assumes seven days is harder: the checkout, the onboarding emails, the sales deck, the forecast someone prepared yesterday. Some need changing. Some describe old customers and should stay as they are.

This is where I think multiplayer has to earn its keep. I want to see what a decision affects, who is dealing with it, and which work is still using the old assumption. Otherwise we've just made a tidier place to announce changes that people miss.

It also means keeping enough history to question a decision later. If we lengthened the trial because customers needed more time to finish setup, that reason matters. Fixing setup might make the decision worth revisiting. A conversion chart alone won't tell us what to do.

The person who owns pricing gets to make the call. They also need to hear from the person who found evidence that the call is wrong. Making the CEO's documents win every argument would automate one of the worse habits a company can have.

What this means for Sauna

This is how I think about multiplayer in Sauna. A personal agent learns how you work: your preferences, your conversations, the things you've asked it to do. As soon as its work affects somebody else, it needs to account for decisions that neither you nor it gets to make alone.

The shared work needs a life beyond the chat that produced it. People and their agents need somewhere to return to, propose changes, and establish what everyone else can rely on.

Take the trial proposal. I should be able to send a colleague directly to it. She can correct a number, ask her agent to check an assumption, or leave an objection for the owner. The next person to open it should be able to tell what changed and whether it was accepted, without reading either of our private chats.

We still need room to think privately. I want to argue with my agent, try bad ideas, and abandon drafts without turning all of it into company knowledge. Sharing a proposal should be a deliberate act. Access to it shouldn't quietly grant access to the customer emails I used to prepare it.

And maintaining this record has to save the owner work. If every minor edit needs a committee, people will go back to making decisions in messages. The review should follow the consequence: fixing a typo and changing what we promise a customer deserve different treatment.

I don't expect software to make a company agree. We will still argue about pricing. Someone will still make a bad call, and someone else will still have to challenge it.

But the next time two rooms reach different answers, I want us to find out while they're still proposals. Last time, we found out through broken billing. Giving everyone an agent is only useful if we get better at catching that disagreement before it ships.