[HN Gopher] Launch HN: Voygr (YC W26) - A better maps API for ag...
___________________________________________________________________
Launch HN: Voygr (YC W26) - A better maps API for agents and AI
apps
Hi HN, we're Yarik and Vlad from VOYGR (https://voygr.tech/),
working on better real-world place intelligence for app developers
and agents. Here's a demo:
https://www.youtube.com/watch?v=cNIpcWIE0n4. Google Maps can tell
you a restaurant is "4.2 stars, open till 10." Their API can't tell
you the chef left last month, wait times doubled, and locals moved
on. Maps APIs today just give you a fixed snapshot. We're building
an infinite, queryable place profile that combines accurate place
data with fresh web context like news, articles, and events. Vlad
worked on the Google Maps APIs as well as in ridesharing and
travel. Yarik led ML/Search infrastructure at Apple, Google, and
Meta powering products used by hundreds of millions of users daily.
We realized nobody was treating place data freshness as
infrastructure, so we're building it. We started with one of the
hardest parts - knowing whether a place is even real. Our Business
Validation API (https://github.com/voygr-tech/dev-tools) tells you
whether a business is actually operating, closed, rebranded, or
invalid. We aggregate multiple data sources, detect conflicting
signals, and return a structured verdict. Think of it as continuous
integration, but for the physical world. The problem: ~40% of
Google searches and up to 20% of LLM prompts involve local context.
25-30% of places churn every year. The world doesn't emit
structured "I closed" events - you have to actively detect it. As
agents start searching, booking, and shopping in the real world,
this problem gets 10x bigger - and nobody's building the
infrastructure for it. We recently benchmarked how well LLMs handle
local place queries (https://news.ycombinator.com/item?id=47366423)
- the results were bad: even the best gets 1 in 12 local queries
wrong We're processing tens of thousands of places per day for
enterprise customers, including leading mapping and tech companies.
Today we're opening API access to the developer community. Please
find details here: https://github.com/voygr-tech/dev-tools We'd
love honest feedback - whether it's about the problem, our
approach, or where you think we're wrong. If you're dealing with
stale place data in your own products, we'd especially love to hear
what breaks. We're here all day, AMA.
Author : ymarkov
Score : 56 points
Date : 2026-03-16 16:21 UTC (6 hours ago)
| il wrote:
| I like the agent-first signup via API. Is this meant to be
| distributed as an agent skill?
| ymarkov wrote:
| Indeed, in the current age we need to build things for agents
| first. We think that the skills will primarily will be
| discovered through marketplaces or via web search
| macrolet wrote:
| Who are your customers? Consumer or business?
| ymarkov wrote:
| Both - we're building APIs ultimately designed for AI agents
| and LLMs that need trustworthy place data and that includes
| cases from enterprise to personal people's agents
| acombandrew wrote:
| This is a great idea, albeit one that will be really hard to pull
| off well but really valuable for developers if you're able to
| execute.
|
| Definitely kind of a boil-the-ocean high-schlep startup but I
| would love to see this succeed.
| ymarkov wrote:
| Thanks, it is going to be fun! :)
| deepdarkforest wrote:
| Its quite funny that you are building an "infinite place
| profile", you both worked on products used by 100s of millions of
| people, and yet your website is down from 45 minutes of HN
| traffic!
|
| Joking, but its a very good idea. Synchronization between the
| physical world information and digital has been a very hard
| problem for decades and im sure an agentic approach can 10x the
| value.
| ymarkov wrote:
| Thanks! Was it truly down? I have checked and I don't see any
| disruptions
| amir_karbasi wrote:
| Really cool! We're currently using map and web searches in our
| agent to gather this info for our tool. Does it support an
| approximate address? For example, if a plaza can have multiple
| street numbers, do I need to make a request for each possible
| address or would it find a certain business with an approximate
| address?
| ymarkov wrote:
| Thanks! Our initial API works as follows - you provide
| POI/business name and its address and we are telling you if it
| exists or not. So if you are looking to check if the plaza is
| existing, you just need to provide its supposed address. If it
| is a business within plaza, then an address of that business is
| required
| amir_karbasi wrote:
| Let me rephrase my question. How exact must the address input
| be? Do I need to include unit numbers? What if the street
| number is off by a few due to the layout of a plaza?
|
| Using Maps or Web Search APIs, I can find approximate
| locations for certain businesses based on my input. Can your
| API work in a similar manner?
| ymarkov wrote:
| It is supposed to work if you even don't include unit
| number or a house number is a bit off. We analyze other
| signals too, so if the address is a bit off, the API is
| still supposed to mark a place as existing
| frankdenbow wrote:
| Implementing maps into our app so giving this a shot. How does
| pricing compare to google maps api?
| ymarkov wrote:
| It is on par with Google Maps API, but Google gives you more
| data. Our terms of service are more flexible - for instance we
| don't require attribution and deleting our data past 30 days.
| And we are actively working on adding more info to our APIs
| thesiti92 wrote:
| what kinds of data quality evals do you guys use now? i'm curious
| to try integrating it
| ymarkov wrote:
| We are using judges with LLMs and web grounding plus manual
| grading. We recently did a benchmark on the LLM quality across
| major AI providers - we plan to open source it soon and will
| probably open source our API quality check benchmark too
| https://news.ycombinator.com/item?id=47366423
| dk8996 wrote:
| We work in this space and have found that, very often, the
| realities on the ground do not match the digital information,
| especially when it comes to geospatial data, where businesses
| exist, what businesses actually exist, and their status. At
| Rwazi, we have millions of users helping collect on-the-ground
| data.
| bravura wrote:
| Bog-standard LLM mapping is terrible and I recently added Google
| Maps to my personal agent to remediate this.
|
| I'd love to try Voygr for fun. Is there a skill defined that I
| could just swap in Voygr
| ymarkov wrote:
| Google also doesn't tell you if a place exists - it just
| returns the list of possible places which it thinks could be
| relevant. We have instructions defined for agents to onboard
| https://github.com/voygr-tech/dev-tools
| maelito wrote:
| I'm not sure I understand : how can you product help for opening
| times or pictures of my local boulangerie ? What kind of data
| sources will help you automate the reviewing of its attributes ?
| ymarkov wrote:
| We are not providing opening times yet - we just check if place
| is permanently closed or not. But it is in the works under our
| experimental enrichment API (which is not yet open to public)
| wipfli wrote:
| I started scraping restaurant websites in Zurich and
| extracted and hand-checked opening hours in the OpenStreetMap
| format. The goal is to build a corpus for evaluation purposes
| which maps website texts to correct opening hours strings for
| all restaurants in Switzerland. Maybe you can use that to
| benchmark your own hours extracting system...
| https://github.com/wipfli/opening-hours/
| ymarkov wrote:
| Appreciate sharing this project - democratizing this data
| is indeed a very important step. Interesting that you
| settled on Haiku - did you have a chance to check
| flash-2.5-lite or gpt-5-nano performance?
| wipfli wrote:
| Not yet. I can ping you once I do some comparison
| teepo wrote:
| Why not go with V'ger? Seems like a missed opportunity:
| https://en.wikipedia.org/wiki/List_of_Star_Trek_characters_(...
| ymarkov wrote:
| Indeed, we've been told about that. Hopefully, it won't be a
| defining moment for us as a company :)
| gnerd00 wrote:
| I think you should market specifically to people and orgs that
| already have registered identity and location tracking of their
| movements, purchases and personal actions while on duty. Then you
| can practice your ambitious tech, but also not pull innocent
| people into more detailed tracking and analytics. Many
| occupations and orgs have already made this bargain, so stick
| with them instead of trying to get naive people to have their
| detailed movements and actions tracked. Also probably large parts
| of East Asia are doing this.
| ymarkov wrote:
| Appreciate thinking about it, but I think there's some
| misunderstanding - we don't track people or movements. VOYGR
| validates places - for instance, we are able to answer a
| question if this business still open?
| Toby11 wrote:
| what does "exist" mean in this case.. what is factored to
| determine a place exist? the building is there? people are
| speaking about it on social media? they have ad on google that
| point to the local address etc?
| ymarkov wrote:
| It means that there is sufficient evidence found online that
| this business or poi is located at that address
| tty456 wrote:
| > Their API can't tell you the chef left last month
|
| Your API can do that? Using what data?
| ymarkov wrote:
| That is our vision of where we want to be. There is a lot of
| information about the places on the public web which you
| analyze and cross-reference. And we started to solve this
| problem with validation API which can tell you if a business or
| point of interest exists at current location.
| jwelten wrote:
| Interesting approach. The annual churn stat seems brutal, I
| imagine that gets worse in certain categories (restaurants, pop-
| ups, seasonal businesses).
|
| How do you handle conflicting signals? E.g., a business shows as
| open on Google, closed on Yelp, and the website returns a 404. Is
| there a confidence score in the API response or is it binary
| (exists/doesn't)
___________________________________________________________________
(page generated 2026-03-16 23:00 UTC)