Polyfork

One traffic cone at two settings. Not scaled: rebuilt, so a third reflective band appears and the triangle count goes 280 to 472.
Density, not length. The span between the posts never changes; the stakes fill it in. 5,774 knobs across the catalogue.
Sixty parts on one 4 m grid and one palette, so any part fits beside any other. 513 of 583 models began inside a kit.
One line typed by a person on 31 July. Gemini drew the reference and an agent wrote the brief. Nothing visual came from the human.
Gemini fixes silhouette and proportion before any geometry exists. Every attempt downstream is graded against this image.
That URL is live and CORS-open right now. 295 of the models sit on the public door with no account needed.
Seven canonical views, then a harness that reports what was actually built rather than what the agent believes it built.
Graded in a fresh session against the kit's own rules. The planner asked for tiled roofs; the first attempt handed in a slab.
Written by the judge agent, not by us. It has sent back roughly two thirds of everything ever submitted to it.
The owner's note, verbatim, on a kei van. Proportion is what a machine reviewer is worst at and a person spots instantly.
Every build writes a lesson. Four in ten come from builds no person ever saw, and every later build reads all of them first.
An agent with a real job, our public API and none of our source code. It files whatever wasted its time, with a replayable request.
One real Monday: the agent proposed four changes, a human approved three and sent one back, and it shipped seventeen minutes later.
First sale on launch day, 1 August 2026, and revenue every week since. Related-party revenue is zero.
Prompt-to-world needs a library that is coherent, parametric and licensed. Every asset here is code an agent can read and import.

Inspiration

Software is increasingly written by agents, and the thing they are moving into next is space. Scenes, configurators, games, worlds you can walk around in, XR. Text first, then interfaces, and now the third dimension.

That shift lands on the web, because agents are web-native. They write HTML and JavaScript, they ship to a URL, and they can look at what came back and iterate on it. Ask an agent to build you a scene and it reaches for the browser, not for a game engine.

Which is awkward, because the browser is where 3D tooling is thinnest. I have been building more and more web 3D with three.js, 2D, 3D and XR, and next to a game engine there is almost no supply chain around it. Finding a 3D asset is easy. Finding one that is the right height, the right density, the right era, in the same visual language as the twelve other things already in your scene, is not.

The reason is that a 3D model is sold as a finished object. Someone else already decided how tall it is. You can scale it, which stretches it and looks wrong, or you can open a modelling tool and fix it yourself, which is the part most web developers do not want to do.

So I started building a library of 3D assets that are not objects but little programs: parametric, AI-native, and customisable in the browser before you download anything.

And the format is the point. An agent's native material is code. Not because it cannot drive a modelling tool, it can, but because a mesh is an opaque binary it can place and not much else, while a module with named parameters is something it can read, diff, change one line of, and rebuild deterministically. Code is AI-native by default. So I made the assets code.

Once a model is code, the last step is the obvious one, and it is the one I think matters most: you stop downloading it and you install it.

And then, halfway through building this, the demand side showed up on its own. On 6 August 2026 Tencent published WorldClaw: type a sentence, get a large explorable 3D world with terrain, regions, materials and placement. Prompt to world. Several labs are working on prompt to game. Read those architectures closely and they all have the same slot in them, the one WorldClaw calls Terrain Asset Prototypes: the reusable objects a world is mostly made of, by count. Right now that slot is filled by running image-to-3D and keeping whatever comes back.

That does not hold, and I wrote up why in full: WorldClaw and the 3D asset supply problem. Objects generated one at a time have no relationship to each other, which is the real reason AI-generated scenes read as an asset flip even when every object in them is fine. A prototype mesh is frozen, so scattering it three hundred times gives you three hundred identical rocks. Regenerating per instance costs GPU time per instance. And generated geometry arrives with no licence, no triangle budget and nobody who checked.

If worlds are going to be built from a prompt, somebody has to supply assets that are AI-native. Coherent as a set, parametric so one asset yields hundreds of variants at no generation cost, machine-readable so a planner can query them, and licensed so the output can ship. None of those are model-capability problems that get solved by the next checkpoint. It is a library-shaped hole in everybody else's architecture, and it happens to be exactly the shape of the thing I had been building for a different reason.

3D models you can change after you buy them

What it does

Polyfork is a store for web 3D where nothing is finished. You pick a traffic cone, a shopfront or a fox, and then you decide how tall it is, how dense, how worn, in the browser, before you download anything. Underneath, each one is a small GLB plus a drop-in ES module that works in three.js and any glTF engine, but the part that matters is the knobs.

The traffic cone above is one model at two settings. It is not being scaled: the geometry is rebuilt, so a third reflective band appears once there is room for one, and the triangle count goes from 280 to 472. Stretching a mesh cannot change its triangle count. That is the whole difference.

Assets are built in kits rather than one at a time, so the parts fit each other: one 4 m grid, one palette, one set of build rules per kit. A shopfront awning fits any facade in the kit because the planner decided every storey is exactly three metres before anything was modelled.

And because it is a program, you can import it. No loader, no download, no texture folder:

import { createAsset } from 'https://polyfork.dev/cdn/traffic-cone-247748.mjs';
scene.add(createAsset({ tallness: 0.9, facets: 16 }));

That URL is live right now, CORS-open and cached at the edge, and 295 of the models are on that public door with no account. Pro opens the same door onto the whole catalogue on a per-account path, which means what a subscription actually buys is not a folder of files but a runtime dependency: models that keep working, keep up with rebuilds, and bake variants on demand. The edge holds a good copy for thirty days, so our outage cannot become a customer's outage.

This is the part I believe is the future of 3D on the web. npm did not make code better, it made code installable, and everything else followed from that. Web 3D never had it, because you cannot install a mesh, you can only download one and hope it fits. A model that is a program can be published, imported, parameterised at the call site, cached and swapped like any other dependency. That is what a package registry is, and it is what Polyfork is turning into.

A 3D model you can import

The store is also built to be used by agents, not just people. There is an /llms.txt, a public REST API, and an MCP server, so an assistant can search the catalogue, read a model's parameters and pull a GLB without a human in the loop. That has turned out to matter: 14,524 API and MCP calls from 29 keys so far.

Polyfork is AI-native in both directions, and that is the part I care about: the catalogue is built by agents, and it is built to be used by them. Both work for the same reason, which is that the unit is a program rather than a file.

Where it is today: 583 published models, 295 of them free, 5 published kits, 5,774 knobs across the catalogue, and a build rate of 175 new models in the last seven days.

How we built it

I am one person. The catalogue is built by a factory of agents that runs unattended, and my job is to supervise it.

Ordering a kit. I write one line. An agent turns it into a production brief, and Gemini draws the reference art from the same line. Nothing visual comes from me.

The entire human design input

Building one part. Every part then runs the same loop:

Gemini writes the brief and the reference art. That is the contract.
A second agent writes the model as code, a module that builds geometry, which is why the output has parameters at all.
It renders its own work through a harness that reports what was actually built, not what the agent believes it built.
A different agent, in a fresh session, grades it against the brief and the kit's own rules.

The judge is not decorative. It has graded over a thousand attempts and sent back roughly two thirds of them.

A different agent grades it, in a fresh session

Google Cloud and Gemini. Gemini generates the briefs, the kit concepts and the reference art. Text generation routes through Vertex AI on Google Cloud, with the AI Studio endpoint kept as a fallback, and a daily liveness check that mails me if Vertex stops serving.

The business runs on the same machinery. Every Monday an agent audits the site for SEO, proposes changes, and ships the ones I approve. On 11 August it proposed four, I approved three and sent one back, and it was live seventeen minutes later. We also send ourselves a customer: an agent with a real mission, our public API, and none of our source code, which files whatever wasted its time along with a request you can replay.

Challenges we ran into

Getting an agent to build geometry that survives being looked at. Early models passed their own checks and were still wrong: surfaces sharing a plane so the depth buffer could not order them, features that vanished from the one camera angle the reviewer would use, detail added where the actual problem was proportion. Fixing this per model does not scale.

Judging is harder than building. The judge agent had to be given the kit's own rules as the standard, and had to run in a fresh session, or it agreed with whatever the builder had just told it.

Knowing what is really true. The most useful thing I built is the harness that measures the finished GLB and contradicts the agent. Nearly every quality problem started as an agent believing its own description of its work.

A revenue trail split across two Stripe accounts when the store moved accounts mid-hackathon, which is exactly the sort of quiet gap that makes numbers look wrong when they are not.

Accomplishments that we're proud of

It is a real business, not a demo. The first sale landed on 1 August, launch day, and there has been revenue every week since: 54 paying customers, a free tier that is more than a third of the catalogue, and 43 of 100 founding lifetime seats sold. Related-party revenue is zero.

A real business, with arms-length customers

The factory improves itself. Every build writes down what it learned. Those lessons are distilled into a shared file that is copied into every future build before the agent opens a single file, so a correction made once is applied to everything built afterwards.

Four in ten of those lessons come from builds no person ever looked at. The system rewrites its own instructions from its own failures, and that is the part that compounds.

The factory rewrites its own instructions

What we learned

Humans are still very important in the loop. The judge agent is a filter, not a gate. I have sent work back 633 times across 349 assets, usually about proportion, which is the thing a machine reviewer is worst at and a person spots instantly.

Ask an agent for a program, not a picture. The single decision that made this work was having the model written as code rather than generated as a mesh. Parameters, diffs, and a rebuild you can re-run all follow from that, and none of them are available if the output is a blob of vertices.

A human note is worth more generalised than applied. When I wrote "car should be a bit lower (move wheels up)", the useful outcome was not the fixed van. It was the agent working out that wheels are pinned to the ground plane, so ride height is really the body's offset, and turning that into a rule and a knob.

Measure, then believe. Anything self-reported by the thing doing the work is a claim, not a fact.

What's next for Polyfork

Scale up: more agents, and more people. More build lanes running in parallel, and the first hires to supervise them. This is the part I did not expect: the factory removes the modelling work, not the judgment. Every finished model still gets looked at by a person, so more output means more people doing the looking, not fewer. Agents made a catalogue this size possible for one person; they are also what makes hiring worth it, because a new person here supervises a lane rather than pushing vertices.
The biggest programmatic 3D archive in existence, and the registry it installs from. 583 models today and growing by 175 a week, every one of them parametric, arriving as kits whose parts fit each other rather than as a pile of unrelated objects. Not the largest pile of meshes: the largest set of 3D assets that arrive as code, which is the format an agent can actually work in. Size is half of it, and the half everyone can count. The other half is the delivery: those models are installable from a URL today, and the goal is to make importing a 3D asset as ordinary as importing a package. A big archive is a catalogue, and a big archive you can import from is infrastructure.
Train on the corpus the factory has been writing all along. Every build keeps its whole session: the brief, each attempt as its own module snapshot, the renders, the judge's verdict and score, the owner's note, and the lesson written afterwards. That is 10.3 GB of transcripts across 604 builds, 1,743 graded passes and 1,591 module snapshots, and unusually it is all labelled, because every attempt already carries a score and a reason it failed. Most 3D data is meshes with no record of what was wrong with them or how it got fixed. This is a paired record of attempt, critique and correction, and it is the obvious thing to fine-tune on next.
Be the library slot for prompt-to-world. The world generators arriving now separate reusable asset prototypes from their placements, which is exactly the boundary a catalogue plugs into. The planner should be able to query a library and generate only what the library genuinely lacks, instead of minting every rock from scratch on every run. Nobody has built that yet. Our catalogue is queryable over an HTTP API and an MCP server today, every asset is a program that yields hundreds of coherent variants at no generation cost, and the licence lets the output ship. That is the whole pitch to a prompt-to-game platform, and it is why the archive and the registry are the same project.
Terrain generators per kit, so a kit ships with the ground it stands on, joinable across kits by arithmetic.
More knobs, better knobs. Every asset that ships with a state axis instead of five near-identical siblings is five fewer things to browse.
Deeper agent surfaces, because the customers who cannot see a screenshot are the ones who benefit most from a model that can be described, queried and reshaped in text.
Keep the factory honest. More self-checks, a stricter judge, and the same rule that has held all along: it runs unattended, and none of it runs unsupervised.