You write a process, not a script
Objectives, what they depend on, and what evidence counts as done. An item only becomes available when its dependencies are complete.
Open source@latch/coreMIT
A conversation that still knows what it is doing.
Most chat agents treat the conversation as memory and hope it stays coherent. Latch runs a checklist of real objectives underneath the chat. The model can suggest updates. Latch is the only thing allowed to write them down. It still feels like a conversation. You can just see what is established, what is done, and what should come next.
Free-form agents wander. Forms are rigid.
An unstructured agent re-asks questions, invents memory, and leaves later answers stale when something is corrected. A form wizard avoids that by being inflexible. Latch sits between those extremes: the conversation can move around, but progress is a real process, not a vibe.
Read the repoFree-form agent
The chat log is the state
- The model overwrites whatever it likes
- Corrections often orphan later answers
- Next topic is a soft hint, at best
Form wizard
Fixed screens, in a fixed order
- The user only fills fields
- Rarely adaptive when someone jumps ahead
- No real dialogue
Latch
The process is the state
- The model proposes; Latch commits
- A correction re-checks what depended on it
- The graph decides what counts as done
You write a process. Latch runs it under the chat.
A process is a set of objectives with dependencies and completion rules: “the problem is established when the user has stated it.” Latch compiles that once, then keeps one instance per conversation.
A process, not a script
First
The problem
Depends on problem
Who is affected
Depends on both
The outcome
Opens next
Constraints
Each item has a completion rule. Nothing downstream is “done” until the facts it needs are in.
One turn
- 01You speak
- 02The model replies, and proposes
- 03Latch writes it down
- 04The next objective opens
You only see the reply. The proposal never lands in the bubble.
How it actually works
The model proposes. Latch commits.
Each turn the model answers in plain language and suggests updates. Latch checks those suggestions, then writes state. Invalid suggestions fail cleanly, with no hidden second call to “fix” bad output.
Memory is facts, not the chat log
When someone says the problem is that users lose their place, Latch records that as a fact with a source. The transcript is kept for provenance. It is not dumped back into the model every turn.
If a fact changes, dependents are re-checked
Say “actually the problem is different.” Latch updates the fact and re-opens anything that was built on the old one, so the process does not keep claiming it is finished.
A short walkthrough
Imagine a product-discovery conversation. The first objective is to establish the problem.
- 01
You name the problem
“Users lose their place during long structured chats.” Latch records that as a fact, not just another line in the transcript.
- 02
The next objective opens
Who is affected becomes available. Latch can point the conversation there without trapping anyone in a wizard.
- 03
You only see the reply
The bookkeeping stays out of the bubble. Hosts show the prose. Control belongs in logs, not in the chat.
- 04
A correction does not rot the rest
If you later change the problem, Latch updates the fact and re-opens anything that depended on the old one. That cascade is the point.
What it is for
Use it when the conversation has a goal that can be broken into objectives, and you need durable, inspectable state, not just a good last reply.
Selected uses
Discovery briefs
Problem, users, outcome, constraints, success measures, gathered in conversation, stored as a brief.
Onboarding
A new account or workspace that still needs a handful of real facts before it is ready.
Intake
Support, sales, or research conversations that have to leave a complete record, not a transcript to re-read.
Triage
Enough structure to decide what kind of case this is, without forcing a form on day one.
Compliance checks
Required facts, accepted sources, and a trail of what was established when.
That a chat log is a workable substitute for state.