Internal knowledge search
An answer nobody can verify is worth very little internally. Knowledge search is useful when the answer arrives with its source attached and the agent can also read the live system rather than a six-month-old export.
The problem
Internal knowledge is split between documents and live systems, and search covers only the documents.
How it is built
- Add your documents as knowledge
Documents are scoped to an environment and reviewed, so what is searchable is deliberate.
- Publish read actions for the live systems
The current value comes from the API; the explanation comes from the document.
- Keep the agent read-only
For this use case there is usually no reason to publish any write action at all.
What you get
- Answers that cite where they came from.
- Live figures rather than whatever was true when the document was written.
- A searchable surface that is deliberately curated, not everything anyone ever uploaded.
What keeps it safe
- Knowledge is environment scoped.
- Runs are attributable to the employee who started them.
- No write actions need be published.
Publish the read actions, run it for a few weeks, and read the traces. Deciding which writes to publish from evidence is both safer and a much easier internal conversation than deciding from a roadmap.
Questions
Can we restrict which employees see which documents?
Knowledge is scoped to an environment, and runs are bound to an identity. Finer-grained document permissions are something you model in how you split environments and deployments.
Build beyond the expected.
Create a workspace, register an application, and import your first API.