A requirement can sound perfectly clear until somebody tries to write it down.

"We need bulk editing" is easy to agree on. Everyone nods, and the meeting moves on.

Then someone sits down to write the ticket. Which fields can be edited in bulk? What happens if you select twenty records and don't have permission to change three of them? If part of the update fails, does the rest go through?

Those are good questions. They're also questions for people who have just left the room.

So the answers trickle in: a Slack thread, a "quick question" that interrupts an engineer, and sometimes a 15-minute sync to clarify a 45-minute meeting. A conversation that felt finished turns out to have been a first draft.

One belief behind Earmark is that work should move forward during the conversation, while the people who understand it are still there.

"A conversation that felt finished turns out to have been a first draft."

One way that shows up: you can turn on live updates for a task, and its draft refreshes as the discussion develops. A spec, a set of tickets, or a customer follow-up can take shape while people are still working through the details.

The feature isn't the interesting part. What it changes about the meeting is.

Run the bulk-editing discussion again, this time with a rough ticket on screen. Halfway through, someone notices the draft assumes every selected record can be changed. An engineer raises permissions. The designer describes what the person using the product should see when only some changes go through: update what you can, then show what was skipped and why.

Now the team has a concrete problem to work through together, instead of an open question waiting in someone's inbox. The draft picks up those decisions as they're made. Before everyone moves on, someone reads the acceptance criteria and asks, "Is this what we agreed?"

That's the part I care about most. A draft can improve the conversation that produces it.

Agreement is easy in the abstract. It gets harder, in a useful way, when it has to survive a description, a set of acceptance criteria, or a proposed next step. A draft gives people something specific to push on, and you find the gaps while it's still easy to ask.

"A draft can improve the conversation that produces it."

This also gives us a tougher standard than counting outputs. A 30-minute meeting that produces a spec, five tickets, two updates, and a follow-up email sounds productive. It can also mean someone just inherited an hour of editing. Volume tells you very little about how much useful work actually moved.

What I want to know is simpler. Can someone use the result? Does it reflect the decisions accurately? Can the next person understand what to do without reconstructing the meeting?

That puts some obligations on us. Drafts should be short enough to review in the moment. Open questions should stay visible instead of getting smoothed over. Correcting something the software misunderstood should be easy. Every output is something a person may have to read, and we owe them a good reason to spend that attention.

Live assistance also has to respect the meeting. Nobody should spend the whole conversation prompting and supervising an AI. If you're babysitting a bot, you're not really in the meeting. The draft should be useful whenever you choose to glance at it, so most of your attention stays on the people and the decisions in front of you.

And sometimes moving work forward means finding the next question. Some discussions need more evidence before anyone should commit. A good draft makes that dependency obvious, so the next meeting starts from what's known instead of from scratch.

"If you're babysitting a bot, you're not really in the meeting."

It would be easier to market how much Earmark generates. A screenshot of fifteen artifacts looks impressive. But when we say Earmark turns conversations into work, the experience I want us to earn is quieter: people leave with something they've had a chance to understand, question, and improve together.

The first review should happen while the people who know the answers are still there.