How FragonForge works, in depth
The home page shows the four-step loop. This page explains what happens underneath: how runs are triggered, what the agent modes do, and which guardrails sit between an issue and a merged change.
The trigger
Everything starts with a webhook from your forge. You label an issue; your forge calls a per-organization webhook URL that carries a signed token, and the payload is verified against your own webhook secret, in constant time, before anything else happens. Runs are admitted against your plan's quota and concurrency limits, then queued. No cron jobs polling your repository, no standing access.
The label is not the only door: a run can also be started directly from the API or the CLI, without touching the issue. Manually started runs pass the exact same quota and concurrency admission as webhook runs.
The sandbox
Each run gets a fresh Kubernetes job with a hardened runtime (gVisor, or Kata VMs on Team and Business) and a wall-clock limit from 15 minutes (Free) up to 4 hours (Enterprise) depending on plan. The sandbox contains a clone of your repository and real toolchains: dotnet test, pytest, phpstan, rubocop and more. It contains no credentials; the details are on the security page.
Agent modes
Not every issue deserves the same process. You choose per repository how much ceremony a run gets:
One-shot
The default. Clone, gather context, write the fix, run your tests, open the merge request. One agent, one pass, best for well-specified issues.
Multi-agent
A planner drafts the approach, a coder implements it, a reviewer looks over the result before the merge request opens. The reviewer is advisory: it flags concerns in the MR description, it does not silently rewrite code.
Spec-driven
For issues that deserve ceremony: the agent first writes a spec, you approve it, then it writes tests, then the implementation. Two human approval gates before any code lands in an MR.
For goals bigger than one issue there is a fourth gear, different enough to deserve its own section: the project orchestrator, below.
The project orchestrator
Give it a goal, not an issue. The orchestrator explores the codebase, drafts an architecture, decomposes the goal into a dependency-ordered pipeline of issues, and drives each one through the same run loop you just read about. Human approval gates sit along the way, and a failed stage retries from the earliest failed point, not from scratch.
Each issue runs the normal loop and opens its own merge request; you stay the gate between stages.
Steering the agent
Two levers keep the agent on your conventions: organization-wide instructions (versioned, prepended to every run) and a per-repo .fragonforge/codingagent.md file that travels with the code, the same way you would brief a new contractor.
The quality gate
A second plane watches quality independently of the agent loop: 33 static analysis tools run against changes, and a baseline-aware gate flags only findings that are new relative to your baseline, so you are not buried in legacy noise. Repositories get an A to F rating over time, and you can let FragonForge open auto-fix merge requests for findings if you opt in.
Gate passed: the change ships no regressions your linters would catch. Legacy findings stay in the baseline instead of blocking the merge request.
Codebase context (RAG)
On paid plans, FragonForge indexes your repository with AST-aware chunking across 9 languages. The agent retrieves relevant code instead of guessing, which matters most on codebases too large to fit in a prompt. The index is tenant-isolated and deleted with everything else when you leave.
What keeps it honest
The agent never merges its own work. The merge request review is the designed-in safety valve.
Beyond that: runs are bounded by wall-clock limits, monthly quotas, and per-plan concurrency. Every model call spends your own key, so the incentive to burn tokens on your behalf does not exist.