The AI artifact was useful. Then someone wanted to keep using it.

A calculator comes out of an agent session. Someone sends the link to a colleague. The colleague wants to change one assumption, save a scenario, and come back next week.

At that point, there are some ordinary app decisions to make. Where does the current version live? Are changes saved only in this browser? Who can see the saved data? Can you update the calculation without immediately changing the page everyone uses?

drobek gives these small browser apps a place to run.

I previously wrote about using a Claude Artifact as a changing team document. The value in that example was a link colleagues could return to as the work changed. Here I want to look at a browser artifact that needs app behavior: inputs, saved records, and controlled updates.

Keep the first version small

Take a simple planning calculator. It estimates how many working days a task needs from a total number of hours and the hours available each day.

For the example, 24 hours at 6 hours per day is 4 days. Those are illustrative inputs, not measurements from a project. The calculation is small enough to check while we work on the app around it.

The first version can stay entirely in the browser:

function estimateDays(totalHours, hoursPerDay) {
  if (!Number.isFinite(totalHours) || totalHours < 0) {
    throw new Error('Enter a non-negative number of hours.');
  }
  if (!Number.isFinite(hoursPerDay) || hoursPerDay <= 0) {
    throw new Error('Hours per day must be greater than zero.');
  }
  return totalHours / hoursPerDay;
}

That is an arithmetic estimate, not a project forecast. It doesn't model weekends, dependencies, or people getting interrupted. The page should say what the number means instead of displaying it with more confidence than the inputs justify.

If the artifact already has usable HTML or React source, give that source to your coding agent and ask it to adapt the app for drobek. Don't assume an artifact share URL is an import format or that platform-specific features transfer unchanged.

A bounded request helps:

Adapt this calculator's source for drobek.
Preserve the calculation and input validation.
Remove dependencies on the original artifact environment.
Keep all data in the browser for this first version.
Return the preview URL and explain any behavior you changed.

The agent can create the app, write the files, and work from compilation feedback. You still try the actual page. A build can succeed while a text input, error message, or calculation is wrong.

Add persistence when there is something worth saving

If people only need a quick calculation, stop there. A saved-record feature adds access decisions as well as convenience.

For private saved scenarios, one possible design is to add the auth and data modules. A signed-in user creates a scenario and can later retrieve their own records. The data collection rules can be:

{
  "read": "owner|admin",
  "create": "user",
  "update": "owner|admin",
  "delete": "owner|admin"
}

This is the rules object for a configured collection, not the complete module configuration. Here, owner refers to the record owner. admin also has access, so describe that honestly if the interface calls scenarios private.

In the frontend, after the collection and authentication are configured, saving the example could use:

import { drobek } from 'drobek';

await drobek.data.collection('scenarios').create({
  name: 'Example estimate',
  totalHours: 24,
  hoursPerDay: 6
});

Use a schema for the stored fields and validate the inputs on the page too. The data module applies its operation rules on the server. Keeping records out of the rendered list is not access control.

If the next request is shared team scenarios, reconsider those rules. Making every signed-in user a reader is a different product decision from letting each person see their own records. An agent should explain that change before it is confirmed.

Treat updates as versions

Suppose the next change adds a maximum daily capacity or another output. The agent writes a new version, you inspect the preview, and then choose whether to publish it.

The production URL can continue serving the earlier published code while you work. If the new code is wrong, publishing an older version restores that code.

But the app's records are shared between preview and production. A preview test that edits real saved scenarios edits real data. Code rollback doesn't undo those writes. Use a separate app when you need an isolated data experiment.

For images or other binary assets, drobek has a separate asset-upload flow. They do not belong in write_files as a giant base64 string. Review which assets the original artifact depended on and provide replacements where necessary.

A maintained app still needs an owner

Hosting the result doesn't make the model's original analysis correct. If an artifact contains an estimate, a recommendation, or a data-derived conclusion, keep its assumptions and source dates visible. Update the evidence as well as the UI.

And some artifacts should remain documents. If the main job is preserving a decision and its reasoning, a repository or document system may be the better home. The calculator example earns an app because people interact with it and may need persistent state.

In drobek, the agent's edits compile into a preview you can check before changing the production URL colleagues use. You can start with a browser-only tool and add a backend module when a specific need appears. The gallery shows the scale of apps I have in mind, and the core is open source.