Argus
Event-driven multi-agent AI code review on AWS
A pull-request review platform built as a distributed event system rather than one large prompt. A webhook parses and chunks the diff, SNS fans it out to four specialist agents (security, performance, style, test coverage), each on its own queue, and a summary agent aggregates their findings from DynamoDB into a single severity-ranked comment. A separate learning loop records recurring patterns per repository.
Verified: each of these is checkable in the repository
- 8
- Lambda functionswebhook, parser, 4 specialists, summary, ltm-writer
- 7
- SQS queues, each with its own DLQmaxReceiveCount: 3 on every queue
- 4
- SNS topicspr-webhook, pr-parsed, review-findings, review-complete
- 4
- CDK stacksMessaging, Storage, Api, Agents
Code review has two failure modes that pull in opposite directions. Reviewers who read carefully are slow, and reviewers who read quickly miss things. Handing the whole diff to a single language model reproduces the second problem: one prompt asked to check security, performance, style and test coverage at once does all four shallowly, and you cannot tune or debug any one of them without disturbing the others.
Argus splits review into independent specialists that run in parallel. A GitHub webhook hits API Gateway, a webhook Lambda validates the HMAC signature, and a parser agent chunks the diff and writes it to DynamoDB. Publishing to an SNS topic fans the parsed diff out to four SQS-backed Lambdas, each with its own model choice and prompt. As findings land, a summary agent reads them back from DynamoDB, deduplicates, ranks by severity, and posts one consolidated Markdown comment. A final event feeds a long-term-memory writer that records recurring patterns per repository.
Why it is built this way
01Fan-out over a monolithic prompt
Four agents on four queues run concurrently and can be tuned, versioned and debugged independently. Adding a fifth reviewer is an SNS subscription, not a prompt rewrite.
02A dedicated queue and DLQ per agent
Every queue has its own dead-letter queue at maxReceiveCount 3. A slow or failing security agent cannot stall style or test coverage, and its poison messages land somewhere inspectable instead of disappearing.
03Two model tiers, chosen per task
Security and performance run on Nova Pro because they need deeper reasoning. Style and test coverage run on Nova Micro, which is roughly twenty times cheaper per token. The split is a deliberate cost decision, not a default.
04A transport abstraction the agents cannot bypass
Agents publish through a transport module selected by an environment variable rather than calling boto3 directly. Swapping SQS for another broker is a configuration change, and it keeps queue semantics out of agent logic.
05A learning loop, not just a reviewer
Review completion emits an event to a separate queue whose writer records per-repository patterns and accuracy in DynamoDB. The system accumulates knowledge about a codebase instead of starting cold on every pull request.
The interesting part of this project turned out to be the queue topology rather than the prompts. Once each agent had its own failure domain, debugging changed character: instead of asking why the review was wrong, I could ask which queue was backed up. That is the difference between a system you can reason about and one you can only re-run.
Next project
ObserveAI
A distributed system built to be observed while it fails