Composer Agent UX¶
Listen's name for the onboarding agent that co-edits the discussion guide — the document listing the questions the interviewer agent will ask. Not pure chat, not pure document editor; a third shape: shared artifact with an explicit edit log both parties can read.
The three failure modes Florian ruled out¶
- Pure LLM rewrite. "You give it one sentence, you expect it to write like a whole page out of it. That's probably not going to work." Fine for short docs; breaks for realistic guides.
- Pure chat. User has to describe changes in prose ("please delete question three") which is cumbersome vs just deleting it.
- String-replace editing. Works narrowly but breaks when changes stack — "ID number two is now ID number three and then you insert a new element here."
What Listen landed on¶
- A shared edit history — every change (human or AI) is formatted as a typed edit operation.
- The user can edit the document directly OR chat with the agent; both write to the same history.
- The agent consumes the edit log as part of its context, so it doesn't undo a change the human just made.
- Undo/redo works across both channels; the user can compare versions.
Florian:
"You're both working on the same edit history… it kind of knows about the changes you made. So it doesn't undo the changes immediately."
Why it matters beyond Listen¶
This is a template for any agent that edits a structured artifact (document, config, code file) alongside a human. The naive choices — full rewrite, prompt-to-edit, or string-replace — all break in predictable ways. The typed edit log as shared context is the generalizable part.
Related¶
- contextual-prompt-engineering — the edit log IS part of the context
- agent-as-junior-engineer — same tension: human stays in the loop, agent doesn't stomp
- agent-taste — Peter Steinberger's framing; Composer's edit log is what "taste" looks like at UX level