KindLink

Inspiration

Small nonprofits get maybe one big fundraiser a year, and they usually can't afford an event planner. So they guess: a hotel ballroom, a generic silent auction, whoever's free to play. When they ask an AI chatbot for help, it sounds confident but gives vague answers ("a local independent bookstore") or names that may not even exist.

The real question behind a good fundraiser is cultural: what do this cause's supporters actually love? That's exactly what LLMs can't know, and exactly what Qloo's taste graph does. KindLink started from that gap.

What it does

A nonprofit describes its cause, city, guest count, budget and a few general supporter interests (no donor data, ever). KindLink's agent then builds a complete, evidence-backed event plan:

• Supporter taste profile: the Qloo taste tags and entities that define the cause's audience
• Venues in the city, ranked by Qloo affinity and screened for event suitability
• Performers matched to supporter taste and filtered to the budget's popularity band
• Sponsors: local businesses and brands whose customers overlap with the supporters
• Neighborhoods: a Qloo heatmap of where supporters are, shown in 2D and 3D
• Promotion: podcasts and TV shows whose audiences overlap
• Concept, run of show, and a ready-to-send sponsor pitch letter for any sponsor
• A side-by-side comparison with a generic LLM plan made from the same inputs with no data
• A full audit trail of every decision the agent made

Every recommendation shows its evidence: the Qloo signal used and the affinity or popularity score. Nothing is invented: the LLM writes the concept and copy but can only name entities Qloo returned, and a grounding check removes anything else before the user sees it. If Qloo doesn't have enough data for a section, KindLink says so instead of guessing.

How we built it

• Agent pipeline (FastAPI, Python): 11 steps, streamed live to the UI. It understands the cause, finds and tests taste tags, resolves supporter interests, scouts venues, performers, sponsors, neighborhoods and promotion in parallel, writes the plan, verifies every name, and drafts a no-data baseline for comparison.
• Qloo API: entity search, tag search, Insights across places, artists, brands, podcasts and TV shows, and the heatmap endpoint for neighborhoods. The agent tests its own tag choices against live Qloo rankings and switches or drops tags that don't produce a real signal.
• LLM layer: OpenRouter free models, used only for reasoning and writing. Picks are passed as short IDs, and the output is validated in code against the Qloo result set.
• Reliability: every Qloo call is cached for 7 days, rate-limited to 4 requests per second with retry and backoff, and each step has a timeout and a graceful fallback.
• Frontend (Next.js, TypeScript, Tailwind): a live progress view, plan tabs, a Leaflet/MapLibre map with 3D heatmap columns, a shareable sponsor pitch page, and a markdown brief export.
• Hosting: Railway (frontend, backend and Postgres).

Challenges we ran into

• Keeping the LLM honest. Free models love to invent plausible venues. We built a grounding check that verifies every name against the Qloo results and strips anything unverified, plus tests for it.
• Choosing the right taste signal. Broad tags give flat, meaningless rankings. The agent now tests candidate tags live and only keeps the ones that actually rank things.
• Qloo quirks. Artist insights ignore the city filter, so performers are matched on taste and the plan says so openly. Some signals saturate affinity, so we fall back to ranking by popularity.
• Slow free LLMs. They sometimes time out mid-run. Each step gets a time budget, and when the model is too slow, it falls back to rule-based screening rather than losing the section.

Accomplishments that we're proud of

• A plan where every single name is traceable to a Qloo response, with the score to prove it.
• The Generic AI vs KindLink comparison makes Qloo's value obvious at a glance: vague or unverifiable picks on one side, specific and scored picks on the other.
• An agent that corrects itself, testing and discarding its own choices, and is transparent about it in the audit trail.
• Honest empty states: "not enough data" is a feature, not a failure.

What we learned

• Cultural grounding is the difference between an answer that sounds right and one you can actually act on.
• Agents need guardrails in code, not just in prompts. Validation after generation is what makes "no hallucinations" a real guarantee.
• Showing the evidence builds trust. Users care as much about why a pick was made as the pick itself.

What's next for KindLink

• Contact and booking details for venues and performers, so a plan turns straight into outreach
• Tracking sponsor responses and ticket sales against the plan
• Learning from past events which picks actually drew a crowd
• Support for more cities and languages, and recurring events like galas, runs and community days

Built With

• fastapi
• httpx
• leaflet.js
• lucide-react
• maplibre
• next.js
• node.js
• openrouter
• openstreetmap
• postgresql
• pydantic
• pytest
• python
• qloo
• railway
• react
• tailwind-css
• typescript