Somebody to Argue With

Last July I published eleven principles about how software should work, and one of them promised people. "BeMo simulates a team of experts, so your small team can think big." Grant writer. Strategist. Comms pro. Coach. All built in.

A month later I wrote the longer version: simulate the experts and "even small teams can operate like large ones."

I have been going back through what I published while we are building BeMo, checking each claim against what building has actually taught us. This one I can check more closely than most, because for the past year my co-founder, Becky Kern, and I have been the smallest possible test of it: two people, a great deal of AI, and a product whose promise was that software could stand in for some of the colleagues we did not have.

The claim held, and I will spend the credit in one paragraph

The simulated expertise is real and useful, and I would not go back. We ship work in a week that a two-person company had no business shipping, and almost none of it begins with either of us staring at a blank page.

But that is not what changed the way we work. I had the mechanism upside down.

What the machine actually did

I can show it in one example.

On September 17, Becky took a ten-page internal strategy document we had written for an audience of two and gave it to a tool that turned the document into a conversation between two synthetic hosts. Then we listened to them talk about our own company.

The first thing that happened was useful. They played our thinking back to us in language we had not used. Our document was full of founders' shorthand, and the hosts turned some of it into plain words. One analogy described the systems a nonprofit already runs as the kitchen behind the waiter. We had been circling that idea for months without finding such a simple way to say it.

Another phrase sounded familiar for a different reason. I had written it myself a year earlier and then stopped using it. It took a machine reading our own work back to me to notice that the older language was better.

I do not know why an idea lands differently when it comes back in another voice, and I have stopped trying to explain it. I only know it happens often enough that I now build it into how I work.

The second thing was more interesting. The hosts started making connections we had not asked for.

Our internal document contained no pricing, but they said BeMo would cost around three thousand dollars a year. My first reaction was that they had made up a number. They had not. They had found our published pricing, assumed a five-person team, done the math and landed almost exactly on our team plan.

That was useful, not because the machine had uncovered a hidden truth, but because it kept going. It took what we gave it, looked one step farther and brought something back for us to consider. Sometimes the step lands between two things we had already written down. Sometimes it goes past where we stopped. Either way it gives us more to react to than we would have produced sitting alone with the original document.

None of it has to be right to be worth having. It arrives as a suggestion, and a suggestion that misses costs me the few seconds it takes to read it and move on. That is why I want more of them rather than better odds.

Then came the third thing, which is the same machine doing something that looks similar and is not.

Five statements in that conversation were wrong, and none of them was wildly wrong. That would have been easier. They were close enough to the truth to sound right.

Something we had described as a direction was described as already working. A competitor price we had marked unverified was stated as fact. A number we call reach was described as customers. A mechanism we had never documented was explained confidently.

The problem was not that the machine invented things. The problem was subtler. Something uncertain had become certain. Something we were considering had become something we had decided. Something that needed checking came back sounding finished.

And none of it arrived as a suggestion. A suggestion asks to be judged. These came back as statements, which is a different act, and being wrong about a statement does not cost anyone a few seconds.

The only thing standing between those statements and one of our slide decks, sales conversations or strategy decisions was that Becky and I knew the material well enough to catch them.

The part that does not transfer

That is the part I got wrong in 2025.

I wrote that the software brings the expertise and the person brings the work. After a year of building this way, I think it is closer to the other way around.

The software brings range. It gives us more ways to say something, more connections to consider and more possibilities than we would reach on our own. We bring the judgment that makes any of it usable, and judgment turns out to be connected to something a system cannot have: a stake in the outcome.

When Becky tells me an argument does not hold, the sentence carries weight because she is on the hook for what happens next. If she is wrong, it matters to her. If I am wrong, it matters to me.

A model can make exactly the same argument, sometimes better, and lose nothing if the answer turns out to be wrong. I can feel the difference in how hard I think about those two answers.

That is not a criticism of the model. It is a distinction I had missed. The value of a colleague was never just that they could do the task. It is that they carry some of the weight of being right.

What changed in BeMo

That realization changed how we think about the product.

We are not going to give people a cast of pretend colleagues with names, personalities and titles and ask them to suspend disbelief. BeMo is not a grant writer, a strategist or a communications director.

It reads what your organization knows and what the funders around you have actually done. It drafts, questions, compares and connects. It can give a small team far more to work with than it would produce alone. What it does not do is become the person who has to live with the decision.

That is why the rule underneath BeMo is a simple one. BeMo proposes and a person confirms. When BeMo works from what an organization knows, the person using it should be able to see what it used, and when something is uncertain it should stay uncertain rather than come back sounding like fact.

Notice the word should. I wrote it as can the first time, and can is a claim about the build I would not sign today. I caught it on the reread, four hundred words after explaining that this is exactly the failure. The certainty creeps in for me too.

Becky wrote about that rule on Monday from the user's side, which is the side that matters. The builder's footnote is that writing the rule down took an afternoon, and making the behavior dependable every single time is most of what we actually do. When I published those principles last year I would have called that part friction and designed it away.

The delta, in one sentence. I promised a simulated team of experts so a small team could think big, and building with the smallest possible team taught me that the machine gives you more to think with while the person supplies the judgment, because judgment comes partly from having something at stake.

Then: a team of experts, built in. Now: a machine that gives us more to think with, and two people who have to live with what we choose.