-
The same dog in Park Slope and Astoria: each area gets its own names, each labelled with the Qloo title it comes from.
-
Places to ask near the shelter: Qloo's rank first, then why Namesake's AI picked it, on a map of where pet-title fans stand out.
-
The result: name options labelled with their Qloo titles, a Generic / Local toggle, and a listing written only from recorded facts.
-
How Namesake made this: what Qloo returned, kept apart from what Namesake's AI did with it and what code checked.
-
Start: pick a shelter area and an animal, add your own, or open one of five finished stories. Photos are AI-generated.
Inspiration
Shelter volunteers write a listing for every animal, usually in a hurry, and AI bio writers are already everywhere. None of them has evidence that it helps, and one is known for inventing backstories.
So before writing any code, I read the research. No study shows that a name speeds up adoption. What does measurably hurt is overselling: adopters who found a dog harder than expected were about ten times as likely to return it. What helps most is being seen, in person and through people's own networks. And nobody had tested whether local taste data helps at all.
That set the goal: listings that stick to the facts, carefully screened names, and using Qloo for what it can plausibly do, finding the people and places near a shelter who care about pets.
What it does
A volunteer picks an animal and the shelter's area. In about a minute for an area it already knows (a few minutes for a new one), Namesake's AI produces:
- a listing written only from the shelter's recorded facts, with a bite history always stated (one of the five finished examples has one)
- name options from Qloo taste data: pet-themed shows and films popular near the shelter, each name labeled with what Qloo returned and screened for villains, tragic characters, real people, and coded references
- a plan to get the animal seen: local places within 5 km of the shelter that fans of those titles favor (never a national chain or a theme park), on a map, plus foster networks, outings (or a quiet meeting when the record says busy places are hard) and timing
A Generic / Local toggle shows the listing with and without Qloo, so you can see exactly what Qloo adds; when Qloo's data for the area doesn't back a name's title, the button says With Qloo instead of Local. A Why drawer keeps what Qloo returned separate from how the app read it. Refine, edit, approve, copy, or print a flyer.
How we built it
Two PydanticAI agents do the open-ended work. One finds pet-themed titles popular in the area, settles which Bluey is meant, ranks them, and asks Qloo for places their fans go. The other writes the listing and the names. Plain code makes the fixed Qloo calls and checks everything the agents return: every title and place must come from Qloo, every bio sentence must trace to the recorded facts, and every name must pass the screen. A draft that fails gets one repair round, then falls back to a template.
It's FastAPI and Jinja, Leaflet for the map, SQLite caching every Qloo answer, and one Docker image on a VM. AI agents built and reviewed it under my direction: one wrote the code, and two or three other models reviewed every change before it merged.
Challenges we ran into
Most of them came from the data. Qloo's pet tags left almost nothing when used as filters, but worked well as signals. Names were ambiguous: 6 of 10 titles came back with several candidates, and a bare "Portland" resolves without saying which one. Popular isn't the same as pet-loving: 9 of the first 15 venues near Park Slope also came back for Yellowstone, so we now compare every place with what the neighborhood watches anyway. Name screening was subtler than expected: famous animals that die in their story, and reality shows whose "characters" are real people.
Accomplishments that we're proud of
- The Generic / Local toggle answers "would this work the same without Qloo?" on the result screen itself.
- What Qloo returned is never blended with the app's interpretation of it.
- The listing is held to the record by code, not by the model's good intentions.
- The claims stay within the evidence, and the app records what a real trial would need.
What we learned
Read the evidence first; it changed what I built. Qloo's signal is in order and comparison, not raw scores, which saturate near 1.0. Always check what the API actually heard, because Qloo quietly ignores parameters it doesn't recognize. An agent earns its place where the answers are ambiguous; everywhere else, plain code is cheaper and safer. And in this domain, the riskiest thing an AI writer can do is be warm and wrong.
What's next for Namesake
- Run the trial: randomize generic against local listings at intake and measure days to adoption, with returns as a safety check. It needs about 190 adoptions, so a network of rescues rather than one shelter.
- A cheap test before the trial: ask people who live near a shelter whether they recognize the titles Qloo picked for their area. If they don't, local names can't help, and the big trial isn't worth running.
- Paste straight into shelter software, where listings go out to every adoption site.
Built With
- carto
- claude
- codex
- deepseek
- docker
- fastapi
- github-actions
- javascript
- leaflet.js
- muse-spark
- openstreetmap
- pydantic-ai
- python
- sqlite
- uv
Log in or sign up for Devpost to join the conversation.