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
Labeling an issue starts a run through your forge's webhook. 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 (Kata VMs on every plan) 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. It contains no credentials either; the details are on the security page.
The limit
What the sandbox does not contain is your project's dependencies. It 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.
2m 52s from label to merge request
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 need a plan first: the agent drafts a specification for your approval, then a test plan for your approval. These are the two human approval gates before it writes the tests and implementation and opens a merge request.
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.
A plan that cannot deadlock. A weaker model sometimes returns a dependency graph with too few edges, which reads as "all of this can run at once" and then builds things in an order that cannot work. A health check catches the thin graph, re-prompts once, and if it is still thin falls back to a linear floor: step N depends on at least step N minus 1, unioned with whatever valid edges the model did produce. That costs parallelism and buys a pipeline that always terminates. On a model you trust, you can switch it off.
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? The quality gate draws from a catalog of 34 analysis tools, 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.
Every AI review states its blast radius. The reviewer maps each hunk of the diff to symbols in the code graph and lists the callers that resolve to them, into its own prompt and into the merge-request comment. So "this change is contained" stops being an opinion you have to take on trust. When it cannot answer, because the file is not indexed, the index is still building, or the diff is too large to map, it names which of those it was. An empty blast radius would read as "nothing calls this", and that is the one thing it must never imply by accident.
Gate passed: the change ships no regressions your linters would catch. Legacy findings stay in the baseline instead of blocking the merge request.
Code search, not a pasted repository
The agent does not paste your repository into a prompt. It searches an index and reads from its own checkout. Structural search works on every plan, Free included: find a symbol, list its callers and its callees, expand a definition. Semantic search is the paid addition, and it 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. The index is tenant-isolated and deleted with everything else when you leave.
The limit
Every other file is chunked line by line, which still retrieves, just less precisely. A repository that cannot be embedded says so rather than returning a quiet empty result, because silence would read like a clean answer.
What keeps it honest
The guarantee
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, and the economics (runs, wall-clock, review capacity) set most of the limit. One technical limit belongs next to it, though: the sandbox cannot reach a package registry, so on a project that pulls third-party packages the agent still writes the code and opens the merge request, but it cannot install them to run the tests it wrote. Until the dependencies are committed to the repository, that verification step is yours.
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.