For a team, a sprint is usually two weeks of work. I worked in sprints at many companies. When I asked my class to press one if they agreed, they did: in two hours, one session can do the sprint job of ten people.
But a sprint does not end when the code is written. It ends with a retrospective, a meeting about the sprint itself. What went well. What did not work. What did we learn, and how do we avoid the mistake next time. If one session is one sprint, it needs its retrospective too.
Without session logs, I have no idea what happened. The agent is working in there, and I do not know what is going on. So when I launch my agent to write any code, the first thing it knows is that it must write a session log, and at the end of every session it does: what happened, what changed, what it learned. That is the paper trail. I have more than two thousand of those logs on my machine now.
Your company ran three hundred agent sessions last quarter, and every session wrote a log. Your lead wants to know which mistake happens most. You have one afternoon. What do you do with the logs?
Not read them. Three hundred logs with your own eyes, until your eyes are bleeding, is not a plan. You make another agent that reads them, in batches, a fresh session for each batch, so no single desk overflows. Go back over the last ten sessions, or the last three hundred. What went wrong most often? Which rule keeps getting broken? How do we harness the agent better next time? That is lesson mining. The logs are the agent's own account, and the reader is an agent too, so ask it to quote the log line behind every count, and check a few yourself. Then the top mistake becomes the next line in the rules file.