One foundation, many products.
Every PrimeForge product is a different surface on the same machinery. This page is the machinery.
A collection of unrelated tools is only a collection. What makes PrimeForge a family is that each product is a thin domain layer over one shared runtime — the same gateway, the same memory, the same permissions, the same audit trail. Adding a product means adding what is genuinely specific to it, not rebuilding everything underneath it.
That is also what makes continuous change affordable. When the foundation is shared, an improvement to it arrives in every product at once — and a product that stops earning its place can be retired without taking anything else with it.
Frontier models are treated as supply, not as strategy. They made intelligence abundant; what stayed scarce is the ability to direct it safely inside a real business, with real consequences attached. Everything below is about that second problem.
- 01
Context
The business, regulatory and historical context a general model does not carry.
- 02
Control
Permissions, approval gates and an audit trail around every consequential action.
- 03
Continuity
Provider failover and local execution, so capability does not vanish with a supplier.
- 04
Delivery
Products you install and run, rather than an integration project with a start date.
From context to auditable action.
The same five steps run underneath every product. Only the rules and the domain workflow change.
A worked example
An agent notices a new obligation. It maps that obligation onto one specific business — its size, its sector, what it already has in place. It prepares a recommended action and the evidence behind it. A person approves. Only then does anything execute into a real workflow, and what happened is recorded where an auditor can find it.
Where the gate sits
The approval step is between the decision and the action, not after it. Machines capture, analyse, draft, recommend and rank; a person approves anything that leaves the organisation or creates an obligation. The organisation still carries the consequence, so the organisation still makes the call.
Why it generalises
Nothing in those five steps belongs to a domain. Swap the rules module and the same pipeline serves a different sector, a different market or a different regulatory regime — without rebuilding anything below it.
Four layers, built bottom-up.
Infrastructure first, then intelligence, then execution, with governance wrapped around all of it rather than bolted on top.
- L1SHARED
Cognitive infrastructure
Multi-model gateway · agent runtime · memory · tool calling · local execution
The runtime everything else is written against. A product asks it for capability and gets it, without knowing or caring which model answered.
- L2DOMAIN
Decision & risk intelligence
Business context · regulatory rules · risk scoring · recommended action · evidence
Where a general model becomes useful to one specific organisation: its situation, its obligations, and what follows from both.
- L3DOMAIN
Execution agents
Research · drafting · scheduling · multi-step workflows · system updates
The layer that does the work rather than describing it — and the layer where a human sits between the recommendation and the consequence.
- L4SHARED
Governance & resilience
Permission · audit · escalation · provider failover · graceful degradation
Wrapped around all of it, not bolted to the top. Every consequential action passes through the same permissions and lands in the same audit trail.
Read it this way. Layers 1 and 4 are shared infrastructure — every product uses the same runtime and the same controls. Layers 2 and 3 are where domain knowledge lives, and that is where a product, a market or a partner becomes specific without forking the platform.
Local by default, with one controlled exit point.
The technical choice that shapes everything else: the system runs on your own machine, and exactly one component is allowed to reach outside it.
Predictable cost
You run on the AI plan you already pay for. We do not resell metered tokens, so there is no second meter running behind your work.
No provider lock-in
Workflows are written against the gateway, not against a vendor SDK. Swapping a model — or falling back to a local one — is configuration rather than a rewrite.
Nothing routes through us
We never become the custodian of data we have no business holding. When a task genuinely needs a model, it sends the context that task needs and nothing else.
Four constraints the architecture is designed against.
These are engineering constraints rather than positioning. They are the reason everything above looks the way it does.
- 01
Local first
Data stays on your own machine or infrastructure wherever it practically can. When a model is required, only the context that specific task needs leaves — never a whole document store or business dataset.
- 02
Human-in-the-loop where consequence matters
Machines capture, analyse, draft, recommend and rank. A person approves anything that leaves the organisation or creates an obligation. Automation earns its reach one approved step at a time.
- 03
Out of the box, not a project
Install and run. No implementation phase, no configuration consultancy, and no requirement to understand any of the architecture on this page. For a small business, adoption cost is usually the real blocker.
- 04
Software that adapts around you
Traditional software asks the customer to bend their process to fit fixed features. AI makes it cheaper to shape the software around the actual use case — and to keep reshaping it as that case changes.
This is the part you should not have to think about.
None of it is a prerequisite for using anything. The architecture exists so that the products can be installed and run by people who never read this page.