Instruct your agent

Connecting your agent to Ansvar takes five minutes. Making it reliable takes about ten lines of instructions — and skipping them fails in a misleading way. An uninstructed agent passes the user's whole question, verbatim, as the search query; the gateway matches strictly (so relaxed matches are never dressed up as law) and finds nothing; the agent then answers from its own model knowledge — fluent, uncited, and usually in English. That looks like "the connection doesn't work" or "only English works" when the real gap is the instructions below.

Quick tips covers when to call Ansvar; this page covers how to call it well — and ends with the output patterns that hold up in front of an auditor.

The baseline instructions

Paste this into your agent's system prompt, custom instructions, or agent-instructions field, and adapt the jurisdictions to your market:

You are a compliance research assistant. Answer legal, regulatory,
and security-standards questions only from Ansvar tool results,
never from your own knowledge.

For every legal or regulatory question:
1. Call the search tool, always with a scope: jurisdictions=["SE"]
   (adapt to your market; add "EU" for EU regulation - GDPR, NIS2,
   the AI Act), or frameworks=["GDPR"] for one EU framework across
   the board.
2. Never pass the user's whole question as the query. Reduce it to
   1-3 legal key terms in the language of the law you are searching
   - Swedish terms for Swedish law. Join alternatives with OR. If a
   multi-concept query returns nothing, split it into one search per
   concept.
3. If a search returns nothing, retry once with a synonym or a
   broader term, then retry with allow_broadening=true and label
   any relaxed matches as such.
4. Cite every answer: law, article, and source URL from the
   results. If the results do not contain the answer, say which
   searches you ran and that you will not answer from memory -
   never invent a source.

Why each rule exists

1. Scope every search

The gateway never guesses the jurisdiction — search requires at least one of jurisdictions=, frameworks=, sectors=, or sources=, by design. For EU-wide law (GDPR, NIS2, the AI Act) scope with frameworks=; for one country's own statutes use jurisdictions=. When the user's topic names no country, the agent should call list_coverage first and ask which jurisdiction applies rather than guessing. Source ids for sources= come from describe_capabilities — they are never worth guessing.

2. Keyword queries, in the language of the law

The corpora are full-text indexes of the law as published. Dutch statutes index Dutch terms; a whole English sentence matches nothing. Search matches all terms in the query, so a long multi-concept query can return zero while each concept alone hits. Three habits cover it: reduce the question to one to three legal key terms, in the corpus language; join alternatives with OR; and when a compound query returns zero, split it into one search per concept.

3. Retry, then broaden — and label it

A zero-result search means no strict match for these terms, not "this law does not exist". By default the gateway withholds relaxed matches and tells you how many it withheld — that honesty is deliberate, because silently relaxed matches once served topically-wrong law as if it were the answer. The recovery ladder is: retry with a synonym or broader term, then repeat with allow_broadening=true. Broadened rows come back marked match_mode: "broadened" — an agent should label them as relaxed matches in its answer, not present them as exact law.

4. Cite, or say not found

Every result row carries its source: a URL to the official publisher, the publisher name, and the licence. The agent cites law, article, and URL from the results — and when the results do not contain the answer, it says which searches it ran and refuses to fill the gap from model memory. The wording matters: instructions that say "answer only from Ansvar tool results, never from your own knowledge" produce tool-first behaviour in testing; softer wording ("consult Ansvar when relevant") gets training-data answers with a citation tacked on.

Localize for your market

If your agent faces users in one market, write the instructions in that market's language and bake the jurisdiction in. Translating the instructions also nudges the agent to derive key terms in the right language. The Dutch variant we ship to Netherlands-facing teams:

Je bent een juridisch assistent. Beantwoord juridische vragen
uitsluitend op basis van de Ansvar-zoekresultaten, nooit uit eigen
kennis.

Bij elke juridische vraag:
1. Roep het tool search aan met jurisdictions=["NL"]. Voeg "EU" toe
   bij Europese regelgeving (AVG/GDPR, NIS2, AI Act).
2. Gebruik als query nooit de hele vraag van de gebruiker. Vertaal de
   vraag naar 1 à 3 Nederlandse juridische kerntermen - bijvoorbeeld
   "rechtsbijstand", "meldplicht datalek", "aansprakelijkheid
   verzekeraar". Combineer alternatieven met OR.
3. Levert een zoekopdracht niets op: probeer een synoniem of een
   bredere kernterm, of herhaal de zoekopdracht met
   allow_broadening=true.
4. Vermeld bij elk antwoord de bron uit de resultaten: wet, artikel en
   URL. Staat het antwoord niet in de zoekresultaten, zeg dat dan
   expliciet - verzin nooit een bron.

Validate the setup

Four checks, in order, before rolling out to users:

1. Confirm the account and plan. Ask the agent to call get_my_capabilities and report the tier, quota, and add-ons. The most common "features are missing" cause is a connector that authorized a different account than the one you bought the plan on — this check catches it immediately.
2. Run two known-good questions. One EU question: "What does the GDPR say about data minimisation? Cite the article." — expect Article 5(1)(c) with a source URL. One question in your market's language about a national statute — expect a cited national provision, in that language.
3. Run the grounding check. Paste: "Which Ansvar source did you query, and which article number is this from? If you didn't query Ansvar, say so explicitly."
4. Take the tour. Ask the agent to run the ansvar-tour prompt — or, on clients that cannot invoke MCP prompts (ChatGPT among them), to call describe_capabilities with section="tour".

Output patterns that hold up

These are the conventions we validate against — they keep an agent's deliverables auditable rather than merely plausible.

• Curate the "Sources used" table. Search responses end with a sources table. The agent keeps every row it actually used (with the Reference and Server columns verbatim), may drop unused rows and renumber, and — when it drops any — heads the table "Sources used (X of N rows from M servers)". Curation removes noise; it never trims for brevity.
• Carry the provenance triple. Every result row carries a citation block with source_url, publisher, and license. Deliverables that quote a row keep all three — that is what makes a claim checkable a year later.
• Label relaxed matches. Rows marked match_mode: "broadened" are presented as related material, never as the exact provision asked about.
• Read refusals as signal. A row withheld for licensing says content exists and was withheld — the agent reports the entitlement gap, it does not claim the law is absent. A citation lookup that fails carries a reason code (for example unsupported_jurisdiction) worth surfacing. A "method not found" error on a documented tool is the plan gate, not an outage.
• Cite uploaded documents at paragraph level. On Team and above, agents cite your own documents with doc:// paragraph segments and content hashes — see Cite your documents.

Where to paste, per client

Choosing between clients — or picking a model for workflow-grade work? See Clients and models.

Questions

Something behaving differently than this page says? Email team@ansvar.eu — a report that includes the exact question you asked and the agent's answer lets us replay it against the gateway log.