A free, open source personal AI agent that is always on, proactive and sessionless. Self-host your open source alternative to Muse, Dots, Instinct and Town.
Free and fair source. Install Harness Maxxing on your own VPS in one command and get Claude Code working for you 24/7: hundreds of persistent sessions, memory, scheduled jobs, Telegram and voice.
ForgeLoop is a distributed software-engineering harness for autonomous coding agents. It decomposes feature specifications into parallel units of work, executes agents in isolated environments, and uses builds, tests, containers, browser automation, and independent review to close the loop between generated code and verified software.
What it does: you label a GitHub issue; ForgeLoop plans it, has a coding agent implement it, runs your real tests, reviews the diff, and opens (or, if you allow it, merges) a pull request.
Why it's different: an agent saying "done" counts for nothing. A change only moves forward when your configured checks pass and every acceptance criterion has recorded evidence.
Where code runs: on a runner you control, with your own model API key. The hosted control plane coordinates and keeps the audit trail; it never checks out your repository.
Proof it works:issue #10 → PR #11 on a public repository was planned, implemented, verified, and merged with zero human approvals, for about $0.22 in recorded model cost. Replay it step by step.
Built with: Java 21, Spring Boot, GraphQL, PostgreSQL, React 19 + TypeScript, Docker, GitHub Apps, and MCP — over 900 automated unit and integration tests plus end-to-end browser tests in CI.
ForgeLoop takes GitHub issues or feature specifications through planning, bounded agent work, integration, verification, and human review. Its central design principle is simple: an agent saying “done” is not evidence. A run becomes reviewable only when its configured checks and acceptance criteria have supporting results.
This repository is presented as a technical portfolio case study, not a self-hosting or local-install guide. The hosted site is the product demo; GitHub sign-in is required to use the console. The runner is a separate execution component in the product architecture.
The engineering problem
Coding agents can produce patches, but reliable software delivery also needs safe coordination, repository access, isolated execution, bounded spend, recovery from failure, and proof that a change meets its requirements. ForgeLoop explores how to make those concerns explicit in a working product rather than hiding them behind a chat interface.
The delivery loop
A GitHub issue or operator specification enters through repository-specific intake rules.
A planner turns the request into a validated dependency graph of bounded tasks.
Runners claim compatible work and execute it in isolated Git worktrees, using locally configured model credentials.
Changes are integrated, then repository-policy checks, acceptance criteria, and an independent review produce evidence.
Failed checks can route into a limited repair cycle. Passing work follows the configured human-approval policy before GitHub publication; auto-merge is opt-in and checks the verified commit.
Administrators can also manually ask a runner to scan a repository snapshot for evidence-backed issue proposals. Scans are read-only, may incur provider charges, and never create GitHub issues without an explicit review action.
Architecture
Component
Responsibility
Hosted web app
Public product pages and the GitHub-authenticated operator console for runs, repositories, policies, usage, support, and evidence.
Control plane
Java and Spring Boot GraphQL API; organization-scoped state, policy, issue intake, task scheduling, runner leases, audit records, and GitHub coordination.
PostgreSQL and artifact storage
Flyway-managed durable workflow state plus redacted, checksummed evidence in filesystem or S3-compatible storage.
ForgeLoop runner
Java desktop/CLI process near the repository; uses Git worktrees and Docker for execution, MCP for approved context/tools, and runner-local provider credentials.
External services
GitHub App and OAuth for identity/repository events; configured hosted or local model providers for agent work.
The control plane coordinates work; the runner handles checkout, execution, and model calls. The hosted service stores workflow records, issue text, findings, usage, and verification evidence. Optional detailed run records can also upload prompts, provider responses, and repository context as artifacts. Local execution is not an offline-only or zero-data-transfer promise; provider data handling still applies.
Engineering decisions
Challenge
Design response
Parallel agents can overwrite or depend on one another’s changes.
Validate task graphs, capabilities, dependencies, and owned paths; issue expiring single-owner leases; use isolated worktrees; integrate declared commits deterministically.
Model output can be incomplete, malformed, or overconfident.
Require structured outputs, validate paths and schemas, run versioned verification gates, track criterion-level evidence, and use bounded repair and review stages.
Repository execution and credentials are sensitive.
Keep checkout/provider work on the runner; use short-lived GitHub installation grants, hashed runner credentials, organization membership checks, redaction, and audited operator actions.
Services and workers can fail mid-run.
Persist workflow transitions, publish runner heartbeats, expire and recover leases, retain checksummed artifacts, and expose progress and failure evidence to operators.
Agent usage has real cost and needs a human boundary.
Track provider/model/token and estimated-cost data, enforce budgets and retry limits, require configured approval, and keep automatic merge disabled unless an administrator opts in.
Technology
Backend: Java 21, Spring Boot, Spring Security, GraphQL, Spring Data JPA, Flyway, PostgreSQL.
Web: React 19, TypeScript, Vite, Vitest, Playwright; the public site is prerendered with SEO and social metadata.
Runner: Java 21, Git, Docker, MCP, local provider adapters, and native desktop packaging for Windows, macOS, and Linux previews.
Tool gateway: TypeScript, the Model Context Protocol SDK, and Zod schemas.
Delivery and operations: GitHub Apps and OAuth, GitHub Actions, Docker Compose, filesystem/S3-compatible artifact storage.
Evidence and project boundaries
The hosted product is live and the repository contains the implementation and automated checks. Current CI covers the control plane, runner, web app, MCP gateway, Windows installer setup, and a disposable Compose end-to-end environment that exercises database restore, runner pairing, package enrollment, and browser tests.
A live issue-to-verified-PR path has been demonstrated against a demo repository. A second-repository unattended issue-to-merge run was also validated on October 9, 2026. Remaining checks include off-host backup/restore, a physical reboot/server validation, staging burn-in, and a production go/no-go review. Desktop installers are unsigned development previews and macOS packages are not notarized. The website and desktop downloads label this limitation.
This is an evolving portfolio product, not a claim that every production launch gate is closed. The open items are listed at the bottom so implementation and operational evidence remain distinct.
Checklist reviewed October 15, 2026. Checked items are implemented or have the
specific evidence stated; they do not imply every production validation is complete.
Product and control plane
GitHub sign-in and self-service account provisioning with organization-scoped membership and roles.
GitHub App installation, signed webhook validation, idempotent deliveries, repository synchronization, and configurable issue-label intake.
Optional per-repository label bypass and Issue Chat label application with explicit paid-work warnings.
Optional issue-assignment gate for any assignee or a specified GitHub login; read-only intake diagnostics.
Manual repository analysis proposals with bounded/redacted context, runner-local model calls, usage estimates, and administrator-approved issue creation.
AI issue chat with editable specifications, explicit issue publication, optional intake-label application, and conversation deletion.
Independent review and criterion-level evidence before delivery, with human approval required only when configured.
GitHub check and pull-request publication; guarded auto-merge is opt-in and validates checks and the expected commit.
Product experience and engineering quality
Responsive dashboard and public product pages, user documentation, SEO/social metadata, and structured data.
Cross-platform desktop preview packaging and GitHub Release download discovery with SHA-256 verification.
Runner 1.0.12 preview published for Windows/macOS x64 and ARM64, plus Linux DEB, RPM, Arch, and portable archives for both architectures; all twelve package digests verified.
Navy-and-teal desktop redesign, rounded native icons, HiDPI branding, and local preview/window-control regression coverage.
Automated CI for Java modules, frontend checks, MCP checks, Windows setup, and disposable end-to-end workflows.
Live public downloads/release-feed smoke check for 1.0.12, separate from installer signing.
Linux server Compose deployment with loopback diagnostic ports and server-hosted Cloudflare ingress; physical reboot recovery remains unverified.
Live validation and remaining launch gates
Complete a live verified delivery and merge test: project-hub issue #6 / PR #7 merged after manual approval (October 9 evidence).
Complete a second-repository unattended issue-to-merge test: project-hub issue #10 / PR #11 merged automatically with human approval disabled (successful validation). Both delivery tests are complete; operational launch gates remain separate.
Validate a physical workstation/server reboot, tunnel recovery, runner heartbeat, and authenticated access.
Configure encrypted off-host backup retention and complete a restore drill on another host, including evidence objects.
Complete staging burn-in.
Verify external alert delivery.
Record an explicit production go/no-go review after the operational checks above.
Sign Windows/macOS installers and notarize macOS packages; published previews remain unsigned.
Publish the canonical-domain SEO migration and new authorization article: October 15 live audit checked all 21 public pages with zero findings; old-host article redirects preserve path/query, and the new social image returns HTTP 200 (audit evidence).
Verify the new domain in Google Search Console and submit its canonical sitemap; search indexing and ranking are not established by build checks.
Enable and verify support email notifications.
October 22 repository hardening
Run history now uses tenant-scoped database pagination, with direct issue-source
lookups and complete paginated usage reporting. The guarded multi-turn writing
worker is connected behind a default-off runner switch and repository policy
opt-in. Lease renewal, spend reservations, cancellation, and verification
boundaries are described in agent-loop activation.
Security updates, immutable CI action pins, code separation, bounded load
scenarios, and local validation are recorded in the
hardening report. Operational launch gates remain
separate and unchanged.