Fractal AI: the distributed computing and storage layer for Enterprise AI applications
Language models are good at understanding what people want and at explaining results. They are slow, costly and non-deterministic when asked to process an enterprise's data. In Fractal's architecture the model does only the first and last steps. Fractal does the heavy lifting in between: it stores a digital twin of the systems of record and runs the work in parallel across many small instances on commodity hardware.
Overview
The architecture
The user talks to the AI language model. The model writes a Fractal App, which the Fractal mesh runs in parallel against its local copy of the enterprise's data. The results go back to the model, which summarizes them for the user.
- Fractal replicates data from the systems of record into a digital twin.Data flows from source to twin only. There is no return path, so nothing an Application does can reach a system of record that way.
- The twin is a live, full-fidelity replica.It is continuously synchronized: not a backup, snapshot or stale staging copy.
- Each Fractal instance holds one shard of the twin.Every instance is the same small, self-contained stack. The data is spread across the mesh, not concentrated in one database.
- The language model writes a Fractal App, and every instance runs it in parallel.The user states what they want in plain language, for example: "Which customers were overbilled last quarter, and by how much?" The App is a small program that works on one data shard, inside a bounded context.
- The results go back to the language model.A compact, structured answer, not the underlying data. The model summarizes and presents it to the user as an executive summary they can act on.
The model
AI at the beginning and end of the workflow
Language models are good at two things this architecture needs: understanding loosely stated requests, and explaining structured results in plain language. Fractal uses them for exactly those two steps and nothing else.
- 1The user states what they want in plain language, inside an Enterprise Application. For example: "Which customers were overbilled last quarter, and by how much?"
- 2The language model writes a Fractal App. The App is a small program that works on one data shard, inside a bounded context.
- 3The App is sent to the Fractal Computing mesh and deployed to every Fractal instance.
- 4Every instance runs the App in parallel against its own local shard of the digital twin. The results are aggregated.
- 5The results go back to the language model: a compact, structured answer, not the underlying data.
- 6The model summarizes and presents the result to the user as an executive summary they can act on.
At the beginning: capturing intent
- The user doesn't need to know a query language, a schema or a report menu. They describe what they want.
- The model maps that intent onto the enterprise's data structures and the domain context libraries, and writes a Fractal App.
- New questions don't need a new development project. The model writes a new Fractal App.
At the end: a human-consumable view
- The App returns structured results such as totals, exceptions, rankings or forecasts.
- The model turns them into an executive summary: what was found, what it means, and what to look at next.
- Because the summary is built from the App's deterministic output, every figure in it can be traced back to the computation that produced it.
The model never touches the data directly. It sees the user's request, the App it wrote, and the App's results. It does not read millions of records, and it never has credentials to the systems of record.
Business case Your data stays yours →
The data
Fractal does the heavy lifting, on a digital twin
All of the application's actual work, including storing the data, processing it and producing results, happens in the Fractal Computing mesh. The mesh works on a digital twin of the systems of record, never on the systems of record themselves.
- A live digital twinFractal replicates data from the systems of record into the Fractal instances. The twin is a continuously synchronized, full-fidelity replica, not a backup, snapshot or stale staging copy.
- One-way syncData flows from source to twin only. There is no return path through the sync channel, so nothing an Application does can reach a system of record that way.
- Source systems cannot be corruptedHallucinations, prompt injection, cascading agent errors and model drift are contained in the twin. Fractal reports zero source-system corruption events across its production deployments.
- Controlled promotionWhen a result should change a system of record, it goes back only through an explicit, logged, human-approved promotion step that sits outside the AI loop.
- Distributed storageEach Fractal instance holds a discrete shard of the twin in its own multi-model database (relational, document, time-series, graph, vector). The data is spread across the mesh, not concentrated in one database server.
- Distributed computingA MapReduce-style middleware runs the App on all instances at once and combines their results. Instances coordinate peer-to-peer over HTTPS, with no central broker and no single point of failure.
Business case AI without risk to your systems → Hot backup at a tenth of the cost →
The instances
Scale invariance and Deterministic AI
Fractal's architecture is scale invariant. Every Fractal instance is the same small, self-contained stack: application code, middleware, web server, shard and partition manager, database scheme library, multi-model database and stream processor. Scale comes only from the number of instances, from one on a smartphone to 1,000+ on a large server. An Application written for one instance runs unchanged on all of them.
The building block is the Fractal: a small, self-contained, vertically integrated software stack that runs as an independent processing unit in a loosely coupled distributed system. It keeps only the essential 0.1% of the conventional enterprise software ecosystem. Each instance carries a complete copy of the application logic, so it runs autonomously. Instances talk to each other over a peer-to-peer HTTPS mesh with no central coordinator and no shared-memory bottleneck.
| Layer | Function | Role when AI writes the App |
|---|---|---|
| Application Code | Small, focused modules that use context libraries for domain-specific heavy lifting | Where the AI-written Application plugs in. The plug-in is a thin module, not a whole application. |
| GUI Widgets | Front-end interface components | Ready-made components for showing results in the Enterprise Application |
| Distributed Processing Middleware | MapReduce variant for parallel computation across Fractal instances | Runs the Application on every instance at once and combines the results |
| Web Server | HTTPS peer-to-peer communication between Fractals | Instances coordinate without a central broker |
| Shard & Partition Manager | Granular, explicit, developer-controlled data distribution | Each instance gets its own shard, so the Application never has to fetch remote data |
| Database Scheme Library | Domain-specific context, stored procedures and co-located application logic | Business knowledge (rates, billing logic, account hierarchies) the Application calls instead of rebuilding |
| Multi-model Database Engine | Relational, document, time-series, graph and vector data in one engine | The Application queries every kind of data in one place, with no cross-system joins |
| Memory Manager / Stream Processor | Pipelined data movement from persistent storage to CPU registers | Data is cache-resident before the Application needs it, so the Application never waits on I/O |
The whole stack is written in JavaScript and is identical on every platform, so an Application is written once and deployed anywhere. Typical instance counts are 1 on a smartphone, 1–10 on a tablet, 10–20 on a desktop PC, 100–400 on a small server such as a Mac mini or Intel NUC clone, and 1,000+ on a large server.
Why AI can write Fractal Apps reliably
- Bounded, contained context. An App works on one shard. Through Locality of Logic, each stored procedure needs to know only its local scheme, or at most one or two adjacent schemes.
- Small surface. A Fractal App has fewer than 10 encapsulation boundaries, compared with hundreds of interacting tables in a legacy application. That is a context a language model can hold and get right.
- Domain context libraries. Business logic such as rate structures, billing rules and account hierarchies is already encoded in libraries. The App calls them instead of reinventing them.
- Safe to try. The App runs on the twin, so a wrong App costs a rerun, not a corrupted system of record.
Why the result is deterministic
- The model's non-determinism is confined to writing the App. Once written, the App is ordinary code: the same input gives the same output, every time.
- The App can be inspected, tested on a sample shard, versioned, reused and audited like any other enterprise software.
- The scale is massive but the logic is local, so an App that is correct on one shard is correct on every shard.
- The summary is built from the App's output, so it can be checked against the numbers.
Deterministic AI: the flexibility of a language model for capturing intent, combined with the repeatable, auditable behavior of enterprise software for doing the work.
Business case AI you can rely on → Runs where you need it →
Speed
Locality of Reference: fast on commodity hardware
Conventional enterprise software spends most of its time waiting on I/O. Each abstraction boundary (application, ORM, connection pool, network stack, database server, storage engine, disk) adds roughly 10 I/O wait states per useful instruction cycle. With seven boundaries, software runs about 107 below what the hardware can do. Fractal's Locality Optimization™ removes that waste.
How it works
- Locality of Reference: data is sharded when the system is built, so each instance works only on data it holds locally. No network requests happen mid-computation.
- A stream processor pipelines data from persistent storage through RAM and L2 cache to CPU registers, so computation doesn't wait for data.
- Because every instance runs at near-hardware speed on its own shard, total throughput grows nearly linearly with the number of instances.
What it means for cost
- Fortune 500-scale workloads run on a shelf of small, inexpensive computers. No data center or cloud dependency is required.
- Reference deployment: 10 Mac mini / NUC clones running 400 Fractal instances serve a 10-million-customer billing application, totaling 3.6 trillion input records.
- The same JavaScript stack runs on any platform, from a phone to a large server.
Figures are Fractal-reported results from Fortune 500 production deployments in utilities, telecommunications and financial services.
Business case ≥ 50% lower cost, ≥ 10× faster →
Runtime, cost, team size, reliability and corruption risk, measured side by side.
Cost
Token costs go from a large expense to an immaterial one
When a language model processes enterprise data itself, token usage grows with the amount of data: every record the model reads costs tokens. In Fractal's architecture the model handles only the request, the App and the results. Token usage then depends on how complex the question is, not on how much data is behind it.
| Step | Model at the center of the work | Fractal architecture |
|---|---|---|
| Capture intent | A short request | A short request |
| Do the work | The model reads and reasons over the records, repeatedly. Token use grows with every record and every rerun. | The model writes one Fractal App, typically a few hundred lines. Fractal runs it over all the records at no token cost. |
| Present results | Summary from whatever fit in the context window | Summary from compact, aggregated Application results |
| Repeat next month | The full cost again | Rerun the same App: no new tokens until the summary step |
| Scaling to more data | Token cost scales with data volume | Token cost stays flat; Fractal adds instances |
Order of magnitude: the reference billing deployment holds 3.6 trillion input records. Even at a few tokens per record, reading that data would cost trillions of tokens. Writing a Fractal App and summarizing its results takes thousands. The language model becomes a small, fixed cost per question, and the data processing runs on about $20K of hardware.
Business case AI token costs become immaterial →
Summary
Most Enterprise AI designs put the language model in the middle of the work. The model reads the data, reasons over it and writes the results. That is expensive, because every record becomes tokens. It is slow, because the model sits on top of the conventional database stack. It is also risky, because a non-deterministic model with write access to production can corrupt millions of records at once.
Fractal changes where the model sits. AI is used only at the beginning and the end of the workflow. At the beginning, the model turns the user's request into a Fractal App: a small, bounded program. At the end, it turns the App's results into an executive summary. Fractal is the distributed computing and storage layer in between. It holds a continuously synchronized digital twin of the systems of record, runs the Application in parallel on every Fractal instance, and returns the results.
The outcome is AI with the flexibility of a language model and the deterministic behavior of enterprise software. The systems of record cannot be corrupted, performance improves by orders of magnitude on inexpensive hardware, and language-model token costs become immaterial.
Business case The decision, in business terms →
Adoption
Getting started: a 90‑day parallel proof of concept
Fractal deployments start with a 90‑day proof of concept that runs alongside existing systems. The systems of record keep running unchanged. The Fractal twin and the AI layer are built in parallel and measured against live production data.
- Days 1–14: provision the twin on commodity hardware, establish one-way sync and verify the replica against production.
- Days 15–60: run AI-generated Fractal Apps against the twin and collect performance, accuracy and cost metrics daily.
- Days 61–90: compare results with the production baseline and make a transition decision based on measured data.
- After day 90: move workloads on the client's timeline. There is no hard cutover; the twin keeps running in parallel as long as needed.
You are not on your own: Fractal's onboarding team guides the twin setup, the AI integration and the deployment. A typical deployment needs one point of contact on your side, not a team of consultants (see the benchmarks).
Business case A safe, controlled migration path → Recommended next step →
See what safe, low-cost AI looks like on your data
A 90-day deployment at production scale, alongside your existing systems. No disruption. Your data. Real numbers.