Design knowledge Q&A and action agents separately. Q&A needs evidence; actions also need permission, approval and a failure path.
Discuss your scopeFilter documents by user permission and cite files and passages. Flag outdated, conflicting or missing evidence and refer to an owner instead of inventing an answer.
Restrict tools to approved operations. Show targets and changes before writes, prevent duplicates and record outcomes. Stop or escalate failures; verify reversibility per action.
Illustrative example · not customer data
“Who approves this purchase? Help me submit a request.”
Q&A output: cite the current procurement policy and clause; do not reveal restricted documents.
Action output: draft a request with amount, target and approver; submit only after confirmation and system authorization, then return its ID or failure reason.
| Checkpoint | Acceptance method |
|---|---|
| Access separation | Test one question with different roles; restricted material must not leak through answers, citations or logs. |
| Updates and withdrawal | Update or withdraw a sample and verify index synchronization and removal of old versions. Agree cadence by source. |
| No answer and failure | Include missing evidence, tool timeouts and duplicate submissions; review fallback, alerts and human handoff records. |
Document inventory and owners, access matrix, update rules, cited test set, tool permissions, approval/failure records and operating handover.
Customers confirm data quality and permitted use. Business results and high-impact actions retain human review; model output is not approval, legal judgment or unrestricted authority.
Decide the next step