A library system needs a staff agent that can call the catalog API and also answer from a policies knowledge base. How should tool and knowledge services be matched?

A library staff agent that must call the catalog API and answer from written circulation policies needs both tool-calling and a knowledge store. Live holdings and availability change in the catalog system, so an API tool is the correct mechanism. Authored policies live in documents, so a knowledge store supports grounded retrieval. Matching tools to live systems and knowledge to authored policy is the core planning split for municipal agents.

Integrating catalog API tool-calling for indexed holdings and a knowledge store for written policies fails because indexed holdings can be stale and cannot reflect real-time shelf status, which requires a live API call at query time.

Integrating catalog API scheduled ingestion for live holdings and a knowledge store for written policies fails because scheduled ingestion creates a stale indexed copy of the catalog and cannot provide real-time availability, which requires direct live tool-calling.

Integrating catalog API tool-calling for live holdings and a knowledge store for loan transactions fails because loan transactions are live operational records, not authored written policies, so indexing them cannot support grounded retrieval of circulation policy rules.

Exam caveat: tool permissions should be least-privilege (catalog/hours, not payroll), and policy indexes must track effective dates. Operational check: ask a holdings question that requires an API response and a policy question that requires retrieval; confirm each path is used, and fail closed when the catalog tool errors instead of inventing availability.