The Work Starts Before The Software Sees It
Most business work starts before software can see it.
It starts in a meeting, a call, an exception someone explains out loud, a follow-up everyone assumes someone else wrote down, or a customer detail that only makes sense because one employee remembers the history.
The part I underestimated is how much operational judgment lives in that pre-software layer.
By the time the work shows up in a system, it has usually been cleaned up. A task exists. A note was entered. A status changed. A field got updated. But the judgment that produced those objects happened earlier, in a messier and less structured environment.
That is why I think "AI meeting summaries" are the wrong frame.
The more interesting product is not a better recap. It is a capture layer that turns conversation into operating state.
There is a big difference between those two things.
A summary is something a person reads. Operating state is something a business can act on. It has structure, ownership, permissions, confidence, review status, and a path into the workflow.
A useful system does not just say, "Here is what happened in the meeting." It can produce transcript segments, speaker labels, decisions, open questions, entities, follow-ups, and proposed updates. It can distinguish what was said from what was inferred. It can preserve evidence. It can ask for approval before mutating anything downstream.
That is where human judgment starts becoming a software primitive.
The interesting primitive is not the transcript by itself. It is the reviewed unit of work that comes out of the transcript: this person committed to this next step, this customer detail matters, this exception should change the process, this recommendation is low confidence and needs escalation. Once the system can represent those units, it can participate in operations instead of merely describing them.
This matters most in the kinds of businesses that have historically been underserved by software. Their operations are not simple; they are just under-modeled. A CRM may know the customer exists. A project tool may know a task exists. But the actual operating logic often lives in meetings, inboxes, spreadsheets, and employee memory.
AI changes the economics of modeling that work.
Instead of forcing the business to document every process upfront, the system can observe a workflow, structure the useful parts, and route them through review. Over time, repeated judgments become more durable: common exceptions, recurring handoffs, approval patterns, risk signals, and next-step recommendations.
That does not mean the model gets to act freely. In most real businesses, the important product work is deciding what the system is allowed to create, who can approve it, what evidence travels with it, and what happens when confidence is low. Autonomy is downstream of those design choices. That is the less flashy, more durable work.
This is where the operating-model shift starts to show up.
The AI system is not valuable because it chats about the business. It is valuable because it helps create and maintain the state the business runs on. That requires context, permissions, feedback, audit trails, and escalation paths. It requires knowing when the system is drafting, when it is recommending, and when a human has to approve the next step.
I think we are still overestimating autonomy and underestimating workflow design.
The companies that win here will not be "chatbots for meetings." They will own the boundary where undocumented work becomes trusted action.
The useful question is not "Can the model summarize this conversation?"
The useful question is "Can the system responsibly turn this conversation into state the business can use?"