Log2PR

Log2PR Architecture

Inspiration

Monitoring and debugging application error logs can be overwhelming. Logs show the problem, but engineers still have to manually search code, create branches, write fixes, open PRs, and notify the team. I wanted to automate this workflow.

What it does

Log2PR handles the full fix cycle automatically:

Reads error logs from Elasticsearch
Extracts stack trace, file names, and service name
Fetches related code
Generates a fix
Creates a branch and pull request
Sends a Slack message with the summary and PR link

In short, it converts logs directly into pull requests.

How I built it

I designed it as a multi-agent workflow, where each agent has a clear role.

Elastic Agent: uses MCP server tools (plus custom tool I built) to query Elasticsearch and extract error details.

GitHub Agent (team-style design, uses GitHub's MCP Server):

lead-engineer (orchestrator) : manages the subagents.

software-engineer (subagent) : fetches code, fixes it, and writes it to a virtual file system provided by Deep Agents.

git-operator (subagent) : reads the fix, creates branch, pushes code, and opens PR.

Slack Agent: Summarizes the error, attaches the PR link and notifies developers on Slack.

Key design choices I took with reasons and learnings

Subagents with separate conversations: needed to limit the tokens sent to LLM in a conversation to prevent violation of context window and other such constraints.

Virtual file system: stores large tool outputs and only passes relevant pieces to the LLM which again saved tokens. Deep Agents enabled this.

Smart context handoff: a hack that I used to make subagents share data through the virtual FS so nothing is lost in transit. A lot of trial and error with system prompts was required to bring it live!