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 that depends on the plan, from 15 minutes on Free to 120 minutes on Business, and by agreement on Enterprise. The sandbox contains a clone of your repository and real toolchains: dotnet test, pytest, phpstan, rubocop and more. What it does not contain is your project's dependencies: the sandbox has no route to a package registry today, so they must already be in the repository and a build that starts with a restore step fails there. It contains no credentials either; 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.
Can it build a whole app? Yes: a goal goes in, and the entire buildout comes out as a dependency-ordered series of reviewed merge requests, starting from a completely empty repository if that is where you are. Deep planning exists for exactly this: discovery clones and scans the repository, architecture drafts a design you approve, and decomposition is validated per step. Acceptance criteria, files to touch, and tests to add are required for every step, or the plan is rejected and regenerated. The practical limits are economic, not structural: every step is a run against your plan's quota and wall-clock limit, and your review capacity sets the pace. One tip: a large specification works best committed as a file in the repository, where discovery reads it directly instead of squeezing it through the prompt.
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, and it answers the question every engineer asks first: what if the agent itself ships junk? 33 analysis tools run against changes, from static analyzers to test runners. They are the community tools you already know (eslint, phpstan, rubocop, and more), orchestrated and normalized rather than reinvented: every finding carries its tool, severity, rule, file and line, and a fix suggestion. No proprietary engine, and we say so.
Findings are fingerprinted across runs: only findings that are new relative to your baseline block, so you are not buried in legacy noise, and a finding that disappears from the code is stamped resolved automatically. Repositories get an A to F rating over time. And because the gate lives inside a coding agent, findings do not just get listed: you can let FragonForge open auto-fix merge requests with convergence detection, so the plane that catches a problem is the same one that repairs it. Honest boundary: this is a quality gate, not a SonarQube replacement. There is no finding triage (no false-positive or accepted status, no assignment) and no taint-analysis SAST; the comparison is on the SonarQube page.
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 so the agent retrieves relevant code instead of guessing, which matters most on codebases too large to fit in a prompt. Chunking is AST-aware for C#, Go, JavaScript, TypeScript, Python, Java, Rust, PHP, and Ruby; every other file is chunked line by line, which still retrieves, just less precisely. The index is tenant-isolated and deleted with everything else when you leave.
What keeps it honest
The agent merges nothing you have not allowed. Review is the default gate; autonomous merge is an opt-in that applies only when your quality gate is explicitly green.
Autonomous merge carries hard limits of its own: changes that touch CI configuration, authentication, secrets, or dependency manifests are never merged automatically, and neither are unusually large ones. Beyond that: runs are bounded by wall-clock limits, monthly quotas, and per-plan concurrency. A run either draws on the FragonForge AI budget your plan includes, which pauses rather than overcharges when it is spent, or it spends your own credential, whether that is an API key or your own ChatGPT plan. On that second path the incentive to burn tokens on your behalf does not exist at all.
Frequently asked questions
Can FragonForge build a whole app from scratch?
Yes. Give the project orchestrator a goal instead of a single issue, and it delivers the entire buildout as a dependency-ordered series of reviewed merge requests, starting from a completely empty repository if that is where you are. A discovery stage scans the repository, an architecture stage drafts a design you approve, decomposition is validated step by step (acceptance criteria, files to touch, and tests to add are required for every step, or the plan is regenerated), and each step then runs in its own sandbox and lands as a merge request. Building a whole application this way is a built-in use case, not a workaround; the practical limits are economic (runs, wall-clock, review capacity), not structural.
Does it work on an empty repository?
Yes. You can start from a completely empty repository: the architecture stage designs the project structure and the first pipeline steps create it. When code already exists, discovery and codebase context put it to work. A large specification is best committed as a file in the repository, where discovery reads it directly instead of squeezing it through the prompt.
How many runs does building a whole application take?
Every pipeline step is one run against your plan's monthly quota and wall-clock limit, and a whole application typically decomposes into dozens of steps. There is no single honest number, because it depends on how the goal decomposes; size the plan by expected steps per month (Free 100, Solo 300, Team 1,500, Business 5,000 runs) and remember that your review pace sets the overall speed.