Three Ways to Find a Generation You Made Weeks Ago

"Find that video I made a few weeks ago" sounds like one request. Underneath it, it's a routing problem with three possible answers and no shared fallback between them — and the failure mode isn't the agent picking a slightly worse tool, it's the agent (or you, prompting directly) picking a tool whose scope simply doesn't include what you're looking for, which returns an empty result that reads exactly like "this is gone," even when it's one query away in a different tool.

Why "find it" stopped being one function

The reason there isn't a single search-everything tool is that "everything you've made" isn't one kind of data. A generated video has a prompt attached to it that describes its content. An uploaded reference photo doesn't — it was never generated from a description, so there's no prompt text to match against. A Suno track and a slideshow aren't in the same table as a generated image at all. Once you actually look at what's stored where, three non-overlapping tools is the honest shape of the problem, not an accident of engineering.

Tool 1: search_my_media — when you can describe what's in it

This is the one built for exactly the phrasing that opened this piece. search_my_media runs a multi-term match over the prompts behind your past generations — images, videos, and music — so "find that golden retriever video" or "the neon Tokyo portrait from last week" works because the words in your request overlap with the words in the original prompt, not because you remembered a filename or a date. It also takes optional filters — a date range, a specific model — for narrowing a common subject down to the right one among several.

The scope that matters here: it searches generations, meaning things Versely's models produced from a prompt. It has nothing to search if what you're picturing was never generated from text in the first place.

Tool 2: fetch_user_generations — when you just want the recent list

Sometimes there's no subject to describe because you're not thinking of one specific piece — you want to see what you made recently and pick from it. fetch_user_generations is the paginated, no-query answer to that: a recency-ordered list of your past images, videos, or audio, filterable by content type, that you browse rather than search. It's the right tool for "show me my last few videos" and the wrong one for "find the one with the dog in it," because it has no concept of subject matter at all — it hands you a list in order and expects you to recognize what you're looking for, not describe it.

Tool 3: browse_user_library — everything that was never a generation

This is the tool most people don't know exists until the first time they need it and reach for one of the other two instead. browse_user_library covers, explicitly, what generation search does not: raw files you uploaded rather than generated — a reference photo for an image edit, a voice sample for cloning — plus generated music tracks, slideshows, and UGC video overlays. None of that lives in the same place as a prompted image or video generation, so neither search_my_media nor fetch_user_generations has any way to surface it, no matter how precisely you describe it.

This is the tool for "the product photo I uploaded last month," "that slideshow I built for the launch," or "the reaction clip I used as an overlay" — three requests that sound exactly like the ones the other two tools handle, and none of which those tools can actually answer.

The overlap trap

The scopes don't overlap, but the phrasing people use to ask for things does, and that's where this breaks in practice:

• "Find my carousel about morning habits." A slideshow isn't a generation with a searchable prompt in the same sense a single image is — it's library content. Run this through search_my_media and you get nothing or an unrelated single image that happens to share a word, not the slideshow itself.
• "Show me the photo I sent you for the background swap." That photo was uploaded, not generated — there's no prompt behind it because you didn't write one. search_my_media has nothing to match against; this is a browse_user_library request wearing a description's clothing.
• "What have I made this week?" No subject, no upload — this is a plain recency ask, and reaching for search_my_media with a vague or empty query gets a worse, less relevant result than just asking fetch_user_generations for the recent list directly.

In every case, the tool that got picked isn't broken — it's answering the question it was built for, correctly, about a different dataset than the one the user actually meant. The empty or irrelevant result that comes back doesn't announce "wrong tool, try again over here." It just looks like the content isn't there.

The rule that actually fits in your head

One question does most of the routing: was this generated from a text description, or not?

• If yes, and you can describe its subject — use search_my_media.
• If yes, and you just want to browse recent output without a subject in mind — use fetch_user_generations.
• If no — it was uploaded, or it's a slideshow, a UGC overlay, or a music track — use browse_user_library, regardless of how specifically you can describe it.

A Versely walkthrough

You don't need to name the tool yourself in normal use — ask the agent to find something you made before and it routes based on how you phrase the ask, the same three-way split above running underneath one conversational request. Three real phrasings and what actually happens:

1. "Find that beach sunset video I generated a couple weeks ago." A subject description of a generation — this is search_my_media territory, matched against the prompt text of your past video generations.
2. "What have I generated in the last few days?" No subject at all — this is fetch_user_generations, a plain recency browse rather than a search.
3. "Where's the product photo I uploaded for that background job?" An upload, not a generation — search_my_media has no prompt to match here, so this routes to browse_user_library instead, which is the only one of the three that indexes uploaded reference files at all.

Once you've found the piece worth keeping, the move that actually prevents this search from happening again next month is saving it into a named project on the spot rather than trusting future-you to search for it later — a project groups the keepers together so "find it" becomes "open the folder," which is a faster and more reliable operation than any of the three search tools above.

That last point is really the whole argument. None of this is a problem worth solving with a better memory — it's a problem worth solving with organization, and it only becomes a real problem in the first place once your content velocity is high enough that a month's output stops fitting in what you can recall unaided. Teams shipping ten pieces a week hit this within a month; teams shipping one piece a week may never notice the three tools exist, because a short list doesn't need a router. If you're generating enough that this article was useful, you're generating enough that a project folder will save you more time than getting better at phrasing search queries ever will.