Field guide · AI systems · June 2026
From meeting transcript to a follow-up you can send.
The value of a call is in the follow-up, and the follow-up is the step that gets dropped. Recording and transcription are close to solved: a transcript lands in a folder minutes after the call ends. Then, most of the time, nothing reads it.
Posted June 26, 2026
The action items stay buried in prose. The follow-up gets written from memory a day late, or not at all. The next call starts without the context of the last one, because pulling that context back out of a transcript takes longer than most people will spend on it between meetings.
The shape.
A light layer sitting on top of whatever already captures the transcript. It reads the transcript and produces three things: a structured record of who was on the call and what is still open, a follow-up draft in your voice ready to review, and a tracked task for anything that was actually committed to on the call. A person approves the draft before it goes anywhere. The layer does the retrieval and the first pass. The human keeps the judgment about what mattered and what gets sent.
Why human-in-the-loop, specifically here.
Meeting notes are most useful when a person decides what mattered, not when a generic summary flattens the call into bullet points that miss the one thing that actually needs following up on. The three outputs are drafts, not an auto-send. The point of the layer is to remove the retrieval cost and the first-draft cost, not to remove the person from the decision to send something under their name.
The honest status.
Rarefied Earth treats this as a candidate, not a shipped capability. The transcript-capture layer it would sit on top of is still inside its own dogfood window: a defined set of gates (weeks of real usage, consent discipline holding, the workflow proving out for both meeting notes and voice-memo capture) that have to clear before anything gets built on top of it. The rule the firm holds is not to build the downstream step until the layer underneath it has earned its keep.
The manual version is real and runs today. After a call, read the transcript, pull the action items, draft the follow-up by hand. That is not a placeholder for the automated version; it is the actual current practice, and it is the thing being watched to decide whether automating it is worth doing. If the same three-output shape keeps holding across enough calls, it becomes a candidate to make repeatable. If it does not hold, that is worth knowing before anything gets built, not after.
What a reader can do without waiting for the automated version.
After your next call, produce the three outputs by hand, once: a short structured record, a follow-up draft, and a note of anything you actually committed to. Do it again after the call after that. If the shape holds and saves real time across a handful of calls, it is worth making repeatable. If it does not, you learned that cheaply, which is the whole point of testing the manual version before automating it.
Related work.
This sits next to the command surface piece on the same theme: an agent doing real work only earns trust once the boring, high-frequency step around it, routing a request or turning a transcript into a follow-up, is reliable enough that a person stops having to do it by hand every time.