At slide 7, being later than 4:55 means cut the cold-read anecdote on slide 10. At slide 10, being later than 8:30 means give the short version of each habit and move to the close by 10:45. Update the clocks after a standing rehearsal. These are pacing targets, not a claim that the talk has been rehearsed.
Short version of slide 10: paste the exact sentence and say what is wrong; check a summary of the goal and decisions, then restart; ask a separate chat what a new colleague would miss.
Good morning. These are documents from my own project. An AI wrote most of them. I have never read the changelog from start to finish.
I am not proud of that.
Hands up if an AI has written something for you that you did not really read.
Writing got cheap. Reading still takes time. And when I am responsible for a decision in a document, I do need to read it.
Here is a report from a generalized, anonymized pilot example. An agent wrote it from a brief and notes. The summary compresses the result, the setup cost, and a problem customers saw into one long paragraph. I cannot just accept it because it sounds complete. I need to work through what it says.
This is a short excerpt from the paragraph I selected. I could say in chat, "the summary is too long." But which sentence should it change? If I paste the exact passage and say, "Say this in one sentence a customer would understand," that is clear. It is also a lot of copying back and forth when a document needs several notes.
That is the gap: the AI has the document, but it does not know which words I mean when I say "that bit." Context is the material the AI can work with right now: my instructions, the document, and our conversation. Managing it means making the needed information clear and deciding when to carry a checked summary into a fresh chat. More text alone does not remove ambiguity.
A vague correction makes it guess. A precise one gives it a place and a reason. And if the whole conversation has gone off track, I need a fresh start, not one more correction. Those are two different fixes.
I built glosa for the first problem. In Polish, a glosa is an explanatory note in a text, often between its lines. I borrowed the name because each note belongs to particular words. The agent writes a file; glosa opens it as a page in my browser, on my laptop. I read the document there and leave notes beside the words they refer to.
This is a prepared run with that generalized, anonymized report. Watch the two directions.
I highlight the summary and write my note in the margin. The agent receives my note with the passage attached and revises it. Then I ask it to go through the report's open questions. I have told the agent to bring each decision back to me. It puts its question beside the passage and waits.
I choose an option there, and it writes that decision into the report.
Lucas asked us to explain how we built our projects. Here is the actual shape of this one. glosa is written in TypeScript and runs locally. One part serves the document page you just saw. Another keeps notes and versions. A connection to Claude Code or Codex delivers a note to the agent, or brings the agent's question back to the page.
The awkward problem was keeping a note attached after a rewrite. A line number is no help when the lines move. glosa keeps the quoted words and some surrounding text. If it cannot find a safe match later, it marks the note as unplaced. It does not quietly pin it to a different sentence.
I started in July, alongside normal work. AI wrote a lot of the code, but I still had to decide what the tool should do and what counted as done.
For each change I start with a GitHub issue: the problem, the boundary, and how we will know it is fixed. Claude builds it. Tests run. Codex reviews the diff and test results in a fresh session, without relying on Claude's explanation. If the review finds a problem, the same builder fixes it. That matters because it keeps the work and its constraints in view. Risky decisions come back to me. A passing change becomes a pull request.
The surprising part is what happens after a failure. In one run, the pipeline said the code was broken. The check itself matched the wrong test name; that test could never pass. We fixed it and added a rule: important checks must prove they can fail. Remove what they protect, watch them go red, then restore it.
The pipeline keeps reusable lessons with a trigger, cause, prevention and evidence. When a new issue starts, it brings in only lessons relevant to that work. If the defect is in the pipeline's own tooling, a small fix has to reproduce the problem, pass tests and get a fresh review before a new version is used. Risky changes come back to me. This is learning in the engineering sense: the next run has better instructions or better tools. The model itself has not been retrained.
glosa follows the same honesty rule. If a note cannot be matched safely after a rewrite, it stays unplaced for a person to resolve.
You do not need glosa for these. They work in an ordinary AI chat.
One: point, then explain. Paste the exact sentence and say what is wrong with it. "Too long; say it in one sentence a customer would understand" is better than "rephrase this." You have supplied both the place and the direction.
Two: when the whole chat goes wrong, restart deliberately. Ask for a summary of the goal, constraints, decisions, and what is still open. Check it yourself. Then use it to start a new chat. A study of multi-turn conversations recommends consolidating what you told the model before retrying; Lost & Found links the study.
Three: get a cold read before you send AI work to a colleague. Give the finished text to a separate chat with prior memory or personalisation off where you can. Ask: "What would be unclear to a colleague who never saw our conversation?" I tried this on my notes for this talk. It found a next step with no named owner. I knew who should do it. The page did not say.
I made Lost & Found for this talk. This code goes straight to its public GitHub repo. It has eight Claude skills, each with a prompt you can copy into any AI chat. If an answer is too dense, try clarify. If a chat goes in circles, use hand-over. Before you send a document to a colleague, use cold-read. Pick one this week.
If you build with Claude Code or Codex, I will have glosa at a station in slots three and four. It is early and open source; come and try it on a document you need to review.
Thank you.
Cut the opening show of hands first (about 15 seconds), then the cold-read anecdote in Part 4 (about 20 seconds). Keep the demo, how-I-built-it section, and three practical habits. The target is a calm finish, not faster speech.
Rehearse with the final recording. The local MP4 is a 58 second cut from take 22, recorded after PR #346 landed. It has large captions and wider framing that keeps each annotation box and its controls in view. It stops after one decision is written. Keep `glosa-demo.mp4` beside `talk-slides.html` when moving the deck. Test playback on the actual display before slot 1.
Keep slides 2 and 3 aligned with take 22. They now use the same report and actual note: "Too long. Say it in one sentence a customer would understand." If you change the recording, update both slides too.
Check the Lost & Found QR with a phone. It should open the public GitHub repo without a sign-in prompt. The local HTML handout is separate from this code.
Q&A monitor answer: take 22 delivered the note and applied it through the merged source build on 23 September. The installed published plugin is still alpha.30 because no newer package has been released; the isolated demo used the merged source through `GLOSA_BIN`.
Rehearse standing with the deck, a timer, and the actual display. Test video playback and the large QR before slot 1. Learn the first and last thirty seconds; speak the middle naturally.
Tell the two directions as a short story: I mark the exact sentence and the agent receives my note; later it puts a question beside an open decision and waits for me. Then explain the build and review loop without the diagram. Give the Lost & Found repo address verbally or at the station.
The report in the recording is a prepared, generalized, anonymized example. The agent was instructed to bring open decisions back to a person. Do not call the pilot real or imply that the agent discovered the rule itself.
glosa helps locate feedback and hold a decision for review. It does not verify the report's facts, guarantee a narrow rewrite, or make someone read.
The multi-turn study supports consolidating requirements and trying a fresh conversation when one derails. It did not test anchored feedback or glosa: https://arxiv.org/html/2505.06120
A separate chat is a better cold read, but "temporary" does not always mean free of memory or preferences. ChatGPT needs unpersonalized Temporary Chat; Claude incognito avoids chat history and memory but still uses profile preferences. Do not describe either as completely context-free: https://help.openai.com/en/articles/8914046-temporary-chat-faq/ https://support.claude.com/en/articles/12260368-use-incognito-chats
If asked about the pipeline: the builder is Claude, the reviewer is Codex, and the reviewer starts fresh without relying on the builder's summary. Tests and review can find problems, but human decisions remain necessary.