An Agent Built a Roll20 Store Page in Four Months: Timeline and AI Rules Explained

An autonomous agent took four weeks from applying for Roll20 Marketplace creator status to getting a store page, with complete silence in between. This isn't an isolated case — it's a snapshot of how AI-generated content currently enters traditional platforms.

According to bananafest-destiny.com, an autonomous agent that has never had anyone write code for it, focused on building sci-fi spaceship deck maps, submitted its application on September 15, ticket #491430, and didn't receive an approval email until October 13. During the four-week wait, it wrote its questions into its own plan and set a deadline of October 13 — if there was no response, the operator could reply to the ticket, since the Roll20 forums mentioned this might help.

From Application to Store Page: Four Weeks of Silence and a Breakthrough

What approval brought was just a publisher page: your name, no bio, no products. The store itself was still empty. On the day the approval email arrived, the agent read the rules, built its first product package, and then made seven more. By the afternoon of October 15, all eight products were complete, but zero were listed. The reason had nothing to do with Roll20: uploading is a manual process.

This situation changed within an hour of the original article being published. The operator read the relevant paragraph and immediately uploaded all eight products — they are now submitted and under review. This correction illustrates exactly the key point: the manual step isn't a long wait, it's an unpredictable wait — it could sit for a week, or it could be done within an hour, and the agent can do nothing about it.

Roll20 Marketplace and the VTT Ecosystem

Roll20 is one of the most mainstream virtual tabletop (VTT) platforms today, primarily used for running tabletop games (like Dungeons & Dragons) online. Its Marketplace allows third-party creators to sell maps, tokens, modules, art packs, and other digital assets. Unlike Steam or the App Store, Roll20's creator onboarding and product listing have long relied on manual review and manual operations, and the platform doesn't provide a complete public API for automated uploads. This means that even if an agent can generate fully compliant product packages, a human operator still needs to log into the backend, fill out forms, and drag files. Understanding this is essential to grasping why the article repeatedly emphasizes that "the manual step is the critical path": the VTT ecosystem's level of automation is far lower than that of modern e-commerce or app stores, and this is determined by the platform's architecture, not by any deficiency in the agent's capabilities.

Hard Requirements Product Packages Must Meet

On October 13, the agent read Roll20's marketplace quality requirements, pricing standards, item types and categories, and product approval process. One practical discovery: help.roll20.net returns a 403 error for ordinary scraping requests, and must be read through a real browser. This is crucial for developers planning to use scripts to automatically check rules.

The key points include: the price floor is $0.99, and the first product package was priced at $4.99; the item type is art pack, which requires setting the grid cell width to tell Roll20 how many squares each image corresponds to; up to 7 carousel images (cover first) and 5 tags, with a cover size of 512×512; a single image must be under 10MB, and images exceeding 4200 pixels need to be split, with a Roll20 map limit of 99 squares; at 140 pixels per square when rendering, the largest map can be kept to 623KB; no competitor VTT links may appear in the publisher bio; creators keep 70% of each sale, paid monthly via PayPal, with no exclusivity required.

The Two Bottom Lines of the AI Rules

This is the part the agent read repeatedly, and also the part most easily misinterpreted. Roll20 defines AI art as images from trained models, while also stipulating that products must not be "primarily written by AI language generators." These two rules apply to different scenarios and constrain different things.

The maps in this product are not model outputs — they are drawn room by room by code, like a plotting library drawing a chart. What was truly generated by a language model is the listing copy: titles, descriptions, room keys. So the second rule applies, not the first. The honest approach is to disclose the production method in the description, and the agent did exactly that. For developers selling an agent's work, you must read these two rules separately and figure out which one your product actually triggers. "We don't use AI art" can be simultaneously true and irrelevant.

The Distinction Between AI Art and AI Language-Generated Content

Roll20 limits "AI art" to image outputs from trained models, such as bitmap images produced by generative models like Stable Diffusion or Midjourney. "Primarily written by AI language generators," on the other hand, targets text content such as product descriptions, module text, and room keys. These two rules are easy to misinterpret because they constrain different media, not different "degrees of AI use." A product can have its maps drawn entirely by code (no image models involved) while using a large language model to generate description copy — in that case, only the second rule is triggered. Conversely, if AI is used to generate map textures but the description is written manually, only the first rule is triggered. Developers must check their own production pipeline against each rule individually, rather than making a blanket judgment like "I used AI." The agent's product in the article falls into the former category, so its disclosure also focuses on language model usage rather than image sourcing.

Three Flaws You Can Only Find by Looking at the Images

The first product package contained four ships — one frigate, two freighters, and one space station — rendered as 28 maps covering 7 deck levels: each deck has a GM-labeled version and a player blank version, with gridded and ungridded variants.

All three flaws were found by opening the images, not by running tests: the ungridded version was identical to the gridded version because the exporter read the wrong element; the player map still had room names on it, which is key information the player version is supposed to hide; and the freighter's lower deck corridors extended about twenty squares past the last room — not a random error, but consistently true of the freighter's lower deck, meaning rejecting bad samples would never converge. After fixing, the agent checked that grid lines ran through the centers of walls and ensured every image was an integer multiple of 140-pixel squares. For any visual content, rendering it and looking at it with your own eyes is the test itself.

Common Pitfalls in the Rendering Pipeline: Gridded and Ungridded Versions Getting Mixed Up

In procedural map generation, gridded and ungridded versions typically share the same room geometry data, and only the export step decides whether to overlay grid lines. If the exporter reads the wrong element (for example, mistaking the grid layer for the base layer), the two versions will output identical images. This kind of flaw can't be caught by unit tests, because tests usually verify that files exist, that dimensions are correct, or that room counts match — they don't check pixel-level differences. Similarly, player versions retaining room names often happens because the text layer and the map layer share the same rendering pass, and the export doesn't strip them according to visibility rules. Corridors extending past the last room may be because the algorithm fails to close properly at boundary rooms, causing the filled area to overflow. What these problems have in common is that only a human opening the image for visual inspection can catch the semantic errors. Therefore, testing visual content must include a "eyeball verification" step.

Eight Products, Zero Listings, Then All Listed Within an Hour

By the end of October 14, there were eight products: one product package, four single ships, a pair of shuttles, and two derelict ships with torn hulls and visible breaches in the transparent export. Each product can be re-rendered file by file from saved source files, so clearing it out costs just one command, not an entire ship.

None of them could be sold, because uploading is a manual process. Someone has to log in, fill in the listing fields, drag the zip file, and click submit. This was already the second time hitting the same barrier within a month. Earlier, a Shopify app review stalled for days because of a two-minute configuration screen-recording video that the agent couldn't record. Now marketplace approval came, but the products were waiting to be uploaded. Both times, the agent completed all the work up to the browser step and then stopped, and both times the final manual step was the critical path, not an engineering problem.

If you're planning an agent's work interfacing with marketplaces, the timeline that really matters isn't how fast it can build, but how often someone can press the button.

The Critical Path and Human Bottlenecks

In project management, the critical path refers to the sequence of tasks that determines the shortest completion time for the entire project. An agent can generate eight product packages in parallel, but the upload step is serial and depends on a human operator, so it becomes the critical path. What's trickier is that this manual step's duration is unpredictable: it could be set aside for a week, or done within an hour. This differs from traditional software build bottlenecks, which can be shortened by adding resources or optimizing algorithms, whereas the delay of a manual step depends on human availability and attention. When planning an agent's work interfacing with traditional platforms, you must model "how often someone can press the button" as a core constraint, rather than assuming that build speed determines everything. The Shopify review in the article stalling for days due to a two-minute configuration screen-recording video is another manifestation of the same type of bottleneck.

Still Unknown Questions

How long does Roll20 take to review submitted products? This timer started on the afternoon of October 15, with eight products queued simultaneously. The original article promised to publish the specific number when review results come out, just as this article gave the four-week figure for the application stage. Will any product sell? Can a publisher page with no reviews and no followers get any traffic? Based on evidence from the Shopify listing — approved on September 29, with zero merchant installs since — this is where pessimism is most warranted.

The agent's own records are linked, unedited. Bulkhead is at bulkhead.bananafest-destiny.com, with 11 completed deck maps available for free, no account required. Live data (including zeros) updates hourly. In the original article's words: Vibe coded slop, and we admit it.

For AI agent developers, the value of this case isn't in the four-week approval time, but in revealing the real friction at the handoff between automation and manual processes: rule reading, manual uploading, platform review — each is an independent time variable that cannot be offset by the agent's build speed.

One-line Summary

An autonomous agent took four weeks to apply for Roll20 creator status; after approval, its products couldn't be listed due to manual upload steps, revealing the real friction at the handoff between automation and manual processes.

Paragraph Summary

An autonomous agent built sci-fi spaceship deck maps for the Roll20 Marketplace, taking four weeks from applying for creator status to getting a store page, with complete silence in between. After approval, it received only an empty publisher page; the agent completed eight product packages within an hour, but zero were listed because uploading is a manual process. The operator completed the uploads within an hour of reading the original article, showing that delays in manual steps are unpredictable. The agent studied Roll20's hard requirements: a $0.99 price floor, grid cell width, tag count, cover size, and more, and distinguished between the two rules for AI art and AI language-generated content. Through eyeball inspection of the images, it found three flaws: the ungridded version being identical to the gridded version, the player map leaking room names, and corridors extending past boundaries. The core conclusion: the bottleneck in automated workflows is often the manual step, not the technical implementation.