How a small project intended to improve local LLM interaction developed into an autonomous software engineering system with persistent memory, repository analysis, tool execution and recovery.
Status: October 2026 | REAPER-AI v0.9.1 development line
Figure 1 – Current REAPER-AI web interface with project tree, integrated diff view, agent activity, run summary, live events and diagnostics.
1. Why Build Another AI Coding Agent?
The original idea behind REAPER-AI was considerably simpler than the system that eventually emerged. I wanted a local interface for working with language models without constantly running into context limitations. Existing solutions could generate code and answer technical questions, but maintaining continuity across longer engineering tasks remained difficult. A model could inspect a source file, identify a possible defect and suggest a correction. Yet once the conversation became sufficiently long, previously established information could disappear from its effective context. Important decisions had to be repeated, and results from earlier investigations were not necessarily available when needed. The underlying problem was not exclusively the context window of the model. It was the absence of a reliable mechanism for managing the information gathered while working. Initially, a lightweight chat frontend seemed sufficient. The project gradually moved beyond that objective as it became clear that a useful coding assistant needed to do more than maintain conversations. It needed to inspect repositories, execute commands, modify files, verify results and preserve its working state between operations. That development eventually led to REAPER-AI: a locally operated autonomous coding agent whose primary interface happens to be a chat.
Source Code and Development Status on GitHub
REAPER-AI is developed as an open-source Python project under the MIT licence.
Repository: https://github.com/robertbackhaus-a11y/REAPER-AI
The system described here covers the development through October 2026, including the established v0.9.1 architecture, native MCP integration and the subsequent v1.0.0 development direction. The repository remains the authoritative source for the currently released implementation.
2. What REAPER-AI Actually Does
REAPER-AI is intended to process software engineering assignments independently within a local operating-system environment.
A typical request might involve investigating a defective function, modifying several related modules, running tests and reporting the changes. Unlike a conventional chatbot, REAPER-AI can perform the necessary operations itself. Its implemented functions include autonomous repository inspection, source-code analysis, targeted file modifications, operating-system command execution, Git inspection, test execution and error correction. An integrated web editor provides direct access to project files. The agent can also discover and execute external tools through the Model Context Protocol. Projects have separate workspaces, conversations, model configurations, repository indexes and durable knowledge. SQLite preserves execution history, observations and checkpoints so interrupted operations can be continued explicitly.
The interface displays live execution events, tool results, model decisions and diagnostic information. These functions should not be confused with a guarantee of successful autonomous execution. Whether an assignment is completed correctly still depends substantially on the selected model and its ability to maintain a coherent sequence of engineering decisions.
3. From the First Execution Engine to Sentinel
The initial implementation concentrated on establishing a functional connection between a local language model and the filesystem. Python was an obvious choice. It provides direct access to filesystem operations, subprocess execution, Git and HTTP interfaces without requiring an extensive application framework. LangGraph was selected to manage the execution process. It provides explicit states and transitions while allowing the language model to determine what technical operation should be performed next.
The early approach followed relatively fixed execution stages. This was sufficient for simple tasks but unsuitable for problems that required repeated investigation and correction. A software defect rarely follows a predictable sequence of operations.
The execution architecture therefore evolved toward a single iterative agent named Sentinel. Its fundamental workflow is: Prepare → Decide → Execute → Observe → Decide → … → Finalize.
During each iteration, the model receives the current assignment and relevant recorded evidence. It returns a structured decision identifying the next tool and its arguments. The Python dispatcher executes the operation and records the actual outcome. That observation becomes part of the next decision. The model is responsible for technical reasoning, while the execution engine controls tool invocation, process limits, persistence and recorded results. This separation is essential. A language model may assert that a file was modified. Only the actual filesystem operation and its recorded result establish whether that modification occurred.
Figure 3 – Sentinel execution loop: the model decides, the dispatcher executes, and recorded observations feed the next decision.
4. System Architecture
REAPER-AI deliberately uses a relatively small local technology stack. The central application consists of Python, LangGraph, Ollama, FastAPI and SQLite. The browser interface uses HTML, CSS and vanilla JavaScript. Ollama provides access to locally installed language models. FastAPI exposes project management, conversations, execution control and event streams. SQLite stores application state without requiring a separate database service. The architecture does not use a hosted agent platform, a distributed execution environment or a separate orchestration service. This is a deliberate design decision rather than a temporary restriction.
REAPER-AI is intended for one user operating within an existing workstation environment. Introducing role management, distributed workers, additional message brokers or multiple state databases would increase complexity without addressing the principal engineering problems.
The agent executes tools with the permissions of the operating-system user who started it. Existing file modifications are protected through source hashes. When Sentinel applies a targeted patch, the expected content and SHA-256 hash must match the current file. The system does not automatically commit or publish repository changes.
Figure 2 – Logical REAPER-AI architecture: browser UI, FastAPI, Sentinel, local models, tool dispatcher, SQLite and the local repository/OS environment.
5. Repository Analysis and the Context Problem
One of the first practical difficulties was source-code navigation. Loading an entire repository into a model context is rarely efficient. Large projects contain numerous files that are irrelevant to a particular assignment, while the functions needed for the task may occupy only a few hundred lines.
REAPER-AI therefore maintains an incremental repository index containing file metadata, hashes, Python symbols, imports and selected Git information. Sentinel can use this index to locate potentially relevant modules before requesting specific source ranges.
However, retaining source information alone proved insufficient. During development, the agent occasionally requested the same file ranges repeatedly despite having already inspected them. The recorded observations demonstrated that a successful tool operation did not necessarily translate into information that the model subsequently used.
The system now distinguishes historical source coverage from source excerpts actually included in the next model prompt. Working memory also distinguishes confirmed tool facts from model interpretations and open questions. A successful read establishes that source content was retrieved. It does not prove that the model correctly understood the code.
6. Persistent Memory and Recovery
A long-running coding agent needs persistent state for a different reason than a conversational assistant. It must remember not only what was discussed, but which operations were performed, what those operations returned, which files changed and which verification steps remain outstanding. REAPER-AI uses SQLite to retain conversations, projects, run results, observations, checkpoints and durable project knowledge. Temporary working memory contains the current task, confirmed findings, proposed decisions and unresolved questions. Durable memory is more restrictive. Explicit user decisions and recorded execution outcomes can survive across conversations, while arbitrary model statements are not automatically promoted to established project facts. Execution checkpoints allow interrupted work to continue from a previously recorded stage. Recovery is explicit. After an interruption, REAPER-AI does not silently restart the entire assignment or repeat every completed operation.
7. MCP: Extending the Available Tools
Version 0.8.0 introduced native Model Context Protocol support. MCP provides a standardized interface for discovering and executing tools made available by external servers. REAPER-AI supports local stdio connections and Streamable HTTP. MCP tools are integrated through the existing tool dispatcher rather than through a separate orchestration platform. This allows Sentinel to use additional capabilities without changing its central execution model.
The distinction between a tool interface and an agent is important. MCP makes functions available; it does not determine when they should be used or whether the results satisfy an engineering assignment. Those decisions remain part of Sentinel’s iterative workflow.
8. The Web Interface as a Development Workspace
The interface evolved alongside the execution engine. What began as a conversation interface now combines project selection, persistent chats, repository navigation, an integrated source editor and execution diagnostics. The browser displays live events, including phase changes, tool operations and checkpoint activity. Decision Trace records provide insight into which information was presented to the model, which action it selected and what happened when the tool executed. Separate runtime diagnostics can display information returned by Ollama, including model-thinking content when available. The interface does not attempt to manufacture reasoning steps or represent an operation as completed before the execution engine records its outcome. This approach reflects an important practical requirement: autonomous software development is difficult to evaluate when the only visible result is the model’s final answer.
9. D01: Testing Autonomous Repository Analysis
D01 was developed to examine whether Sentinel could conduct a repository investigation independently and produce a technically defensible assessment. The test was not concerned with generating code. It evaluated how the agent navigated an unfamiliar source tree, used its tools, responded to invalid requests and determined when enough evidence had been collected. The accepted Qwen3.8-Q5 run completed after 18 model calls and 17 tool calls in 128.9 seconds. The agent recovered from two invalid source-range requests, avoided repeating successful identical reads and produced a report citing inspected source locations. The execution received grade 2, while the technical quality of the report received grade 4. The overall assessment was grade 3. This discrepancy was instructive. The agent operated autonomously and completed its workflow, but its report contained incorrect technical conclusions. A completed execution cannot be treated as proof that the resulting analysis is correct.
10. S02: Making Source Selection More Relevant
S02 addressed problems discovered during source inspection and the earlier D01 investigations. The central problem was determining which previously collected source excerpts should be included in the next model decision. Earlier selection behavior could favor historical fragments over a currently relevant range. An agent might possess the necessary evidence in persistent state while receiving less useful information in its immediate context. S02 introduced relevance-based selection of individual source excerpts. Source references, requested ranges and their relationship to the current task became more important than simple historical ordering. The result was a more controlled distinction between information retained by the application and information actually available to the current model invocation. S02 improved context construction. It did not guarantee that the model would interpret the selected source correctly.
11. Three Models, One Autonomous Bugfix
The most useful model comparison involved a small Python transaction-report application containing a reproducible calculation error. The program excluded negative transaction amounts from category totals. Refunds therefore failed to reduce the corresponding totals. Three independently prepared project copies were tested using Qwen3.8-Q5, Qwen3.6-35B-A3B and Devstral Small 2. All three models received the same assignment: identify the defect, correct the implementation and verify the result without unnecessary changes. Qwen3.8 correctly identified the defective condition, modified the source and passed all three independent tests. Nevertheless, it repeated verification operations unnecessarily. Qwen3.6 identified the defect considerably faster, but neither modified the source nor executed a functional test. Devstral performed extensive additional tool operations without completing the correction within the test window. The comparison revealed three different aspects of autonomous coding. Recognizing a defect does not establish that a model can implement the correction. Completing a run does not demonstrate that the requested work was performed. A functionally successful implementation can still expose significant inefficiencies in the agent’s decision process.
Qwen3.8 remains the reference model for REAPER-AI because it demonstrated the strongest practical autonomous performance among the evaluated candidates. This is a decision based on observed operation within REAPER-AI, not a general ranking of the models’ coding abilities.
| Measurement | Qwen3.8-Q5 | Qwen3.6-35B | Devstral 24B | Comment |
| Runtime | 157.2 s | 44.0 s | 186.0 s | Qwen3.6 was fastest, but not successful. |
| Model calls | 31 | 11 | 46 | Higher count did not equal better efficiency. |
| Tool calls | 30 | 10 | 46 | Devstral used many tools without finishing. |
| Input tokens | 123,366 | 39,702 | 272,292 | Context use varied substantially. |
| Repeated actions | 18 | 2 | 38 | Repeated verification remained a major issue. |
| Functional correction | Successful | Failed | Failed | Only Qwen3.8 produced a verified fix. |
Figure 4 – Three-Model Autonomous Bugfix Benchmark. The same defect and acceptance check were used for all three models.
12. Why Better Models Do Not Automatically Produce Better Agents
The model experiments revealed a recurring pattern. Language models can generate technically plausible actions without consistently maintaining an accurate understanding of the overall execution state. One model may continue investigating after sufficient evidence has been obtained. Another may conclude that a proposed action has already been performed. A third may repeat successful verification commands because the significance of earlier results was not preserved adequately. These failures should not automatically be addressed by adding more layers of orchestration. A larger framework cannot compensate indefinitely for a model that repeatedly ignores available evidence. REAPER-AI therefore follows a relatively narrow development principle: improve the existing execution state, evidence handling and decision context where measured failures demonstrate a concrete need.
13. Current Limitations and Further Development
The project has demonstrated autonomous source investigation, targeted modifications, verification, error correction and checkpoint recovery. It has not demonstrated consistently high reliability across arbitrary software engineering assignments. Repeated tool calls remain possible. Technical reports can contain factual errors even when the agent completes normally. Completion detection and the quality of model decisions still require improvement. The established autonomous process supervisor is Windows-specific. Full Linux and macOS operation requires corresponding process supervision and practical acceptance tests. The development direction beyond v0.9.1 concentrates on multi-file coding, functional verification, autonomous correction, preservation of existing changes, cross-platform operation and improvements to the daily workflow.
14. Conclusion
REAPER-AI began with the relatively modest objective of making local language-model interaction more practical. The development quickly exposed a more fundamental problem. A coding assistant becomes useful as an autonomous engineering tool only when it can retain evidence, make changes, execute checks and distinguish completed work from its own intentions. The implementation now provides the necessary technical foundation: local inference, iterative execution, repository indexing, persistent memory, checkpoint recovery and extensible tools. The experiments also show why these mechanisms are necessary. A fast model can finish without solving the task. A coding-specialized model can spend minutes repeating ineffective operations. Even the strongest tested model can correctly fix a defect while wasting substantial effort on redundant verification. The remaining challenge is therefore not simply to make the language model generate better source code. It is to improve the quality and continuity of the engineering decisions made between individual tool operations. For a locally operated coding agent, that distinction is likely to determine whether autonomous execution becomes an everyday development tool or remains an interesting experiment.
Project: REAPER-AI
Repository: https://github.com/robertbackhaus-a11y/REAPER-AI
Licence: MIT
Technical baseline: October 2026