Museum & Cultural Guide Assistant

Build a conversational assistant for a museum, gallery, or cultural institution. The assistant answers visitor questions from your own content — opening hours, exhibitions, accessibility, policies — and enriches conversations with public information about artists, artworks, and history via the API Tool.

This is the lineup’s primary showcase of how to combine proprietary knowledge (your own documents) with dynamic public enrichment (an external API) in a single agent.

Reusable pattern. We’ll use Pulteney Art House, a fictional regional art museum in Bath, England, as the worked example. The same workflow applies to galleries, science museums, historic houses, archives, university museums, and any cultural institution with a defined visitor experience and a collection that benefits from external context.

What your agent will do. By the end of this guide, the assistant should handle conversations like:

• “What are your opening hours on Saturdays?” — answered from the knowledge base.
• “How much is a family ticket?” — answered from the knowledge base.
• “Tell me about Pieter de Hooch.” — Wikipedia lookup via the API Tool.
• “What’s the Cassatt exhibition about, and who was she?” — knowledge base for the exhibition details, API for biographical context, in one reply.
• “Where are you located?” — optional Show Map for a visual location pin.
• “I’d like to book a private tour for a group of 12.” — Lead Capture fires with structured fields.

Prerequisites

• A Jhunkoo.ai account and an active subscription.
• The two sample knowledge sources, hosted as public URLs (these are what you’ll attach to the agent):
  • Visitor Guide — pulteney-art-house-visitor-guide.md
  • Current Exhibitions — pulteney-art-house-current-exhibitions.md
• (Other formats of the same content) The same documents in PDF and Word. All three formats are usable as the agent’s source — we attach the Markdown in this guide because the Markdown source has image URLs the agent can resurface in chat (the PDFs and .docx files here have the images embedded as binaries instead). See the Callout below for the full picture.
  • PDFs (also usable as customer downloads):
    • pulteney-art-house-visitor-guide.pdf
    • pulteney-art-house-current-exhibitions.pdf
  • Word documents (also usable for editing in Word):
    • pulteney-art-house-visitor-guide.docx
    • pulteney-art-house-current-exhibitions.docx

No Google API key is required for this guide. Show Map (if you choose to enable it) runs on Jhunkoo’s own infrastructure; the API Tool uses Wikipedia’s public REST API, which requires no authentication.

Build the agent

You are a helpful museum assistant for Pulteney Art House in Bath, England. You help visitors plan their visits, answer questions about our exhibitions and collection, and provide background on the artists and works in our care.
 
Be warm, knowledgeable, and unhurried — like a thoughtful gallery steward. Answer questions about the museum from the information you have been given. For background questions about artists or art history, you may look up public information.

Search for information specifically about Pulteney Art House — our opening hours, ticket prices, memberships, accessibility, café and shop, family and school visits, group bookings, current and upcoming exhibitions, our history, and our policies. Use this tool whenever a visitor asks about the museum, our exhibitions, our collection's holdings on display, or anything else specific to our operations.

Look up a short, factual summary of a topic from Wikipedia. Use this for biographical context on artists, descriptions of art movements and periods, historical figures, places, and any widely-documented public-knowledge topic. Returns a paragraph of plain-text summary and, when available, an image URL.

https://en.wikipedia.org/api/rest_v1/page/summary/{title}

{
  "title": "wikipedia_summary",
  "description": "Look up a short, factual summary of a topic from Wikipedia. Use this for biographical context on artists, descriptions of art movements and periods, historical figures, places, and any widely-documented public-knowledge topic. Returns a paragraph of plain-text summary and, when available, an image URL.",
  "method": "get",
  "url": "https://en.wikipedia.org/api/rest_v1/page/summary/{title}",
  "headers": [
    {
      "key": "User-Agent",
      "value": "PulteneyArtHouseBot/1.0 (https://www.pulteneyarthouse.example; [email protected])"
    }
  ],
  "params": [
    {
      "type": "string",
      "key": "title",
      "description": "The Wikipedia page title to look up. Use the canonical English Wikipedia title — e.g. 'Pieter de Hooch', 'Mary Cassatt', 'Impressionism'. Spaces are accepted.",
      "defaultValue": "",
      "required": true
    }
  ],
  "query": [],
  "body": [],
  "auth": { "type": "none" },
  "timeout": 30
}

You are a helpful museum assistant for Pulteney Art House in Bath, England. You help visitors plan their visits, answer questions about our exhibitions and collection, and provide background on the artists and works in our care.
 
## Tone
 
Be warm, knowledgeable, and unhurried — like a thoughtful gallery steward. Match the voice of our visitor guide and exhibitions content: factual, generous with context, never breezy or salesy. We're a small museum that takes its visitors seriously.
 
## When to use the knowledge base
 
For any question specifically about Pulteney Art House — opening hours, ticket prices, concessions, memberships, accessibility, café, shop, family activities, schools programmes, group bookings, current or upcoming exhibitions, our history, photography rules, anything in our published guide — call the `search_knowledge_base` tool before answering. Do not answer questions about the museum from general knowledge.
 
If the knowledge base returns no results for a museum-specific question, say you don't have that information and offer to put the visitor in touch with the team ([email protected], +44 1225 000 000).
 
## When to use the Wikipedia API
 
For background questions about artists, art movements, periods, historical figures, places, artworks by name, or any widely-documented public-knowledge topic, call the `wikipedia_summary` tool with the most appropriate Wikipedia page title.
 
Use plain canonical English Wikipedia titles. Examples:
 
- _"Who was Pieter de Hooch?"_ → call `wikipedia_summary` with title `Pieter de Hooch`.
- _"What is Impressionism?"_ → call `wikipedia_summary` with title `Impressionism`.
- _"Tell me about the Rosetta Stone"_ → call `wikipedia_summary` with title `Rosetta Stone`.
 
If the Wikipedia API returns no result (a 404 or empty summary), tell the visitor you don't have information on that topic. **Do not retry with variations or guess.** Suggest they ask the team directly if it's important for their visit.
 
When the Wikipedia response includes an image URL, include that image in your reply using standard Markdown image syntax. Do not invent image URLs.
 
## Combining the two
 
Some questions need both. For example: _"What's the Northern Light exhibition about, and who was Pieter de Hooch?"_ — the exhibition details come from the knowledge base, the artist background from Wikipedia. In your reply, lead with the museum-specific information (because that's what the visitor came to us for) and bring in the public-knowledge context as enrichment.
 
Never present Wikipedia information as if it were our own curatorial position. Words like _"according to public sources"_ or _"in general"_ signal that you're drawing on external information; phrases like _"in our collection"_ or _"in this exhibition"_ are reserved for content from the knowledge base.
 
## When to capture a lead
 
Call the `lead_capture_tool` only when the visitor expresses clear intent to be contacted or to book something the assistant can't complete — private tours, school visits, group bookings, membership enquiries, accessibility arrangements, or curatorial questions about specific works. Do not capture leads when the visitor is browsing or asking general information questions.
 
When the visitor agrees to be contacted, collect their name and email at minimum. If the conversation has already revealed the enquiry type, group size, or preferred dates, include those — but do not interrogate the visitor for fields they haven't volunteered.
 
## When you don't know
 
If a visitor asks about something we explicitly cannot help with — processing ticket payments through chat, confirming whether a specific work is on display today, providing valuations, reserving café tables — explain that those go through the team directly and offer the appropriate contact (per the visitor guide's "what we can't help with" section).
 
## Formatting
 
Use Markdown. Lead with the direct answer. Include images from the knowledge base or from Wikipedia API responses when they exist; never invent image URLs.

How the assistant decides what to retrieve

This is the pedagogical core of the guide — the pattern you can lift into any cultural-institution build, regardless of which specific APIs you wire up.

The assistant has two distinct sources of information, and the instructions above teach it when to use each:

Three things make this composition work:

1. The knowledge base “wins” for institutional questions. The instructions explicitly say “do not answer questions about the museum from general knowledge” — the agent won’t pretend Wikipedia knows our ticket prices.
2. The API “wins” for context questions. Conversely, the instructions don’t let the agent fabricate facts about an artist from training data — it’s required to look them up.
3. The voice stays consistent across both. Phrases like “according to public sources” signal the source without breaking character.

The reusable principle: knowledge base for the institution’s own voice, external API for everything outside it. This pattern generalises to bookshops (KB for stock and events, API for book metadata), restaurants (KB for menu and reservations, API for ingredients or wine pairings), and any operator whose own content is one part of a larger conversational landscape.

Configure each tool

Each tool below has a focused subsection. Skim to the ones you have questions about.

Knowledge base

Two URL sources form the agent’s single source of truth for institution-specific content:

• Visitor Guide — opening hours, tickets, memberships, transport, accessibility, café, shop, families, schools, group bookings, house rules, history.
• Current Exhibitions — what’s on now, what’s coming next, past exhibitions list, practical exhibition notes.

Why two sources, not one? Splitting visitor information from exhibition content improves retrieval. A question about “how much is a family ticket” pulls from the visitor guide alone; a question about “what’s in the Cassatt exhibition” pulls from exhibitions alone; “what time is the Cassatt exhibition open on Sundays?” pulls from both. Each source can be updated independently as content changes — exhibitions rotate more often than visitor policies.

Why Markdown, not PDF? PDFs are great for human readers, but PDF→text extraction frequently strips markdown image URLs, breaks tables into unreadable spans, and injects page-footer noise. The Markdown source preserves all of that cleanly. The PDFs are still useful — visitors can download them — but the agent reads from Markdown.

Wikipedia API Tool (the primary lesson)

The single API tool we configured does a lot of work. Here’s what to know about it.

What it returns. A successful call returns a JSON object with these fields the agent uses:

• extract — the plain-text summary (typically 2–4 sentences)
• description — a short one-line description
• thumbnail.source and originalimage.source — image URLs, when the page has one
• content_urls.desktop.page — the link back to the full Wikipedia page

The model surfaces the extract and (when present) the image. It can also offer the visitor a link to the full Wikipedia page if they want to read more.

404 handling. Wikipedia is unforgiving about page titles. “Pieter de Hooch” works; “Pieter De Hooch” or “Pieter Hooch” may not. The instructions tell the agent to give up honestly rather than retry with variations. That’s a deliberate teaching point — API Tools aren’t magic, and graceful failure beats clever guessing.

Image rendering. Wikipedia’s response includes a thumbnail.source URL. When the agent surfaces this in a Markdown image tag, the chat widget renders the image inline. This is what gives the assistant its “richer than a chatbot” feel. The instructions tell the agent to use the URL from the API response — never to invent one.

Rate limits. Wikipedia’s REST API is generous (no per-user limit for low-volume use), but they ask all API consumers to identify themselves via the User-Agent header. The configuration above does that. If you fork this for your own institution, update the User-Agent to identify your organisation.

Cost. Free. The Wikipedia API is open and unauthenticated for read access. Calls don’t accrue any third-party cost to you or to Jhunkoo. (The agent’s LLM tokens are billed normally; the API call itself is free.)

Lead Capture

The built-in contact fields (name, email, phone) plus the custom fields (Enquiry Type, Group Size, Preferred Date, Notes) give the museum’s team enough to follow up usefully without interrogating the visitor.

Each chat session produces one lead. If the agent calls the tool more than once in the same conversation, the existing lead is updated rather than duplicated, and custom field values are merged so an earlier partial capture is never lost. Two separate conversations create two separate leads. See Lead Capture for the full mechanics.

Where leads land. Captured leads appear in the agent’s Leads view in your Jhunkoo dashboard (/agents/[agentId]/leads). You can export them as CSV or wire the export to a CRM, Google Sheets, or your team’s inbox using your own workflow.

Show Map (optional)

If enabled, this surfaces a visual map of the museum’s location when a visitor asks “where are you?” or “how do I get there?”. No configuration; the tool runs on Jhunkoo’s own infrastructure with no API key.

This is a small visual enhancement — useful if your institution gets visitors who travel to see you, optional otherwise.

Test in the studio

Use the chat panel on the right of the agent configuration page. A test script that exercises every capability:

1. Pure knowledge base. “What are your opening hours on Saturdays?” — must come from the knowledge base, not the API.
2. Knowledge base — exhibitions. “What’s the Northern Light exhibition about?” — KB retrieval; agent should also surface the exhibition’s image.
3. Pure Wikipedia API. “Who was Mary Cassatt?” — must call wikipedia_summary; agent should return a paragraph of context and the Wikipedia portrait image.
4. Composed (KB + API). “What’s the Cassatt exhibition about, and who was she?” — knowledge base for the exhibition, API for biographical context, in one reply.
5. Composed (KB + multiple API calls). “Tell me about Pieter de Hooch and Gerard ter Borch — I saw them mentioned in your Northern Light exhibition.” — KB confirms the exhibition; the agent makes two API calls for the artists.
6. Wikipedia 404 handling. “Tell me about Pieter Hooch.” — Wikipedia 404s on this title. Agent should say it doesn’t have information, not retry with variations.
7. Honest “no” — KB only. “Can I reserve a table in the café for Saturday lunch?” — KB explicitly says we can’t, agent should explain and offer the contact for arrival timing.
8. Lead capture. “I’d like to bring a Year 5 class of twenty-eight pupils for a curator-led session in November.” — agent should collect at minimum name and email, ideally also enquiry type, group size, preferred date.
9. Show Map (if enabled). “Where are you?” — agent should call Show Map with the museum’s address.

If any answer is wrong or off-brand:

• Wrong museum-specific answer. Confirm both knowledge sources finished Training in the Knowledge tab.
• Agent answered about the museum without checking KB first. Re-read the “When to use the knowledge base” section of the instructions — the rule needs to be explicit and the agent needs to be told not to answer institutional questions from general knowledge.
• Agent invented Wikipedia information. Re-read the “When to use the Wikipedia API” section. The rule needs to require an API call, and the failure case needs to be an honest “no”, not a guess.
• Wikipedia API call returned a 404 and the agent retried with variations. Add the explicit “do not retry with variations” line if it’s been edited out.
• Image didn’t render. Confirm the agent included a markdown image tag with the URL from the Wikipedia response. Look at the raw API result in the chat trace to confirm the image URL was present in the response.
• Lead capture fires too early. Tighten the “clear intent” language in the instructions; add explicit “do not capture while the visitor is browsing” guidance.

Publish and embed

1. Use the publish control at the top of the agent page to make the agent live.
2. Open Settings → Client settings and set Origin to the institution’s site (e.g. https://www.pulteneyarthouse.example).
3. Open Client script to copy your publishable key and the install snippet.
4. Follow the Widget guide to embed the chat widget on the site.

What you built

A working assistant that:

• Answers visitor questions from the museum’s own content (visitor guide + exhibitions)
• Looks up artists, art movements, places, and historical context on Wikipedia at the moment the visitor asks
• Surfaces images from both the knowledge base and the API response
• Knows the difference between “what we publish” and “what’s publicly documented”
• Knows when it can’t help and routes the visitor to the team
• Captures structured leads only when the visitor expresses real intent

The same pattern adapts to any cultural institution — galleries, science museums, historic houses, university archives, libraries. Replace the two source documents with your own, configure the API Tool against whichever public knowledge source fits your domain (Wikipedia for art and history; Open Library for bookshop catalogues; PubMed for medical content; or your own published API for anything specific to your sector), and the rest of the structure stays the same.

Next steps

• API Tool reference — full schema, authentication patterns, and configuration tips.
• Lead Capture — full reference for fields, dedup, and the leads dashboard.
• Knowledge tool — multi-source retrieval, RAG behavior, and best practices for content structure.
• Widget guide — install the chat widget on the institution’s site.
• Prompt Builder — form-driven alternative to hand-writing the instructions above.
• FAQ — billing, limits, troubleshooting.

Disclaimer: The institution, exhibits, and supporting materials in this guide are fictional and created solely for demonstration purposes. Any resemblance to real organisations or historical details is unintended.

Portions of the example assistant use data retrieved from the Wikipedia REST API for demonstration purposes.

Sample images are sourced from Unsplash (under the Unsplash License) and Wikimedia Commons, including public-domain artwork by Mary Cassatt.