Find the right ad asset in seconds with AI search

Somewhere in your workspace is the exact file this afternoon's campaign needs. A vertical cut of the hero film. The product on white, cropped square, approved by the brand team in March. You know it exists because you shipped it in the spring sale. What you do not know is where it lives, what it was renamed to, or whether the copy you can find is the version that got signed off.

So the search begins. The library, then the old campaign folder, then the export someone called final_v3, then the Slack thread where a designer posted it, and finally a message to that designer, who is on holiday. Industry coverage of AI-assisted asset search keeps arriving at the same rough figure: teams spend about a quarter less time hunting for files once search actually works. Hold the number loosely, it is trade coverage rather than a controlled study, but nobody who produces campaigns for a living doubts the direction. The hours lost to looking are real, and they come straight out of the part of the week that ships work.

What the coverage rarely says out loud is that finding the file is only the halfway point. In campaign production, an asset you have located is still an asset doing nothing. It is not in the template, not in the flow, not rendering. The search that matters ends in usage: file found, checked, and wired into a live build. That is the workflow this piece walks through, using Nubu's AI assistant, which searches the same product that renders the ads.

What "AI asset search" usually means, and what campaigns need#

Say "AI asset search" and most people picture a smarter library: type a phrase, get matching files. The enterprise DAM category does that and goes much further, with rights management, licence tracking, expiry workflows and brand portals serving thousands of users. Platforms like Frontify, Canto and Aprimo have spent years on those problems. If brand governance at that scale is your problem, evaluate a DAM. Nubu is not one and does not pretend to be.

Nubu's asset library is a campaign production library, and it earns its keep as one. Files live in folders with full paths, every record carries up to 50 tags, video tiles scrub on hover so you can preview a clip without opening it, and a smart filter turns typed fragments into faceted chips (type 1080 and it offers Width). There is a global search across the organisation, a block flag that keeps a problem file out of renders until someone clears it, and a detail drawer where your team leaves comments on the asset itself rather than in a chat thread three tools away.

That is the substrate. The difference worth writing about sits on top of it: the thing searching this library is the same assistant that plans campaigns and drafts flows, so a found asset has somewhere to go. The question a campaign team actually asks is rarely "where is the file". It is "which of our files can run in this placement, and can it be in the build by five o'clock". Library-side search cannot answer that, because the answer is not in the library. It is in the templates, the placements and the flow. Search-to-usage is the uncovered ground, and it is where the rest of this article lives.

Ask in plain language, and get an answer, not a sample#

Start with the question you would ask a colleague: "do we have any vertical video of the trainers on a running track?"

The assistant runs a real search, not a guess. It searches asset names, original filenames and tags in free text, filters by kind, dimensions and status, and can browse one folder or span the whole organisation (a query always searches everything, so a file misfiled two years ago is still findable). Results come back as compact rows: name, kind, dimensions, duration, size, a preview of the tags, and a usable flag, so a blocked or still uploading file never sneaks into a shortlist.

Two rules make the answer trustworthy. First, searches come back in pages and the assistant is required to keep paging until there is nothing left before it tells you what does or does not exist. Second, a filter the search cannot honour is refused outright rather than silently dropped, so you never get a broader result set quietly described as a filtered one. Ask what you have and you get an answer, not a sample.

When the shortlist forms, detail checking is deliberate and batched: the full record for the whole set in one go, with exact dimensions, duration, size, every tag and the folder path each file lives in. "Check these twelve before we choose" is one question, not twelve.

It looks at the pictures, not just the metadata#

Here is the part that changes how searching feels: the assistant can actually look at your files.

Ask "which of these has the runner facing left?" and it opens the images and checks. For a video it looks at the poster frame captured at upload, so it can see what a clip shows without playing it. This is visual inspection, not metadata matching: an untagged, badly named file shot in 2023 is exactly as findable as a well-groomed one, because the assistant can look at candidates and tell you what is actually in them.

Inspection is honest about its own limits. Batches are viewed as reduced previews and the assistant says so, with a note that fine detail and small text may not be legible, and it inspects a single file at full quality when detail matters. An oversized batch is refused rather than silently trimmed, so it can never believe it looked at files it never saw. If a preview cannot be read at all, the file is named and skipped, never quietly omitted.

In practice this is what makes a messy library searchable today rather than after a six-week tagging project. You do not need perfect metadata for the assistant to find the shot; you need the shot to exist.

Thumbnails in the chat, and folders resolved by name#

A search that ends in a list of filenames still makes you do the last step. The assistant attaches the actual pictures instead: up to eight clickable thumbnails ride its reply, so "these three are the strongest fits" arrives as three images you can see and click through to the library drawer. Anything blocked or not ready to show is skipped and named rather than presented anyway.

Folders work the way people talk. Say "what is in the Autumn folder?" and the assistant resolves the name against the real folder tree, with full paths, because folder names repeat across branches and Retail / Logos is not Partners / Logos. Every folder it mentions is a link that opens that folder in the app. It can also create folders directly, including a whole nested tree in one pass: "set up a folder for each of our twelve markets under Campaigns" lands as one structured change, not thirteen requests.

Cleaning up the library as you go#

Finding exposes mess. The assistant is allowed to fix exactly two kinds of it directly, and both are additive.

The first is tagging. Ask for a tagging pass over a folder and it looks first (batch inspection of the actual images), then writes tags in bulk across the folder. Writes are additive by default, so tags your team wrote by hand are never clobbered, and it favours tags the filters cannot already express: subject, setting, season, mood, product, composition, rather than restating dimensions or file type. Every outcome is reported: records it could not touch are listed with reasons, and tags that would exceed the 50 per record ceiling are counted and declared rather than silently dropped. New tags are searchable immediately. To be clear about what this is not: nothing tags itself in the background. Tagging happens when you ask for it, and it looks before it writes.

The second direct write is creating folders. Everything else, renames, moves into folders, blocking and unblocking, arrives as a proposal card: the whole batch in one reviewable offer that shows what would change, record by record, and applies only when you approve it. Library restructures become something you review in thirty seconds, not something you do by hand for an hour.

Which template can even run this placement#

Now the campaign half of the question. The file is only useful if a template can carry it into the placement you are buying, and the assistant can read templates with the same rigour it reads assets.

Template search returns each template's output comps in summary: dimensions, aspect ratio, duration, how many text fields and footage slots each comp carries, plus tags and a usable flag. Full inspection goes further: every typed field with the template author's own instructions, every footage slot with its expected size, and a placement fit verdict per comp against real delivery rules. A nine second comp gets a plain verdict that Performance Max video needs at least ten seconds, with the comp's own duration quoted back. A static comp is judged against each Google image slot's ratio and minimum size, and the failing ones say exactly why.

That turns "which of our templates could run this as a Demand Gen video?" from an afternoon of opening projects into one question with a defensible answer. And because templates declare their footage slots with expected dimensions, the assistant can line up the two halves: this asset, this slot, this comp, this placement.

From found to wired in#

This is the point of the whole exercise. The same assistant that found the asset drafts the flow that uses it.

Ask it to build the campaign flow and the draft it offers references the real assets it found, not names it hopes will resolve. At offer time those references are verified again: the file still exists, is not blocked, and actually fits the slot it is being piped into. Then the entire proposed flow is test-built by the same build engine the real Build button uses, before the card ever reaches you. The approval card shows what the flow would produce, down to a table of the expected creatives, and any refusal to build surfaces on the card instead of at the moment you press Build. You approve, and the found asset is now a wired-in asset.

Two things stay yours alone. Approval, obviously: nothing applies without it. And uploading: the assistant cannot upload files. When something needs to come in from your machine, it offers an upload card that opens the library's own upload dialog with a folder chooser, and you do the act. If this plan-and-approve pattern is new to you, the AI campaign builder piece covers the full workflow, and product feed to video ads shows it running against a retail feed.

When the asset does not exist, generate it#

Sometimes the honest answer is "we do not have that", and because of the paging rules, that answer means it looked. The assistant can then close the gap itself.

It generates images (up to four in a run, and it can iterate on its own output, so "warmer light, tighter crop" is a follow-up rather than a new brief) and video (up to two in a run, and it runs for a few minutes, so it carries on usefully while the clip cooks). Before the first generation of a request it always asks: it restates what it plans to generate, offers a model choice when more than one could run the job, and takes reference assets where the model supports them. It does not burn spend on a brief you have not confirmed.

The results are not chat ephemera. Every generated file lands as an ordinary organisation asset in an "AI Generated" folder: taggable, searchable, commentable, blockable and wireable into flows like anything you uploaded. Generation runs on your organisation's own provider key, on models your organisation has connected. The same engine also runs inside flows as AI nodes for per-variant generation at build time; the chat lane is for assets you need right now.

The rules that make it trustworthy#

Search only saves time if you can act on the answer without double-checking it. The design here is strict, and worth stating plainly.

Completeness is enforced, not hoped for. Ask what you have and you get an answer, not a sample. Searches are read to the last page, every capped view says so, and "we do not have that" means it looked. Unsupported filters refuse rather than degrade.

Writes are narrow and additive. The assistant can write two things directly: tags and folders. Both add; neither destroys. Everything else is a proposal card, and no delete capability exists at all, not as a tool, not inside a card. When something should be deleted, it tells you, and you do it on the page.

Approval means what you saw. Every bulk card follows the same contract: find the records with a real search, say how many matched, show what would change per record, and offer one card carrying the exact records it found. Those records are frozen at offer. The card never carries a filter to re-run, so approving cannot sweep in records you never looked at. Approval re-checks every record, applies around anything that moved or vanished in the meantime, and reports what was skipped and why. Partial application is a normal, reported outcome, never a silent one.

And it does not oversell. There is no background semantic auto-tagging, no rights or licence management, no expiry workflow, and no similarity or duplicate detection beyond a hash check at upload. Those are DAM features, and if you need them, buy a DAM. Nubu's assistant covers the campaign end: find, verify, tidy, wire in, render. The wider case for this permission model is in AI proposes, humans approve.

A short note on cost#

Everything above that involves a model, the visual inspection, the reasoning, the generation, runs on your organisation's own AI provider keys, billed by the provider at its raw prices with no margin added by Nubu. Caps keep spend legible: generation is limited per run and drawn from weekly lanes, and the assistant asks before its first generation of a request. The full breakdown of connecting keys, choosing models and budgeting for them is in bring your own AI keys.

Prompts to try#

Four asks that cover the arc of this piece, typed as you would actually type them:

• "Do we have any vertical video of the trainers on a running track?": a real search across names, filenames and tags, paged to the end, with the best fits attached as clickable thumbnails.
• "Which of these has the runner facing left?": visual inspection. The assistant opens the images, or a video's poster frame, and answers from what is in the shot, not what the filename claims.
• "Run a tagging pass over the Autumn folder: subject, setting, season and mood": batch inspection first, then additive tag writes in bulk, with anything it could not touch named and every cap declared. A direct write, no card needed.
• "Set up a folder for each of our twelve markets under Campaigns, then move the loose files in Inbox into the right ones": the folder tree is created directly, and the moves come back as one approval card carrying the exact records it found, for you to approve or reject.

Start with the mess you have#

The honest test of any asset search is a library you are slightly embarrassed by: inconsistent names, half finished folders, tags from three regimes of good intentions. That is the library this assistant was built to be useful in, because it looks at files rather than trusting their labels, tells you the truth about what exists, and hands you the found file already wired into the campaign that needed it.

If that sounds like your library, see how the workflow fits together or start with your own files. Ask it what you have. The answer might be the fastest audit your library has ever had.