Share Knowledge Publicly with Zibri Agents

Most of what you build in Zibri is for you. But there's a category of knowledge that shouldn't stay private — a product FAQ, a client-facing resource, a team reference — where the value is in getting it into other people's hands without also handing over everything else in your account.

That's what Zibri's AI agents are for. Any vault can become a public-facing chatbot. Visitors ask questions in plain language, get answers sourced from that vault's content, and never see your raw notes.

One vault, one agent, one shareable link

Creating an agent starts in the Shared Agents panel. You pick a vault, give the agent a name and a system prompt that describes how it should behave, and publish it. The result is a link you can send to anyone — a customer, a teammate, a client — who can then ask the agent questions without logging into Zibri.

Every answer the agent gives comes from the vault you pointed it at. It doesn't reach into your other vaults. It doesn't draw on the open internet. If the answer isn't in that vault, the agent says so rather than inventing something.

[PICTURE: screenshot of the Zibri Shared Agents panel showing an agent being created — vault selection, name field, system prompt, and the shareable link it generates]

Answers sourced from content, not generated from nothing

The agent behaves the same way Zibri's AI Chat does: it retrieves relevant content from the vault and grounds every answer in what it found. That means you can point an agent at a vault of product documentation and trust that it won't answer support questions by making things up — if the information isn't there, it says it isn't there.

This matters more than it might seem. A generic chatbot that hallucinates plausible-sounding answers to customer questions is worse than no chatbot at all. An agent sourced from real content — your content — answers only what it actually knows, and can tell the difference.

The vault becomes the knowledge base

What determines how useful an agent is comes down to what's in the vault you built it from. A vault with thorough documentation, real meeting transcripts, and uploaded reference materials will produce a far more capable agent than one with a handful of quick notes.

This is where Zibri's capture pipeline feeds directly into the agent's value. PDFs you've uploaded, emails you've forwarded in, meeting transcripts from the recorder — everything indexed in the vault is available to the agent. The richer the vault, the more accurately the agent can answer. Building a client-facing agent and finding it can't answer common questions is a diagnostic: those questions aren't in the vault yet.

[PICTURE: screenshot of a Zibri agent responding to a visitor's question, with the sourced answer and the note citation it came from]

Who uses this, and for what

Consultants use agents to give clients a self-service resource specific to their engagement — a vault built from deliverables, meeting notes, and reference documents, turned into a chatbot the client can query between calls. The client gets quick answers; the consultant doesn't get the same question five times.

Teams use agents as internal reference tools. Build a vault around a specific project or process — onboarding, a product launch, a compliance topic — and give teammates a link they can query instead of digging through shared drives or asking whoever happens to know.

Customer-facing teams use agents to publish knowledge bases for support. A vault of product documentation becomes a chatbot visitors can ask real questions, with answers pulled directly from the material rather than generated from pattern-matching on the open web.

In each case, the agent separates access to answers from access to your vault. Visitors get one. They don't get the other.

What the analytics tell you

Agents include usage analytics that show query volume and the kinds of questions visitors are asking. This is more useful than it sounds: the questions visitors ask an agent and can't get answered are a direct signal of what's missing from the vault.

If a customer-support agent keeps fielding a question it can't answer, that question should be documented and added to the vault. The agent's gaps become a roadmap for filling them.

The takeaway

If you have a vault that represents real, useful knowledge — documentation, research, decisions made over months of meetings — an agent is how you make that knowledge available without opening up your entire account. Build the vault well, point an agent at it, and what you've captured stops being private notes and starts being something other people can actually use.

That's a different kind of return on the time you spent capturing it.

— Erin