Knowledge bases decay: owners change teams, documents go stale, and answers get duplicated. Keep storage, retrieval, and permissions in the core; run optional curation workers outside it. Pair resource change events with scheduled checks: events help workers react to recent changes, while schedules catch work based on elapsed time.
Key takeaways
- Use change notifications for supported committed resource changes, not as a substitute for current content.
- Schedule age-based reviews and digests over accumulated events.
- Let workers propose changes; keep owners responsible for approving accepted knowledge.
Start from changes, not assumptions
Create, update, move, and delete operations can inform curation, but a resource event is a notification that something changed—not a complete audit record or a copy of the resource. Events help invalidate cached reads and identify a resource and revision; they do not include full document bodies, row-by-row differences, or guaranteed exact counts. A consumer that needs current content fetches it through authorized AKB APIs.
Where events are unavailable, consumers can use incremental polling by update time or scheduled scans, depending on the source.
Give each consumer one job
| Consumer | Trigger | Output |
|---|---|---|
| Weekly digest | Weekly schedule over accumulated change events | A summary for the team channel |
| Stale-document check | Scheduled age check; 180 days is one example policy | A review request to the owner |
| Duplicate finder | Supported resource change, followed by a similarity check | A merge suggestion |
Schedules handle elapsed-time work; events identify recent changes. Keeping consumers separate lets teams adjust one job without changing the store or other jobs.
Keep owners in control of accepted knowledge
A curation worker can be wrong: it may merge documents that only look alike or flag a policy that is still valid. A practical recommended workflow is to have workers create proposals, such as a draft or review request, and let the document owner decide whether to accept them. This is a team workflow, not an automatic feature of the event stream.
Design consumers to be retry-safe and idempotent: repeated delivery should not create duplicate digests or review requests. Event streams are not permanent histories; if retention creates a gap, reconcile against current state through AKB.
Decide where AKB fits
AKB, Dnotitia's agent knowledge base, keeps storage and retrieval in the core and leaves curation to external workers. Supported resource changes and their outbox events commit together, so a rolled-back operation produces no committed event.
With redis_url configured, a publisher sends events to a Redis Stream for operator-managed consumers. Redis is an operator channel, not a user authorization boundary. AKB also provides an authenticated per-vault server-sent events endpoint that checks reader access. External workers need appropriate access to the vault and APIs they use. The change-event contract describes delivery and recovery.
Audit logging is separate from resource change notifications. It is optional, disabled by default, and scoped to MCP dispatch; capture is best-effort and does not guarantee coverage of all system access. The log system owns retention.
Test one consumer before adding more
Pilot the weekly digest, then test the scheduled stale-document review against a known old document. Success is a digest the team finds useful, no repeated notifications after retries, and a check that catches a deliberately missed change.