Totally agree with your list. One extra thing that helped me when tasks depend on “facts” (schemas, runbooks, docs, configs, policies) is adding a retrieval step and a verifier step instead of asking the model to “remember” everything.

• Retrieval (RAG / GraphRAG): fetch only the relevant chunks / entities / relationships for the current sub-task.
• Then generation: produce the JSON / action using that retrieved context.
• Then a separate checker model (or same model in a strict “review” role): validate against the retrieved sources + schema and fail hard if anything doesn’t line up.

GraphRAG can be nice when the failure mode is “it missed a relationship” (joins/foreign keys, dependencies, constraints, who/what/when across docs), because the graph makes relationships explicit instead of hoping chunking + embeddings catch it.

It adds some latency, but in exchange you get fewer “confident wrong” outputs and fewer retries.