Governance with Policies and Prompts | Botlit Use Cases

In a regulated organisation, the blocker for AI agents is rarely capability — it is the compliance officer's entirely reasonable question: "where, exactly, are the rules written down?" Botlit's answer is that guardrails are first-class objects, not comments in a prompt.

Policies come in seven types, matching the seven ways agents go wrong: content policies for what may be said, tool policies for what may be done (with per-tool risk levels — low, medium, high), data policies for what may be accessed, response policies for output constraints, budget policies for spend, rate-limit policies for volume, and retention policies for how long conversation data lives. Each is a managed definition with full lifecycle — created, reviewed, updated, audited.

Prompt templates bring the same discipline to instructions. A template is versionable, parameterised with variable placeholders, and rendered on demand; it can be duplicated for variants and addressed by slug. The compliance-approved disclaimer paragraph lives in one template referenced everywhere — not pasted into forty agents with drift in each.

Skills round out the vocabulary: named, reusable capability definitions that attach to agents and travel through the store. Policy bundles and prompt templates are store package kinds too, so a governance team can ship "our standard guardrail set" across every workspace it oversees.

The honest boundary: runtime enforcement — the execution path refusing a high-risk tool call or cutting off an over-budget agent mid-conversation — is on the roadmap, and Botlit says so rather than implying otherwise. What you build today is the codified, reviewable rulebook that enforcement will execute; organisations that write it now go live the day the switch exists, instead of starting their policy debate then.