Appliance
A rack server delivered and installed on your network. Air-gapped installations are supported; nothing about your code or your questions leaves the premises.
Reforge · Platform · On-premises
Legacy code, modernized by agents you operate.
Reforge is an on-premises AI platform that scans your legacy codebases, builds a modernization plan and works through it with a team of agents — under the direction of your own operators. Every task is logged with what changed, what it cost and how far the system has moved.
01
A platform, not a plug-in
Reforge ships as a server that runs inside your network: GPUs, models, agent runtime, operator console and reporting in one appliance. Your code never leaves the building.
DeploymentOn-premises applianceRack server, air-gap ready
ComputeGPU-served modelsOpen-weight models on local GPUs, or a licensed endpoint you already hold
AgentsMulti-agent, skill-basedOrchestrator plus specialised agents in sandboxed workspaces
ControlOperators in the loopApprove, redirect, hand off — with roles and an audit trail
ScopeLanguage agnosticAny source stack, a target architecture fitted to it
ReportingPer task, week and monthCost, throughput, quality, modernization stage
02
How it works
-
01
Add your projects
Register one repository or many — a monolith and its satellites, or every service in a domain. Reforge indexes them together, so cross-repository dependencies are visible from the first day.
-
02
Scan and map
Agents build a map of the code: modules, call graphs, data access, integration points, dead branches and hotspots. From the map come a draft plan and the list of skills the agents will need for this particular codebase.
-
03
Answer its questions
Where the code is ambiguous, the platform asks. Which downstream system still reads this table? Is this flag ever set in production? Each answer sharpens its model of your system, and the plan and later work get smarter with it.
-
04
Brief it on your process
Before any change is made, you train the platform on how you work: branching rules, review gates, change windows, coding standards, the parts that must never be touched. Agents then operate inside those rules, and operators can tighten them at any time.
-
05
Approve the plan
The plan is phased — safety net first, then runtime, boundaries, data and delivery — with a target architecture proposed for your codebase, not copied from a template. Your architects decide; the plan is versioned.
-
06
Execute with operators in the loop
Agents pick up tasks; operators watch, approve and redirect. Each finished task records what changed, which tests ran, what it cost in tokens and GPU time, and how the modernization stage moved.
-
07
Report
Everything is kept in a form you can report on — per task, per week, per month. Cost, throughput, quality signals and progress, for the engineering team and for the people funding the work.
03
Inside the platform
From a scan to a plan you can argue with
A module map ranked by risk, the skills generated for this codebase, and a phased plan with a proposed target architecture — all produced before a single line is changed.
It asks before it assumes
Ambiguities become questions with context and consequences attached. Answers feed back into the plan immediately, and the understanding meters show where the model of your system is still thin.
Every task on the record
What was done, by which agent, with what result, at what cost in tokens and GPU minutes — and how much the modernization stage moved. Rolled up weekly and monthly, exported as PDF or CSV.
The hardware is part of the product
GPU utilisation, loaded model profiles, serving latency, queue depth and the policies that govern the agents — concurrency, approvals, sandboxing, change windows, retention — all administered from the same console.
04
What is in the box
GPU inference
Open-weight code models served on local GPUs — tensor-parallel, quantised, with model profiles per task type. Optionally route to a licensed API you already hold, under egress control.
Agent runtime
An orchestrator, specialised agents, a skills library generated per codebase, and an isolated sandbox for every task. Tool permissions are explicit and logged.
Operator console
Roles for leads, reviewers and observers. Approval queues, hand-offs between shifts, and a full audit trail of who decided what and why.
Observability
GPU, CPU and memory, tokens per second, queue depth, cost per task — exported to Prometheus and syslog so it fits the monitoring you already run.
Integrations
GitHub Enterprise, GitLab, Bitbucket and Azure DevOps. Issue trackers and CI. SSO over OIDC or SAML, LDAP groups mapped to roles.
Reference configurations
| PilotOne repository, one team | TeamA product line | EnterprisePortfolio-wide | |
|---|---|---|---|
| GPUs | 2 × 48 GB | 4 × 80 GB | 8 × 80 GB per nodemulti-node |
| Agents | Up to 8 concurrent | Up to 32 concurrent | 100 and above |
| Repositories | 1 – 5 | Up to 50 | Unlimited |
| Operators | 2 seats | 10 seats | UnlimitedSSO, LDAP roles |
| Models | 1 code model + embeddings | 2 code profiles + embeddings + reranker | Custom profilesfine-tuned adapters on your code |
| Storage | 4 TB NVMe | 16 TB NVMe | Scale-out |
| Network | 10 GbE | 25 GbE | 25 / 100 GbE |
| Egress | Optional | Optional | Air-gapped by default |
Sizing is confirmed with you during the assessment. Existing GPU hardware can be used where it meets the profile requirements.
05
What gets recorded
Per task
- Change summarymodules and files touched, diff, linked plan item
- Verificationtests written, tests run, pass and fail counts, CI result
- Costtokens by model profile, GPU minutes, external API spend, configured rate
- Timewall-clock, queue wait, operator wait
- Decisionswhich operator approved, sent back or redirected, and the note they left
- Modernization stage deltahow much the weighted plan completion moved
Per week and month
- Throughputtasks completed, tests added, lines retired
- Cost trendtotal, per task, per phase, forecast to completion
- Quality signalssend-back rate, defects found by characterization tests, build health
- Stage progressper project and per phase, against the approved plan
- Open questions and blockerswho they are waiting on, how many tasks they hold
- DistributionPDF for stakeholders, CSV for finance, webhook for your own dashboards
06
Any source. A sound destination.
The platform reads the code it is given and proposes an architecture that fits it — then keeps the work honest to that decision.
Reforge is not tied to a language, framework or era. The scan works from structure and behaviour, so the same process applies to a COBOL batch estate, a Java 6 monolith or a PHP 5 application that grew for fifteen years.
Target architectures are proposed, not imposed: a modular monolith where boundaries are still forming, services where domains are already clear, event-driven integration where systems must keep talking during the transition. Your architects approve the direction; agents work within it and flag every deviation.
Sources we have modernized from
COBOL · RPGPL/SQL · Oracle FormsJava 6 – 8 · Struts · EJB
.NET Framework · WebFormsVB6 · DelphiPHP 5 · classic ASP
Python 2 · PerljQuery front-endsStored-procedure business logic
Towards
Modular monolithDomain-aligned servicesHexagonal layering
Event-driven integrationCurrent runtimes · LTSContainers · CI/CD
Characterization test suitesObservable by default
07
How we start
Step 1
Assessment
We scan a representative repository together, review the generated map, plan and questions, and size the appliance for your portfolio.
2 weeks · on your hardware or ours
Step 2
Pilot
One repository, your operators, our engineers alongside. Phase 1 and 2 of the plan delivered, with the first weekly reports in your hands.
6 – 10 weeks · installed on-premises
Step 3
Rollout
More repositories, more operators, tighter policies. We stay on for support, model updates and the moments where an architect’s eye is needed.
Ongoing · support agreement
08
Talk to us
Tell us which system keeps you up at night. We will scan it with you and show what the plan looks like.
[email protected]