How to Stop an AI Agent From Regenerating Assets You Already Have

Make asset lookup an explicit part of the task before requesting generation. Ask the agent to search the existing Library, inspect relevant candidates and explain whether it can reuse or adapt one. Define the checks that matter for the task: visual fit, rig compatibility, source permissions and the project's performance budget.

A brief such as "add a rusty sword" leaves the acquisition method open. A more useful brief names the existing Library workflow, requests a candidate list and states when creating a new asset is appropriate. This makes the decision visible without assuming that every search result is usable.

The search → inspect → reuse-or-generate workflow

1. Search first, always. Before any generation call, the agent should search the Library using the supported kind and text filters, then inspect candidate metadata for the required style or other attributes. For modular gameplay kits specifically, use gripforge_gamekit_search with query/capability/tag/target filters rather than asking the agent to build the mechanic from scratch.
2. Inspect candidates, don't take the first hit. Pull metadata for each candidate: for kits, gripforge_gamekit_get returns provides/requires, slots, config schema, and versions so you can see what a kit actually implements before installing it. A catalogue entry existing is not a promise that every target platform is implemented — check the manifest.
3. Run acceptance checks (below) against the strongest candidate. Record which checks passed, which failed, and why.
4. Decide: reuse, adapt, or generate. If the candidate passes every relevant check, reuse it as-is. If it's close but fails one narrow check (e.g. wrong texel density), consider adapting it instead of a full regeneration. Only generate new when no candidate is close enough on the checks that matter for this task.
5. Log the decision. Even a one-line note ("reused prop-crate-02, passed visual+licence+perf, skipped rig fit — not a rigged asset") saves the next session from re-litigating the same search.

This is the same discipline used when reusing props while dressing a greybox level, or reusing library textures on terrain — the difference here is making it a default agent behavior instead of something you do manually each time.

Where files actually land

If you're driving this through MCP, know which endpoint you're using. The hosted endpoint (https://gripforge.ai/mcp, authenticated with an x-api-key header) returns asset URLs — it cannot write files into your project folder directly. The local MCP client, the @gripforgeai/mcp npm package, is what actually pulls a Library asset into your local project via its gripforge_library_pull tool. If your agent "reused" an asset but nothing appeared on disk, check which of the two you're connected to before assuming the reuse step failed. Details on both are in the MCP docs.

Example agent brief

This is an example instruction block, not a literal API call — adapt the wording to your agent's system prompt format.

Task: add a wooden storage crate prop to the warehouse scene.

Rules:
1. Search the Library for existing crate/container props matching tags
   ["crate", "prop", "warehouse"] before doing anything else.
2. For each candidate returned, report: name, tags, polycount if available,
   texture resolution if available, and the source of any usage terms.
   Mark missing information as unknown; do not invent a licence field.
3. Do NOT call any generation tool until you report search results and
   a pass/fail against the acceptance checks below.
4. If no candidate passes, state which checks failed and only then
   propose generation parameters.

Acceptance checks

None of these certify an asset automatically — they're what you or the agent should verify and report on before reuse is approved.

Rig fit deserves a caution: don't assume identical local offsets or rotations will work across differently proportioned rigs — that's not a requirement for success, and differences are expected. If you're fitting the same reused weapon or prop across multiple characters, see the checklist for fitting one weapon to small and tall rigs for the specific transform checks involved.

Troubleshooting

• Agent reports "no matches" too quickly. Check the search query isn't over-filtered by tag; broaden the supported kind/text filters and re-run before falling back to generation.
• Agent reuses an asset that visually clashes. The brief probably didn't ask for a visual-match report — add it explicitly as a required output field, not an implied step.
• Kit installs but a target platform doesn't work. Run gripforge_gamekit_dependencies to check for unresolved dependencies, and use gripforge_gamekit_install with dry_run to preview the plan before writing anything.
• Config values don't match what the kit expects. Read the config schema returned by gripforge_gamekit_get first. gripforge_gamekit_configure validates and applies configuration changes; it is not a read-only lint command.
• Reuse looks approved but nothing lands in the project. Confirm you're on the local @gripforgeai/mcp client, not the hosted endpoint, for any step meant to write files locally.

FAQ

Does passing these checks guarantee the asset is production-ready?

No. These are acceptance checks to run before reuse, not an automatic certification. Visual review, in-engine testing, and licence confirmation from the source remain your responsibility.

How should the agent handle missing information?

Report it as unknown and keep the acceptance decision open. Existing project records can support routine checks; unclear source terms, unavailable measurements or an uncertain rig fit require further review rather than an invented pass.

Where do I read more about the exact tool names and parameters?

The MCP documentation covers the Library tools, the gamekit manifest tools, and the difference between hosted and local endpoints in full.