Taxonomy
Knowing what a question is about before answering it.
What it does
Knowledge tags are derived from the material an agent is grounded in and from its connectors, and those tags are policy-aware: a tag can be visible while its underlying source is not. A tiered classifier decides whether an incoming question is inside the agent's scope, escalating from cheap pattern matching to embedding comparison only when it needs to.
Why it matters
Most bad agent answers are scope failures, not reasoning failures: the question was never one this agent should have tried. Classifying scope first turns those into a clean redirect instead of a confident invention.
How it works
Tags respect access policy
A tag derived from restricted material does not leak the existence of that material to someone who cannot see it.
Classification is tiered for cost
Cheap pattern matching runs first; embedding comparison only runs when the cheap tier is not confident.
It is not an ontology, and we do not call it one
There is no authored hierarchy, no inheritance, no schema to maintain. If you need a formal taxonomy you manage yourself, this is not it yet.
Questions
- Can I define my own taxonomy?
- Not today. Tags are derived from your material rather than authored as a scheme. An authorable hierarchy is the obvious next step and is not built.
- What happens to an out-of-scope question?
- The classifier flags it before the model commits to an answer, so the agent can redirect rather than improvise.
The rest of the bag
AccessControl
Per-document permissions that filter answers, not just pages.
Policy resolution is cached per session for speed; a permission change propagates on cache invalidation rather than instantly on every in-flight request.
Docs
A folder tree the agent reads, and a config file it obeys.
Extraction covers PDFs, spreadsheets and transcripts. Exotic binary formats are not parsed.
Events
A durable ledger of what agents did, and why.
The in-process event bus is a single-node emitter, not a distributed broker. The durable cross-agent record is a separate Postgres task ledger.
That was step 2 of 6: it crosses a tenant boundary. Next, for agent-to-agent traffic the edge is authorised before anything executes, and the caller token is minted for that hop alone.