What is a vector database?

A vector database is a store built to hold embeddings, which are numerical representations of meaning, and to find quickly the items whose embeddings are closest to a query's. It lets an AI agent search a business's documents and records by what they mean rather than by exact words. It is usually the retrieval engine behind an agent's access to policies, guides and past cases.

Why does a vector database matter once agents act?

Because it decides what the agent reads before it acts. An AI agent asked about a customer's eligibility for a payment holiday gets whatever the vector database ranks as closest: ideally the current policy, possibly a superseded version, a training slide or a note someone saved without review. The agent cannot tell the difference unless the database stores it.

Similarity is a measure of meaning, not of authority. The closest passage is not necessarily the approved one.

How does a vector database work in practice?

Content is split into chunks, each chunk is turned into an embedding, and the embeddings are stored with metadata. A query is embedded the same way and compared with the stored vectors; the nearest are returned. Indexes make this fast even across millions of chunks.

For agents in regulated work, the metadata does most of the governing:

• Source and version, so superseded material can be excluded.
• Owner and provenance class, so the agent knows what it may rely on.
• Access rights, so the agent only retrieves what it is permitted to see for this task and customer.
• Retention, so deleted or expired records leave the index too.

Filters on that metadata should run before results reach the agent, not after.

What does that look like in an example?

A bank's complaints agent searches for guidance on handling a complaint about a delayed transfer. The vector database returns six chunks. Two are from the current complaints procedure, one from an older version, two from past complaint files involving other customers, and one from a staff forum. With metadata filters, the agent sees only the two current procedure chunks. Without them, it would have seen other customers' complaint details, which it had no right to use.

How is a vector database different from a search log or monitoring tool?

A vector database's query logs show what was retrieved. That is useful for debugging, but it is not oversight: it records what happened without deciding whether it should have. A log showing that an agent retrieved another customer's file tells you after the fact. A filter that stops the retrieval prevents it. The distinction is drawn in observability is not oversight.

How is it different from a knowledge graph?

A vector database finds content that is similar in meaning. A knowledge graph stores explicit relationships between things, such as which person directs which company. The first answers "what text is about this?"; the second answers "what is connected to this?". In a multi-agent system, several agents may share one vector database, which makes access filters per agent essential.

Where Pryme fits

In Pryme, facts retrieved from any store arrive stamped with their source and provenance class, so the class can be checked at the moment of action rather than assumed from a similarity score. See the governed agentic operating system, explained.