Nobody should find out they own a project because an AI filled in a blank.

Picture a planning meeting. Someone says, "Maybe Alex could look at the rollout next week?" The conversation moves on before Alex says anything.

An hour later, a tidy recap shows up with a neat action item: Alex will deliver the rollout plan by Friday.

"Maybe" became "will." "Next week" became "Friday." Now Alex gets to choose between quietly taking on a project nobody assigned and hitting reply-all to explain that the meeting never decided that. Neither is a great use of anyone's afternoon.

And the recap doesn't stay a recap. It becomes a ticket, a line in a stakeholder update, instructions for an agent. Every step makes the assumption look more official and moves it further from the conversation where it was only a maybe.

So when I look at an AI product that says it respects human judgment, I ask one question: what does it do with the things people haven't decided yet?

At Earmark, part of our answer is one word: Unassigned.

When our default meeting summary includes an action item that nobody took ownership of, it's designed to say so instead of guessing. It records the deadlines people actually stated.

That blank is information. The work exists, and the team still needs to decide who's doing it. A plausible name in that field would hide the very next thing that needs to happen.

Leading product and engineering teams, I learned that a big part of the job is knowing where agreement actually exists. People walk out of the same meeting with different ideas about what was proposed, what was approved, and what still depended on someone checking an assumption. The details that matter are usually small:

• A customer request deserves investigation, but nobody committed it to the roadmap.

• An engineering estimate only holds if the team gets access to a system.

• Two people prefer different approaches, and the team deliberately put off the decision until there's more evidence.

"That blank is information."

Drop any of those qualifiers and the output looks cleaner. It also tells the next person something that isn't true.

The standard I want us building toward is uncertainty that's specific enough to act on. Name the missing owner. Keep the dependency attached to the estimate. Show both approaches when the team hasn't picked one.

That doesn't mean the AI can't have opinions. Suggesting an owner or a next step can be helpful, as long as it's clearly a suggestion and a person decides whether to take it. What the team agreed and what the software recommends should never look the same on the page.

"Drop any of those qualifiers and the output looks cleaner. It also tells the next person something that isn't true."

That distinction has to survive the handoff, too. The person who picks up the ticket may never read the transcript. They need to know which parts are settled and which still need a conversation.

This matters even more when the next reader is an agent. Hand a coding agent a speculative requirement written as a firm one, and it will build it, confidently, in the wrong direction. Keep the "maybe" in, and the person directing the agent gets a chance to resolve it first.

"What the team agreed and what the software recommends should never look the same on the page."

There's a cost to this. A summary with every field filled in looks better. In a demo, a blank owner can look like the AI missed something. I'd still rather show you the blank.

We talk a lot about turning conversations into work. That promise has to include being precise about how far the conversation actually got. Sometimes the most useful output is a ticket that's ready to pick up. Sometimes it's a clear note about the decision you still need to make before that ticket should exist. Both move a team forward. Only one of them looks good in a screenshot.

If nobody agreed to it in the meeting, a polished document shouldn't make it official.