| 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? |
But yes, the general pattern is very useful if you keep it minimal. There are correctness issues over time, from drift, to be aware of.