Prometheus: A Neo4j-Backed Code Agent That Repairs Repositories

The problem Prometheus targets: repository-level repair, not snippet generation

Most coding assistants operate on a file you paste or a selection you highlight. Prometheus is aimed at the harder case: a bug report filed against a repository you did not write, in a language you may not have chosen, where finding the relevant code is itself most of the work. The README frames this as classifying issues, reproducing bugs, retrieving relevant context and generating validated patches, with the retrieval step backed by a graph rather than a flat vector index.

The intended user is not an individual developer asking for a function. It is a team or researcher working on automated software engineering: someone who wants an agent to take an issue from a tracker and produce a patch that survives tests. The arXiv paper, 'Prometheus: Towards Long-Horizon Codebase Navigation for Repository-Level Problem Solving', signals the same audience. The README's news section claims TOP 5 and TOP 1 in the agents using gpt-5 category on the SWE-bench leaderboard as of November 2025. That is the project's own claim about a specific leaderboard category; it is not an independent measurement, and it says nothing about how the system performs on your repository.

Unified knowledge graphs plus LangGraph state machines

The architecture has two load-bearing pieces. The first is a unified knowledge graph stored in Neo4j that represents code structure and semantics together: the README lists codebase structure, AST and documentation as things the graph covers. The second is LangGraph, used as the state machine that coordinates specialized agents. The README names three roles explicitly: classification, reproduction and resolution.

The data flow implied by that description is a pipeline. An issue arrives and is classified. A reproduction agent attempts to establish that the bug is real, which requires executing code. A retrieval step queries the graph for context that is structurally related to the failure, not merely textually similar. The resolution agent then produces a patch, which is validated. Validation happens in Docker, described in the README as a containerized execution environment for isolated testing.

That ordering matters. Reproduction before retrieval means the system has a concrete failure to search around, rather than searching from the issue text alone. Graph retrieval over AST and structure is a different bet from embedding search: it can follow call edges and definitions, but it depends entirely on the graph being correctly populated for your language. The README also mentions a feature implementation pipeline with optional regression testing, and a question answering mode using tool-augmented LLM agents. The paper is the place to look for the mechanism detail; the README gives the shape, not the internals.

Getting it running: what the README does and does not give you

This is the weakest part of the supplied material. The README describes the platform and links to docs/Multi-Agent-Architecture.md and the arXiv paper, but the excerpt provided here contains no installation section, no requirements file listing, no environment variable names and no example command. There is no docker compose invocation, no Neo4j connection string key, no model provider configuration shown.

What can be inferred from the repository layout and description is limited and should be treated as inference, not instruction. The primary language is Python. The system requires a running Neo4j instance for the knowledge graph and Docker for isolated test execution. The agents are built on LangGraph, which implies a model provider must be configured somewhere, and the README's leaderboard claim references gpt-5, suggesting OpenAI-compatible endpoints are at least one supported path.

If you intend to evaluate this, the first file to open is docs/Multi-Agent-Architecture.md, followed by whatever configuration template exists in the repository root. Do not assume a working setup from the README alone. A project with no published releases, as is the case here, also means there is no versioned artifact to pin; you are tracking main.

Where Prometheus breaks down or is the wrong choice

The dependency surface is the first constraint. Neo4j is not optional in the described design; the knowledge graph is the retrieval mechanism, and without a populated graph the context retrieval step has nothing to query. Docker is likewise required for the validation environment. That means a host with a container runtime, a database service and enough memory to hold both, plus whatever the LLM calls cost. For a single-file fix, this is an enormous amount of machinery.

The second constraint is graph construction. The README claims multilingual codebase support, but a unified graph over AST and documentation has to be built per language, and the quality of every downstream agent depends on that step. Nothing in the supplied material describes how the graph is built, how it is kept in sync when code changes, or how long indexing takes. If the graph is stale, the retrieval agent will confidently return context for code that no longer exists.

The third is the validation boundary. Docker-isolated testing proves a patch passes the repository's tests. It does not prove the patch is correct, minimal, or acceptable to maintainers. A patch that satisfies a test suite while duplicating logic or bypassing an abstraction is a real outcome, and the README's 'multi-level validation' phrase does not tell you what those levels check. Finally, there are no releases. Depending on main for a system that writes and executes code in containers is a supply-chain decision you should make deliberately.

How this differs from SWE-agent and similar harnesses

The obvious comparison is SWE-agent and the family of SWE-bench harnesses, which the README itself invokes by citing the leaderboard. The difference in approach is where the context comes from. A typical harness gives the model a shell, a file viewer and a search tool, then lets it explore the repository turn by turn. Retrieval is a consequence of the agent's actions, and the agent pays for every wrong turn in tokens.

Prometheus front-loads that cost into a knowledge graph. Structure and semantics are extracted ahead of time, so the retrieval agent queries a precomputed representation instead of walking the tree. In principle that shortens the long-horizon navigation the paper's title refers to, and it is the reason the project describes itself as reasoning rather than guessing. The trade is real: a harness has no indexing step and works on any repository immediately, while Prometheus needs the graph built first and degrades when the graph is incomplete. If your repositories change constantly, the indexing overhead may never amortize.

The README also positions the project against Lovable and Replit, describing it as moving beyond unreliable prototype generation toward verifiable software. That is a different comparison, aimed at greenfield generation rather than repository repair, and the two claims sit awkwardly together.

Maintenance, releases and the licence discrepancy

The repository is not archived and the last push recorded is 2026-08-16, which suggests active work. There are no retrieved releases, so there is no tagged version, no changelog and no upgrade path other than pulling main. For a platform that orchestrates multiple agents and executes code in containers, that is a meaningful operational gap: you cannot pin a known-good commit range without doing it yourself.

The licence situation needs attention. The repository metadata states GPL-3.0. The README's badge image links to opensource.org/licenses/Apache-2.0 and the alt text reads 'License: Apache 2.0'. These are not compatible positions, and the discrepancy is in the project's own front page. If you are evaluating Prometheus for internal use, the distinction rarely matters. If you intend to embed it in a distributed product, it matters a great deal, because GPL-3.0 and Apache-2.0 impose very different obligations. Resolve which one applies before you build on it. This is a factual observation about the repository, not legal advice; consult counsel for your specific case.

Upgrade cost is hard to estimate from the supplied material. With no releases, every update is a diff against main, and any change to the graph schema or the LangGraph state machine can invalidate an existing index.

Editorial conclusion

Prometheus suits teams that already run Neo4j and Docker and want graph-based context retrieval over a multilingual codebase rather than a chat wrapper around a single model. It is the wrong tool for anyone who needs a pip-install-and-go assistant, and the README's Apache-2.0 badge against a GPL-3.0 repository license must be resolved before you copy any of it into a product. Before adopting, confirm which licence actually governs the code, confirm the Neo4j schema and index creation path, and read docs/Multi-Agent-Architecture.md to see whether the agent graph matches your workflow.

Official sources

1. EuniAI/Prometheus on GitHub
2. Issues
3. License: GPL-3.0
4. README