aws-samples / aws-samples/sample-autonomous-cloud-coding-agents

Orchestrator/ Memory: Implement review feedback memory loop so agents learn from PR reviews

Ouverte
#27 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub
agent-runtime orchestration
Langage dominant
TypeScript
Étoiles
146
Forks
46
Merge moyen
3 j 10 h
PR mergées (30 j)
24

Description

### Component

API or orchestration

### Describe the feature

> This issue depends on #26

This addresses the "Review feedback memory loop (Tier 2)" item from Iteration 3d in the roadmap.

The agent doesn't learn from PR reviews. If a reviewer leaves comments like "use zod for validation", "return 201 for creation endpoints", "use our errorHandler middleware" - those corrections apply to every future task on that repo, but the agent has no way to internalize them. The next task on the same repo will repeat the same mistakes, and the reviewer has to leave the same comments again.

The memory system (Iteration 3b) already supports writing and reading repo-level knowledge. The webhook infrastructure (Iteration 3a) already handles inbound events. What's missing is the pipeline that connects PR review comments to persistent memory.

### Use case

I submitted a `new_task` to create an API endpoint. The agent delivered working code but without request validation, wrong HTTP status codes, and inline error handling instead of the repo's middleware pattern. I left 3 review comments. Then I submitted another task for a different endpoint on the same repo - the agent made the exact same mistakes because it had no memory of my feedback.

### Proposed solution

Use the existing webhook infrastructure to capture `pull_request_review` events and extract actionable rules into memory.

**Flow:**

1. Reviewer leaves comments on an agent-created PR
2. GitHub sends a `pull_request_review` webhook event
3. A new handler (separate from the task-creation webhook) receives the event, fetches the diff + comments
4. A Bedrock call extracts rules from the comments, classifying each as:
- **Repo-level**: "use zod for validation on all endpoints" - applies to all future tasks
- **Task-specific**: "this function needs a null check" - context for this task only
5. Rules are written to AgentCore Memory with `source_type: review_feedback` provenance
6. On the next task for that repo, `loadMemoryContext()` loads these rules during hydration - the agent starts already knowing the repo's conventions

**A real example:**

Review comments: "validate with zod", "return 201 for POST", "use errorHandler middleware"

Next task prompt includes:
```
Repository knowledge (from past reviews):
- Use zod for request body validation on all endpoints
- POST endpoints that create resources must return HTTP 201
- Use errorHandler middleware, not inline try/catch
```

The agent applies all three without the reviewer repeating themselves.

**What's we need to add:**
- A webhook handler for `pull_request_review` events (the current handler only creates tasks)
- An extraction Lambda with a Bedrock prompt to turn review comments into structured rules
- Provenance tagging on memory writes (`source_type: review_feedback`) so trust scoring (Iteration 3e) can weight these appropriately

### Other information

_No response_

### Acknowledgements

- [x] I may be able to implement this feature
- [ ] This might be a breaking change

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Commencez par examiner l’infrastructure de webhooks existante, le système de mémoire d’Iteration 3b et issue #26. Suivez le webhook actuel de création de tâches et loadMemoryContext(), puis déterminez comment les événements pull_request_review, la récupération des diffs et des commentaires, l’extraction Bedrock et la provenance de source_type s’articulent. Le travail est considéré comme terminé lorsque les règles de revue au niveau du dépôt sont persistées et chargées dans les tâches ultérieures, tandis que les retours spécifiques à la tâche restent correctement délimités.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
aws, github, typescript
Domaine
ai, api, backend, cloud
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
38/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.