On a calendar, every meeting looks the same - a title, a block of time, a few names. What each one leaves behind is completely different, and that's the thing building Earmark taught us that we didn't fully appreciate at the start: a generic summary is rarely enough. It's easy to assume every meeting wants the same treatment afterward. A recap, a few action items, a list of decisions, maybe a transcript for reference. Useful, but flat - because different conversations create different kinds of work.

A roadmap discussion and a bug triage don't need the same output. A customer call and a launch-planning session don't either. Walk through it and the divergence is obvious. After a roadmap meeting, the team needs an update explaining what changed, why priorities shifted, and which tradeoffs were accepted. After a bug discussion, it needs a ticket with reproduction steps, severity, expected versus actual behavior, and an owner. After launch planning, a timeline with risks, dependencies, owners, and open questions. After a customer call, an insight brief with pain themes, buying signals, objections, and follow-ups. After a decision-heavy conversation, a log that preserves the rationale, not just the conclusion. After a product-engineering discussion, a handoff with scope, constraints, edge cases, and the technical questions still open. Those artifacts aren't interchangeable - they serve different audiences, answer different questions, and move different parts of the company.

A summary is one-size-fits-all. A workflow understands the job.

That's the whole product lesson. The summary was usually fine; it just didn't know what kind of meeting we'd had. The value was never summarization on its own - it's interpretation. What type of work did this conversation create? Who has to act on it? What format makes it usable? What context has to survive, and what can be safely dropped? A generic summary treats every meeting as a memory problem, when most teams don't just need to remember the conversation - they need to do something because of it. So the output has to match the job. A PM shouldn't have to reshape one recap into five formats by hand. An engineer shouldn't have to infer implementation detail from a broad summary. A leader shouldn't have to dig through notes to find the risk. A customer-facing teammate shouldn't have to rewrite an entire call into a follow-up.

None of that means AI decides everything. Humans still own the judgment - whether the roadmap change is right, whether the ticket is scoped correctly, whether the customer signal matters, whether the launch plan is realistic. What AI can do is get the artifact into the right shape faster, and as we keep building Earmark, that's looked more and more like the real line between a summary and a workflow. Teams don't want a generic account of what happened. They want the right output for the meeting they actually had - because the value was never capturing the conversation. It's turning it into the next useful form of work.