One library per client means one project per client, and the property you are actually buying is that a search cannot reach outside the project it was run in. Everything else about the setup follows from that. You decide what goes into each project, who on your team touches it, and what happens to the material when the relationship ends. The organising work is small. Deciding what belongs in a client's library, and what is just storage, is the part that takes a conversation.
What a client library is for
There is a difference between keeping a client's files and being able to answer questions about them. Storage answers where is the master. A library answers which of last year's spots opened on a face, or where in the founder interview she explained why they rebuilt the product. The second kind of question is the one that shows up under deadline, usually from someone who was not on that shoot and has no idea which of forty files to open.
The routes agencies use
Shared drive folders with a naming convention are the default, and they work exactly as far as the discipline of the person doing the naming. Every fact about the footage that nobody typed into a file name is invisible. Organising files for editing solves handover and does not solve recall.
A managed asset system per client adds tags, permissions, and a search box over the metadata. It is a real answer, it holds up for years, and it costs somebody's ongoing attention, because tags only exist if a person or an auto-tagger put them there. Before committing to one, it is worth reading what goes into building a library in the first place, since most of the effort is cataloguing rather than software.
Building a per-client index yourself gives you exactly the boundaries you want and a pipeline to maintain forever. A handful of agencies with an engineer on staff do this well. Most do not have the engineer.
The fourth route is a hosted retrieval layer where each client is a separate project, reached either from the web app or from an assistant, so the boundary is structural rather than a convention your team has to remember.
Give every client their own searchable project
Vivu can be added to Claude as a custom connector. You make one project per client and upload that client's footage through the project's secure upload page in the browser, where each video is indexed once after it lands. From then on you ask inside that project, in the conversation, for things like the part where the founder explains why they rebuilt the product, and you get back openable time ranges you can preview one at a time. Because every search runs inside a single project, a question asked about one client's material has no path to another client's. The web app and the connector are the same account, the same projects, and the same allowance, so a video someone uploaded in the browser is there in the next chat.
What to put in, and what to leave in storage
Uploading everything is the instinct and it is usually wrong. Indexing costs time and allowance, and most client footage gets used once and never again. The material worth putting in a library is the material somebody will go looking for: finished spots you will be asked to match or beat, long interviews that get mined for pull quotes, event and product footage that outlives the campaign it was shot for. Camera masters that only ever feed one edit can stay where they are.
Third-party material deserves a second's thought before it goes in. If you are collecting a client's competitors' ads, or UGC submissions, confirm you have the right to use what you are about to put in a project.
When one shared library is fine
A two-client shop where the same three people touch everything does not need the separation, and the overhead of project-by-project discipline will cost more than it returns. Neither does an agency whose work is mostly delivery rather than reuse: if footage leaves the building and never comes back, a library is a filing cabinet with extra steps. The setup earns its keep at the point where nobody can hold the whole archive in their head, which usually arrives sooner than people expect.
Where this route stops
A search runs in one project, which means there is no single question across your whole client roster. Footage has to be uploaded and indexed in the cloud first, so onboarding a client with a large back catalogue is an upload project of its own. Searching consumes an allowance rather than being free at the margin. Results are ranges you open and check, not exact frames. And a project of this kind is a working space for your team rather than a client-facing portal, so if clients need their own login to browse and download, that is a review and delivery tool doing a different job.
How to tell if you need this yet
Count how many times in the last month someone on your team asked another person where a piece of footage was, and how often the answer required opening files to find out. If that number is small, your naming convention is holding and you should leave it alone. If it is large, and the person who knows is getting interrupted for it, the per-client library is worth the upload week. The boundary between clients is not the hard part. Deciding what deserves to be searchable is.
FAQ
How many projects should an agency actually create?
One per client is the setup that matches how searches run, since each search stays inside a single project. Splitting further, for example one project per campaign, buys tighter results at the cost of having to remember which project a piece of footage went into. Most teams land on one per client, with a separate project for anything that is not a client's own material, such as reference and competitor footage.
Can a client log in and browse their own library?
That is a different product category. A searchable project is a working space for the people making the work, and client review and delivery is handled by tools built for approvals and shared links. If the requirement in the brief is a branded place where the client browses and downloads on their own, plan for both rather than expecting one to cover the other.
What happens to a client's footage when the relationship ends?
Deleting the project or the individual videos removes that media from the cloud. Doing it deliberately at offboarding is worth writing into your process, alongside the usual handover of masters, because the default otherwise is that material sits in a library nobody is using. Confirm first what you are contractually required to hand back or retain.
Should we index footage we did not shoot?
Only if you have the right to use it. Competitor ads, UGC submissions, and stock all come with terms, and putting a file into a searchable project is a use. The practical habit is to keep anything you did not shoot in a clearly separate project, so nobody later mistakes it for footage the client owns.