Every 3D project accumulates assets. Models, textures, HDRIs, reference photos, sound effects, simulations, render presets, scripts. The assets start organized, drift as the project grows, and end as a folder full of files named with whatever the artist remembered at 2 AM. The artist knows the good assets are in there somewhere. Finding them is the hard part.

An agent is well-suited to the boring part of asset management: tagging, indexing, and surfacing assets without ever importing one. The agent does not decide which assets are good. It does not pick the texture that matches the project's mood. It does not load a model into Blender. Those are the artist's calls. The agent's contribution is the metadata layer that lets the artist find what they need.

This article walks through how to set that up. It picks up the asset-pipeline workflow from Blender + OpenClaw: Agents in the 3D Pipeline and goes deeper into the asset library itself: how the agent organizes it, what the agent records, and where the agent stops.

What the agent is for

The agent's role in an asset library is to keep the metadata current. The library has three parts:

1. The files themselves. Models, textures, HDRIs, scripts. The artist owns these. 2. The metadata. Tags, descriptions, source URLs, license info, render-ready status. The agent owns this. 3. The index. A file (or a database) that lets the artist search the metadata. The agent builds and maintains this.

The agent does not move or rename files. The agent does not delete anything. The agent does not decide which assets are "good" — that is a creative judgment. The agent only writes metadata and queries it.

The split is what makes the workflow safe. The artist owns the files; the agent owns the description of the files. A bad description is fixable. A bad file rename breaks every reference in the project.

The library shape

A typical 3D project has a library like this:

assets/
├── models/
│   ├── props/
│   ├── characters/
│   └── environments/
├── textures/
│   ├── wood/
│   ├── metal/
│   └── fabric/
├── hdris/
├── sounds/
├── scripts/
│   ├── setup/
│   └── render/
└── references/

The artist puts files in here as the project grows. The agent reads the directory and writes a metadata file alongside each entry:

assets/models/props/chair.blend
assets/models/props/chair.meta.json
assets/models/props/chair.preview.png

The .meta.json file is what the agent owns. It contains:

{
  "path": "models/props/chair.blend",
  "type": "model",
  "category": "props",
  "tags": ["furniture", "wood", "low-poly"],
  "source": "Sketchfab CC0",
  "license": "CC0",
  "added": "2026-07-14",
  "poly_count": 1248,
  "size_mb": 1.2,
  "notes": "Wood material applied. No UV issues at import.",
  "preview": "models/props/chair.preview.png",
  "last_rendered_with": "blender 4.2"
}

This is the agent's contribution. It is a plain JSON file the artist can read, edit, and trust. The artist adds notes when they notice something — "this texture looks bad at small sizes," "this model needs retopology" — and the agent reads those notes back.

What the agent reads

The agent's first job is to scan the library and produce the metadata. The agent can:

  • Detect file type. By extension and by reading the file header. .blend files are Blender; .fbx, .obj, .gltf are exports; .png, .exr, .hdr are textures or HDRIs; .wav, .mp3 are sound.
  • Read Blender file metadata. Blender files have a cycles section, a custom-properties section, and an asset library. The agent can read these without opening Blender — a simple Python script using bpy or a header parser can pull counts, dimensions, materials.
  • Read EXIF and PNG metadata. Camera info, color space, dimensions. Useful for HDRIs and reference photos.
  • Read file size and modification time. Useful for "when did I last use this?" queries.

The agent does not render a preview. The agent does not run a simulation. The agent does not import the file. The metadata is what is written on disk by the artist's workflow.

What the agent writes

The agent's metadata writes are limited:

  • Tags. Categorical labels the agent extracts or the artist adds.
  • Source and license. Where the asset came from, what license it carries.
  • Technical metadata. Poly count, dimensions, file size.
  • Preview reference. A path to a preview image the artist has rendered. The agent does not generate this — the artist does, or the artist points to an existing thumbnail.
  • Last-used timestamps. When the asset was last referenced in a .blend file or in a render.

The agent writes to a .meta.json file next to the asset. The agent never writes to the asset file itself.

How the artist uses the index

The artist queries the metadata. Two patterns work well:

  • Command-line search. A small script that reads all .meta.json files and filters by tag, type, license, or other fields. The artist types search "wood chair" and gets a list of matching assets.
  • Generated index page. A static HTML page the agent rebuilds whenever the metadata changes. The page lists assets with thumbnails, tags, and direct links. The artist opens it in a browser when they need to find something.

The generated index page is the more useful pattern. It turns the metadata layer into a browsable catalog. The artist can scroll through it like a Pinterest board, find something that fits the project's mood, and click through to the file.

The agent's role in the index page is:

1. Read all .meta.json files. 2. Group assets by type and category. 3. Render an HTML page with thumbnails, tags, and links. 4. Write the page to the project's documentation folder.

The artist never edits the HTML directly. If a thumbnail is wrong, the artist updates the .meta.json and the agent regenerates the page.

Boundaries

The agent does not:

  • Move files. The directory structure is the artist's. If assets need reorganizing, the artist does it. The agent updates the metadata to reflect the new structure.
  • Rename files. File names matter for references in .blend files. Renames break references. The agent updates the .meta.json to record the new name only if the artist has renamed the file.
  • Delete files. Deletion is irreversible. The agent can mark assets as archived: true in the metadata, but the file stays on disk. The artist deletes when they are confident.
  • Modify assets. The agent does not open Blender to "fix" a model, "improve" a texture, or "tidy" a script. The file is sacred.

These boundaries are what keep the asset library trustworthy. The artist knows the agent has not touched the files. The agent's contribution is the metadata — the description, the index, the search. The files are the artist's.

What this changes for 3D artists

The shift this introduces is mostly about where the artist's attention goes. An artist who uses these patterns well spends most of their time on the parts of the craft that require taste: picking the right model, adjusting the texture, building the scene. The agent spends its time on the parts that require meticulous repetition: tagging, indexing, generating the catalog page.

The combination is faster than either alone. The artist does not have to remember which folder the good chair is in. The agent's index has it. The artist does not have to scroll through fifty .blend files looking for one with a wood material. The agent's tag filter has it.

The asset library stops being a pile and becomes a catalog. The catalog is what makes the project's assets usable for the next project — which is the point. A library that does not get reused is not a library; it is a folder.

Related reading