#Learn from past work

Reviewers leave the same comment on agent pull requests week after week. An agent hits the same missing tool in run after run. Each time, someone fixes the symptom, and nobody has the time to fix the cause. Learn from past work reads that history on a schedule, records each recurring problem once with its evidence, and can hand the ones worth fixing to your factory as tickets.

#Before you start

• A Tessl project for a whole GitHub repository, not a subdirectory, with the GitHub integration able to read the repository.
• Edit access to the project's workspace.
• For Tune Review Lenses, the repository selected in your organization's Tessl Code Review app installation. The loop reads only reviews by the Tessl Review App, not reviews from the tessl code review CLI or the GitHub Action. Without the app, its runs find nothing to read.
• An organization admin only to create an environment: the one Learn from agent runs needs the first time it's turned on in a project, or a new one for Turn findings into tickets. Learn from review feedback and Tune Review Lenses use the project's default environment and need no admin. Later setups reuse the Learn from agent runs environment, and Turn findings into tickets can use an existing environment that has the write access it needs.
• For Turn findings into tickets, a loop that turns tickets into pull requests, such as Ticket to PR. Without one, triage can resolve and ignore findings but can't hand them to the factory.

#The 4 loops

• Learn from review feedback: reads pull request review threads and the commits that answered them, and records mistakes reviewers keep correcting. Each finding recommends agent context (an AGENTS.md line, a rule, or a skill), a verifier, or both. It records at most 3 findings a run.
• Learn from agent runs: reads the transcripts of recent runs that opened pull requests, with the review feedback those pull requests got. It records problems that recur across runs, such as dead ends, repeated failed commands, missing tools or access, and flaky checks.
• Tune Review Lenses: reads how Tessl Code Review did on recent pull requests: the findings authors addressed, declined, or refuted, and the bugs that got past it. Each finding proposes one change to a lens. If the repository still uses the default lenses, its first finding proposes copying them into the repository so you can tune them.
• Turn findings into tickets: checks each open finding against the current code and gives it one outcome. It changes no code itself.

Each loop is useful alone. Turn on the ones you want, and add the others later.

#What each loop can write

• The 3 learning loops write findings for this project and nothing else. They push nothing, open no pull requests, and post no comments.
• Learn from review feedback and Tune Review Lenses run with the project's default environment, which reads the repository.
• Learn from agent runs runs with an environment Tessl creates for it, with GitHub read access and permission to read other runs' logs. Each transcript it reads is recorded in the organization's audit log.
• Turn findings into tickets writes tickets, finding updates, and links to them. It runs with an environment you choose, which needs GitHub write access, or Linear write access with Linear connected. Pick the environment your ticket-to-pull-request loop takes tickets with. Creating a new environment for it makes an organization environment, which needs an organization admin. See Environments for access levels.

#Turn on a learning loop

This walkthrough turns on Learn from review feedback. The other loops work the same way.

1. In the web app, open the project, then Loops, then Add loop, and choose Learn from past work.
2. Under Learn from review feedback, pick a Cadence:
   • Daily at 9:00 AM UTC, the default
   • Weekly on Monday at 9:00 AM UTC
   • Manual: only when you trigger it, which sets the loop up paused
3. Optionally, add Extra instructions, such as the areas to focus on. They can narrow what a run looks at, not widen what it may change.
4. Choose Turn on Learn from review feedback.

The section now links to the loop. With Daily or Weekly, it reads On: runs followed by the schedule. With Manual, it reads Paused: runs only when you trigger it. Learn from review feedback, Learn from agent runs, and Tune Review Lenses run on Mondays when weekly. Turn findings into tickets runs on Tuesdays, so it sees the findings from the day before.

To see a result now instead of waiting for the schedule, open the loop and choose Trigger now, or run:

tessl schedule list --project-id <project id>
tessl schedule trigger <loop id>

Every run uses credits, and weekly suits most repositories. See pricing for current details.

You can also turn the loops on from your coding agent. The tessl-labs/factory-setup plugin's factory-setup skill suggests Learn from past work once your factory is live.

#Read a finding

When the run finishes, open the project's Findings tab. The organization's Findings page lists findings across every project you can see. A finding shows:

• Problem: what keeps going wrong, and why it matters.
• Impact and Expected outcome: what changes once it's fixed.
• Observations: each time a loop saw the problem, with links to the pull requests and runs behind it.
• Suggested fix: the change the loop recommends.
• Status, Found by (the loop that recorded it), Tags, and Linked work (the tickets and pull requests linked to it).

A finding is Open until someone acts on it, In progress once a ticket or pull request is linked, and then Resolved or Ignored.

From the CLI:

tessl finding list --project <project id> --state open
tessl finding view <finding id>

A run that records nothing isn't a failure. The loops prefer no finding to a weak one, and the run's result says what it examined.

#Triage findings into tickets

You can triage by hand, or let Turn findings into tickets do it on a schedule.

#By hand

On a finding's page, choose one:

• Mark as resolved when the code already does what the finding asks.

• Ignore when it doesn't fit the project, or the evidence doesn't hold up.

• File a ticket for it in your tracker, then link the ticket so the finding moves to In progress:

  tessl finding link add <finding id> --type ticket --url <ticket url>

Check Linked work before you file. A finding that already has a ticket doesn't need another.

#With Turn findings into tickets

Turn it on from the same Learn from past work page. Pick its Cadence and its Environment, then choose Turn on Turn findings into tickets. Extra instructions set its limits, such as how many tickets a run may file or who to assign.

Each run decides up to 25 open findings, newest first. It checks each one against the default branch, because a finding can describe code that has since changed, then gives it one outcome:

• Resolved: the code already does what the finding asks.
• Duplicate: an older finding that repeats a newer one is ignored with Duplicate of <finding id>.
• Ignored: it conflicts with the project's rules or direction, or the cost outweighs the benefit. The reason is recorded on the finding.
• For a person: it needs a decision, money, an account setting, or a change only people may make. The ticket is filed so the factory doesn't pick it up.
• Ticket: everything else that's real and worth the work. The ticket is written the way the project writes tickets, and meets every condition the factory's trigger sets, so the factory starts on it.

Every outcome is recorded on the finding: its status, a Triage <date> line in its analysis, and the ticket link. A ticketed finding is tagged triage-ticketed. The ticket ends with a What this change addresses section that links the finding and its observations.

Tickets are left unassigned unless the extra instructions name someone. The factory's pull requests still go to your reviewers.

#From finding to merged fix

1. A learning loop records the finding.
2. Turn findings into tickets, or you, files a ticket and links it. The finding moves to In progress.
3. Your ticket-to-pull-request loop builds the ticket and opens a pull request.
4. When that pull request merges, Tessl resolves the finding.

A pull request closed without merging leaves the finding In progress. If the ticket is canceled, the next triage run removes the link and decides the finding again.

#How duplicates are avoided

• Before recording a finding, the learning loops compare it with the project's existing findings. When an open one describes the same problem, they add the new evidence to it as an observation.
• Triage ignores older findings that repeat a newer one, and combines findings one change would fix into a single ticket.
• Triage doesn't file a ticket for a finding already linked to an open one. A finding gets a new ticket only after its ticket is canceled, when the next triage run removes the link and decides the finding again.
• Only one Turn findings into tickets run works on a project at a time.

#Change the cadence or stop a loop

• Pause: on the Learn from past work page, choose Pause for the loop, or use Loop actions on the loop's page, or run tessl schedule pause <loop id>. A paused loop starts no scheduled runs. Trigger now still works.
• Resume: choose Resume, or run tessl schedule resume <loop id>.
• Remove: on the loop's page, choose Archive from Loop actions, or run tessl schedule delete <loop id>. Its past runs and findings stay. To change the cadence, archive the loop and turn it on again with the new one.

Pausing Turn findings into tickets stops new tickets. It doesn't withdraw tickets already filed, and the factory still builds those. Pausing a loop never cancels a run already in progress. See Stop, remove, and move loops to cancel runs, move a loop into tessl.json to change its instructions or environment, or stop a whole factory.

#Add your own maintenance loop

Learn from past work looks for problems that any repository has. For a problem specific to yours, write a skill and run it on a schedule from tessl.json. The Tessl Carnival workshop walks through one. Its maintenance loop looks for one kind of problem, such as docs that no longer match the code, and files an issue for the factory.

A custom loop can record findings instead of filing issues. Turn findings into tickets then triages them with the rest, with the same duplicate checks. The manage-findings skill in the tessl/harness-engineering plugin covers creating and linking findings.

#Next steps

• Automations overview: loops, actions, triggers, and runs.
• Projects in the app: the Loops and Findings tabs.
• Stop, remove, and move loops: pause, archive, cancel runs, and move a loop into tessl.json.
• Improving agent code quality: run find-optimizations yourself for a one-off look at review feedback.