The "type absence — ok/absent/failed instead of a plausible null" decision is the right call and under-appreciated. I run a large multi-agent setup and the failures that cost me most weren't wrong answers, they were confident answers over gaps the model should have refused. Curious how you handle it when two sources disagree rather than one being absent — do you surface both with provenance and let the agent decide, or pick a winner server-side?
Awesome work. If I understand correctly, your service essentially runs a bunch of web agents to maintain this dataset and keep it up to date and accurate, and we access through your API / MCP?
the problem usually isn’t missing facts. it’s that null means different things in different counties — no flood map vs no flood risk, wrong parcel, owner fields that don’t map cleanly.
if the API returns absent/failed instead of making the model guess, that’s actually a really good design choice.
curious how often those cases show up on normal residential parcels vs the messier commercial/infill sites.
in our fetch api every field comes with ok / absent / failed. it never returns a bare null and lets you/your agent assume. credit is not charged in case the api returns absent value.
for ask api, the null is shown to the model as value: NULL plus an instruction — "acknowledge the gap explicitly. do not state, estimate, or infer a value for it from general knowledge or from the coordinate." so models never make any data up.
empty fields are rare on houses and commercial lots (~5%) and common on rural land (~29%), but on rural land empty usually means "nothing's there," while on houses and lots it usually means "the county didn't publish it.
It would be good to also have a non-LLM version of the pitch, for some people building in the space it's a bad signal. It's associated with zero value "let my agent build something over the weekend" projects that all make these grandiose claims.
per-field freshness is the failure mode here, not coverage. blend sources and one record ends up with hours scraped last night sitting next to a phone number nobody has rechecked in two years
The "type absence — ok/absent/failed instead of a plausible null" decision is the right call and under-appreciated. I run a large multi-agent setup and the failures that cost me most weren't wrong answers, they were confident answers over gaps the model should have refused. Curious how you handle it when two sources disagree rather than one being absent — do you surface both with provenance and let the agent decide, or pick a winner server-side?
Awesome work. If I understand correctly, your service essentially runs a bunch of web agents to maintain this dataset and keep it up to date and accurate, and we access through your API / MCP?
Thank you! and correct, we have long running agents that Source → Crawl → Evaluate → Index → Retrieve → Contract this data.
O(1 crawler) for the web vs O(fields × jurisdictions) for real-world data. So we have to build a lot of unique crawlers.
the problem usually isn’t missing facts. it’s that null means different things in different counties — no flood map vs no flood risk, wrong parcel, owner fields that don’t map cleanly.
if the API returns absent/failed instead of making the model guess, that’s actually a really good design choice.
curious how often those cases show up on normal residential parcels vs the messier commercial/infill sites.
in our fetch api every field comes with ok / absent / failed. it never returns a bare null and lets you/your agent assume. credit is not charged in case the api returns absent value.
for ask api, the null is shown to the model as value: NULL plus an instruction — "acknowledge the gap explicitly. do not state, estimate, or infer a value for it from general knowledge or from the coordinate." so models never make any data up.
empty fields are rare on houses and commercial lots (~5%) and common on rural land (~29%), but on rural land empty usually means "nothing's there," while on houses and lots it usually means "the county didn't publish it.
It would be good to also have a non-LLM version of the pitch, for some people building in the space it's a bad signal. It's associated with zero value "let my agent build something over the weekend" projects that all make these grandiose claims.
per-field freshness is the failure mode here, not coverage. blend sources and one record ends up with hours scraped last night sitting next to a phone number nobody has rechecked in two years
311 of 317 fields get queried and no use case dominates. that's when the app dies and the engine ships.
[dead]
[dead]