I'm a fan of using the llms.txt pattern of progressive disclosure for internal app documentation. Agents just produce more consistent code with these.

Two things I regularly use it for are documenting decision records, under app/docs/adr, and to manage AWS learnings (https://github.com/jbdamask/aws-learnings-library).

For example, in the case of ADRs, as the codebase grows bash tools aren't enough for the agent to get the big picture. If a new feature requires async processing, the agent can orient itself by checking the adr llms.txt, first, then designing according to project standards, e.g.

llms.txt - [0002 Distributed SQS+Lambda Worker Pipeline Over Single-Container Agent]: [Accepted] Rejected porting the local single-session agent pattern to AWS; Lambda time limits, the propose-review gate, and idle-cost requirements each independently require the distributed worker model.

0002-distributed-worker-pipeline-over-single-agent-lambda.md "Each ingest job is a message on an SQS queue. A Lambda pulls one message, runs the full normalize→file→propose pipeline, and writes the proposal to DynamoDB + S3. SQS provides at-least-once delivery and DLQ-after-N-receives for durability. Separate worker Lambdas handle merge, embed, maintenance, and research."

Before I started doing this, there would be design entropy for similar features where one agent would decide to throw everything in a single lambda, another would bake a container, and yet another would use SQS.

Do others use this pattern? Are there things people don't like about it?