The Framework Compatibility Problem
Most FiveM scripts ship with one framework hard-coded in. If you run QBCore, you use QBCore scripts. ESX users are stuck with ESX scripts. Standalone users mostly hack things together. Agency Scripts were built with the opposite philosophy: the framework is an adapter, not an assumption.
The Adapter Pattern
Every Agency script exposes a small set of lookup functions: getPlayerData, getInventory, addMoney, removeItem, getJob. We ship adapters that map these to QBCore and ESX implementations out of the box. For standalone, you implement the four or five functions yourself — typically a morning's work — and every Agency script is compatible.
What This Means in Practice
When you switch your server from QBCore to ESX (which does happen every few years as frameworks evolve), Agency scripts don't need to be reinstalled or reconfigured. You swap the adapter, everything else keeps working. This is incredibly rare in the FiveM ecosystem and it's the main reason server owners standardize on our tooling for the long haul.
Which Framework Label on Our Product Pages Means What
When a product page lists "QBCore, ESX" it means we ship ready-made adapters for both. When it says "Standalone" we mean the script is framework-agnostic — it needs no adapter and runs on any server. In practice almost every Agency script is usable on standalone setups with a small compatibility shim.
When to Ask Before Buying
If you run an unusual setup — custom framework, heavily modified QBCore, or something bespoke — open a ticket on our Discord before buying. We'll tell you honestly what will work, what needs light adaptation, and what isn't worth the trouble. No sales pressure; we'd rather you buy one script that fits than three that don't.
How the Adapter Pattern Works in Practice
When you install an Agency script, the resource folder contains a framework subdirectory with at least three files: qb.lua, esx.lua, and standalone.lua. The main script auto-detects which framework is present by checking for the QBCore or ESX export. The matching adapter file loads; the others don't. This auto-detection happens before any gameplay logic runs — there's no runtime overhead from framework detection.
Each adapter implements the same internal API surface. If a script needs to give a player money, it calls Framework.AddMoney(src, amount) internally. That function in qb.lua calls QBCore's money export; in esx.lua it calls ESX's account system; in standalone.lua it calls whatever function you've defined in config.lua. One call, three implementations, zero script changes between frameworks.
Installation on QBCore
For QBCore servers, installation is typically three steps: download the resource, drop it in the resources folder, and add it to server.cfg. Framework detection is automatic. If you use a significantly modified QBCore (custom money system, custom inventory, custom jobs), you may need to override specific adapter functions in config.lua rather than editing qb.lua directly. The config override approach means you won't lose your changes on resource updates.
Installation on ESX
ESX installation follows the same pattern. One additional step that's occasionally needed: if your ESX version is significantly older (pre-1.7), some adapter functions reference newer ESX export names. The resource ships with a legacy compatibility flag Config.ESXLegacy = true that switches to older ESX API calls across all Agency scripts that need it.
Installation on Standalone
Standalone is where most server owners have historically hit friction with other scripts. Agency Scripts' standalone path is explicit and well-documented. For each script, the standalone adapter file lists exactly which functions you need to implement. Most scripts need between four and eight functions. Each function has a comment explaining what it should return. A typical standalone implementation takes one to three hours depending on how complex your custom player data system is.
Once you've implemented the adapter for one Agency script, subsequent scripts take far less time — the same custom functions often apply across multiple resources.
Why This Matters for Long-Term Server Operation
FiveM frameworks are not permanent. Servers that have operated for three or more years have likely already navigated at least one major framework consideration — perhaps migrating from a community ESX fork to mainline ESX, or from an older QBCore to the current version. Servers that rely on framework-coupled scripts pay a high migration tax: every script needs updating or replacement when the framework changes significantly.
Agency Scripts' adapter architecture means that a framework migration affects only the adapter layer. Your Agency-Phone data, Agency-Admin logs, Agency-Blackmarket transaction history, and player progression in Agency-Minerjob all survive intact. You swap the adapter files, update config.lua, and the scripts keep working. This is the actual long-term value of the compatibility approach — not just supporting multiple frameworks, but insulating your server from framework evolution.
Frequently Asked Questions
Do all Agency scripts use the same adapter pattern?
Yes. Every paid Agency script and most free ones use this pattern. The only exceptions are purely UI resources like Agency-Loadingscreen and Agency-Notify, which have no framework interaction at all and work identically everywhere.
Can I mix framework adapters? For example, use QBCore money but standalone inventory?
Yes, through config overrides. Set your framework detection to QBCore, then override specific adapter functions in config.lua to call your custom inventory system instead of QBCore's. The override system exists precisely for servers with hybrid setups.
What if a new framework becomes popular and isn't supported yet?
Open a support ticket on Discord. We evaluate new framework support requests based on community adoption. For frameworks with significant communities we've added support within 2-4 weeks historically. In the meantime, the standalone adapter path works for any framework as a stopgap.
Are framework adapters updated when the framework itself updates?
Yes. When QBCore or ESX releases a breaking change, we push adapter updates within days of the framework release. Active subscribers receive update notifications through Tebex. This is part of why the subscription model exists — adapter maintenance is ongoing work, not a one-time cost.
Requirements Summary Per Framework
- QBCore — any recent QBCore version. Auto-detected, zero configuration for standard setups.
- ESX — ESX Legacy 1.7+ or mainline ESX. Set legacy flag for older versions.
- Standalone — implement 4-8 functions per script in config.lua. One-time setup, reusable across Agency scripts.
- All setups — cfx.re account with valid license, FiveM server with Artifacts 5181 or higher recommended.