The Easy Half

Two conferences, one month, the same move. On September 15 Salesforce announced AIforce at Dreamforce, "a live interface layer that brings the full power of Salesforce to wherever people and agents work." The trade headline was "AI replaces the UI." Salesforce's own sentence was plainer: "people don't have to come to Salesforce to get work done. Salesforce comes to them." The next morning HubSpot opened UNBOUND in Boston, having renamed a fifteen-year-old conference to mark the same shift. HubSpot had shipped the move in April, five months earlier, when its hosted MCP server went "generally available to all HubSpot accounts," reading and writing the CRM "through natural conversation."

I have been going back through what I published while we are building BeMo, checking each claim against what building taught. This is the first edition of Build Notes to arrive rather than to be found; there is one a week, on Wednesdays. This is the week the claim I was most sure of came true in public. This edition is about why being right about it was worth less than I thought.

What I claimed

Last October I wrote: "But the map has become a maze. Too much time goes into teaching the software instead of doing the work." The fix was conversation. "You simply say what you want, and the system responds." My example was a single request, "Find me 10 funders of child literacy," and the post closed on the line I was proudest of: "Goodbye menus. Hello conversations."

The claim held, and I will spend the credit in one paragraph. Parker Harris, who built the Salesforce interface, is on record asking why anyone should ever log into Salesforce again and answering, "Maybe you never will." Patrick Stokes, who runs Salesforce's applications, said it plainer still before Dreamforce: "The UI is not actually our product." The interface changed. I said it would.

Why it was the easy half

I have used that phrase before. In July, checking what I had written about memory, I ended on this: a system that remembers everything has done the easy half; the hard half is being a participant in the work instead of a destination beside it. The interface is the same kind of easy half, and it turns out to have the same hard half.

Three reasons, in increasing order of what they cost us.

First, it was never a bet on anything we built. It was a bet that the models would get good enough to understand a plain sentence, and that every vendor with a database and an API would then put a conversation in front of it. That bet required no product, and everyone with a system of record has now collected on it. Being right alongside the whole industry separates you from no one.

Second, look at my example. Ten funders of child literacy. One system, one question, one answer, and the answer is the whole job. I picked the case where the door is the work. A nonprofit's week is not made of that case. It is the grant, the program it paid for, and the story you tell about both, and the report that needs all three to agree. My post never asked what happens when they do not.

Third, and the most expensive: the post never asked what happened to the answer afterward. Its idea of memory was the smallest one available. "Integrated Memory means you don't configure settings; the system simply remembers." Settings. I had the word memory in the post and I meant preferences.

Becky, my co-founder, and I work in the world I predicted. I have not opened Trello in a week. An AI assistant moves the cards for us through Trello's API, and it works our inbox, our shared drive and our software deployments the same way. It is what both vendors just sold, arrived early, and I can tell you what it fixed and what it did not. It fixed the clicking. It did not touch the deciding, and it did not touch the keeping. What makes it worth anything is that everything the assistant reads and writes lands in one written record that the next conversation starts from. Take the record away and the doors are faster ways to collect four answers that do not agree.

The doors opened. The synthesis did not.

Picture the world both companies described. A nonprofit's staff can ask the CRM from Slack, the books from Slack, the donor database from Claude. Every system of record has published its door. What has improved?

The asking. Nothing else. A person still asks each system separately, reads four answers, notices where they conflict, reconciles them by hand and decides what is true. Then that reconciliation, the only step with any judgment in it, sits in a direct message and dies there. It never becomes something the organization knows.

Becky counted this on Monday from the other direction: twelve steps to get one document to one yes between two people who agree on almost everything, and two of the steps were the work. Doors that open faster do not shorten that loop. They add sources to it.

To be fair to both vendors, HubSpot has seen part of this, and said it best. Duncan Lennox, its chief product and technology officer, put it in one line in April: "if data is what happened, context is why." Every platform vendor is selling that word this season, and HubSpot is the only one that sells to organizations with no IT department, which is every nonprofit we build for. So its own sentence raises the right question: whose why, and where does it live? For a company whose work lives in the CRM, the why is in the CRM, and HubSpot is building a place for it: "captured systematically so knowledge doesn't disappear when someone leaves." A nonprofit's why is in the board minutes, in the program that changed after a site visit, in the reason the plan moved in March. None of that touches a CRM, and no CRM vendor has a reason to hold it.

So a world of open doors leaves the person as the integration layer. That is the problem we started this company to work on, arriving through a new door with more sources feeding it. Every vendor is making its own system easier to reach. Nobody is doing the reconciling, and nobody is keeping the result.

What changed in BeMo

The conversation stopped being the product. It is the door, and still the right door, but the work moved to the record behind it. You stop going somewhere to do the work.

Every tool a nonprofit runs was built for one job and holds one true thing about the organization. None of them were there for all of it. BeMo is built to be the thing that was present when the grant was won, when the money landed, when the program ran and when the story went out, so what it knows survives a tool or a person leaving. What it holds is what the organization decided and why, with where it came from attached. When the assistant answers, it answers from that record and says when it does not know. The reconciling is still a person's judgment; we are not trying to automate that away, and would not trust a system that claimed to. What changed is where the judgment lands: in the record the organization keeps, instead of in a message thread.

The doors are welcome. We were never going to build them, and every one that opens is one more answer that needs a home. BeMo sits above the tools you already run, and they keep their jobs. What is in front of us, and not behind us, is reaching the systems where the rest of an organization's answers live.

The delta, in three sentences. I wrote that the work would move out of menus and into conversation. Building taught me the work was never in the interface. It moved to the reconciling, and the reconciling dies in a direct message unless the organization has somewhere to keep it.

Then: goodbye menus, hello conversations. Now: the conversations arrived, from every vendor at once, and the work is what happens to the answers afterward.