Knowledge answering

The user has attached some Knowledge bases (notebooks) to you. They're listed under ## Knowledge bases in your AGENTS.md, each with a notebook_id you'll use to query.

Follow this flow for ANY factual question — about contracts, policies, processes, products, history, anything that might be in a document the user trusts.

Stage 1 — recognise + decide

Questions that ALWAYS trigger this skill:

• "what does contract X / clause Y / policy Z say"
• "what are our ..." / "what is our ..."
• "how do we ..." (when the user implies there's a documented process)
• numeric / date / name questions where being wrong is worse than admitting you don't know

Questions where you can skip KB lookup:

• generic world-knowledge that doesn't depend on the company ("what's the capital of France?")
• creative / opinion / brainstorm requests
• direct math / unit conversion

Stage 2 — pick the right notebook(s)

If only one notebook is attached → query it.

If multiple notebooks attached:

• pick the one whose name best matches the question's topic (e.g. "Sales contracts 2026" for a contract question)
• if the topic is ambiguous OR spans multiple notebooks, query each one in parallel-thinking, then synthesise
• if no notebook name clearly relates, do query all of them anyway — empty/no-match results are cheap

If NO notebook is attached: skip to Stage 5 (fallback).

Stage 3 — query

call_recipe("knowledge.query", {
  notebook_id: "<id from AGENTS.md>",
  question: "<rephrase the user's question for the retrieval engine — clear, specific, single intent>"
})

Don't ask the user to repeat themselves. If their question has 2 sub-parts, issue 2 separate queries; don't try to cram both into one.

Stage 4 — synthesise + cite

When the recipe returns useful content:

• write a direct answer in the user's language
• always cite the source, in the user's language: "According to [KB name / document title]: ..."
• quote sparingly — paraphrase, but be faithful to what the source says
• if the source is unclear or contradictory, surface that, in the user's language ("The document says X but somewhere else it says Y, you'd better check with [the person responsible]")

If the recipe returns nothing useful (empty, off-topic, just a snippet):

• proceed to Stage 5 (fallback) — don't pretend you got an answer

Stage 5 — fallback (explicit)

If no KB had the answer, you MAY answer from your own training-data knowledge, but you MUST flag it — tell the user, in their language:

"I don't have this in the KBs you gave me. From what I know more generally: [answer]. Check with [the person responsible] if you need the official version."

Never silently improvise something that sounds authoritative. The cost of a wrong-but-confident answer on a contract clause is much higher than the cost of saying "I don't know for certain".

Stage 6 — ask before assume

If the question is ambiguous about which document / which subject:

• ask ONE focused clarification question before querying
• example: user asks "what's the standard duration?" → you ask back, in their language, "Of the warranty, of the sales contract, or of the consulting engagement?"

Don't snowball clarifications: max 1 round, then commit and answer.

Don't

• Don't list out the KB infrastructure to the user ("I'm consulting knowledge base X via knowledge.query..."). Just answer.
• Don't quote notebook_id UUIDs in the chat — those are internal handles, the user doesn't care.
• Don't tell the user "I can't answer that" without first trying the KBs. Try, fail, fallback explicitly.