Problem

Generic agents are culturally blind. They can translate "gift ideas for a Japanese colleague" into Japanese and still recommend the wrong gifts. Language is solved; taste is not. For 30+ Asian and global locales, wrong food, gift, and weekend advice is the difference between technically functional and actually good.

Product

AgentAsia is a multi-locale personal AI (language wheel, 30+ UI languages, slogan "AI that speaks your language"). Culture Companion is the Qloo layer: before recommending dining, gifts, travel, music, film, or lifestyle, the agent calls Qloo's taste graph so advice matches local culture.

Demo prompts that only work with Qloo:

  • "Plan a weekend in Bangkok for my parents" (Thai destinations + dining + places)
  • "What should I cook for a Khmer family gathering?" (Khmer cuisine, family dining)
  • "Gift ideas for a Japanese colleague" (Japanese brands + lifestyle fit)
  • "What are teens in Jakarta into right now?" (Indonesian music + audience lifestyle)

Remove Qloo and these become generic lists. That is the differentiator.

Qloo integration (workflows and why)

We use Qloo as a first-class agent tool, not a one-off API call:

  1. Locale profile maps the user's language (km, ja, hi, th, id, fil, ko, zh-CN, ...) to cultural seeds: region, cities, dining, music, film, lifestyle, gift ideas.
  2. Tag and entity resolution through Qloo /v2/tags and /search (same concepts as the kit find_tags / search workflows) so we never hardcode taste IDs.
  3. Insights through Qloo /v2/insights with signal.interests.tags, signal.interests.entities, and type-specific filters (urn:entity:place, destination, brand, artist, movie, ...).

The agent exposes this as cultural_insights(locale, intent, query) and is instructed to call it before lifestyle recommendations. The Qloo key never reaches the browser: it lives on the AgentAsia gateway (POST /v1/culture), metered like search.

This matches the kit rules: keep the key on the server, send no personal data to Qloo, and treat results as group affinities (never as one person's profile).

Redacted request to result

Request (locale=km, intent=dining, query="Khmer family gathering"):

  1. Resolve tags for "Khmer cuisine", "family gatherings", "Phnom Penh", "fish amok".
  2. Resolve entities for those seeds.
  3. GET /v2/insights?filter.type=urn:entity:place&signal.interests.tags=...&filter.location.query=Phnom Penh
  4. Agent answers in the user's language, naming real places and dishes from the Qloo result set.

Same shape for Thai weekend travel (destination), Japanese gifts (brand), Jakarta teen culture (music + lifestyle intents).

Setup (clean environment)

  1. Clone https://github.com/jamesparser/agentasia-qloo
  2. npm install
  3. Gateway env: QLOO_API_KEY, QLOO_BASE_URL=https://hackathon.api.qloo.com
  4. Run the Vite frontend and server gateway
  5. Optional harness: npm i -g @qloo/qloo-harness && qloo setup --qloo && qloo exec find_tags --input-file request.json

Known limitations

  • Qloo results describe what groups tend to like, not what one person will do. The agent never claims personal preference.
  • Hackathon keys only work against https://hackathon.api.qloo.com
  • Coverage varies by region; some locales have stronger dining/place coverage than media.
  • Without QLOO_API_KEY the tool fails closed (qloo_not_configured); it never fabricates taste data.

Judging fit

  • Technological Implementation: real Insights + tag/entity resolution in the agent loop
  • Design: culture is a first-class axis, same as language
  • Potential Impact: SE Asia + diaspora get family, food, gift, festival advice that fits
  • Quality of the Idea: language alone is not Qloo; language + taste graph is a non-obvious general-agent use case

License: MIT. Public repo: https://github.com/jamesparser/agentasia-qloo

Built With

Share this project:

Updates

Submission history