[Title is rage bait]

TL;DR — We can simply offer agentic workflow by uploading alarms information to a public GPT, and add a chat interface on top. We then add Yad2 for rent + Mamad (saferoom) data and let people search “houses for rent + saferoom in places in south of Israel with less alarms” — and this is real agentic workflow.

ICBMs GPT — chat interface returning 20 apartments under ₪7,000 in the cities with the fewest alarms

Try it yourself: ICBMs GPT — טילים בליסטיים גיפיטי


What “agentic” actually means in practice

The industry calls a lot of things agentic. Multi-step LLMs with tools. Self-orchestrating workflows. ReAct loops. CodeAct. Anything with a planner module.

But for an end user, “agentic” should mean exactly one thing: a natural-language interface over a dataset they couldn’t query before. No SQL. No clicking through eight filters on a real-estate listing site. No cross-referencing three open tabs.

The framing problem isn’t the LLM. The framing problem is the dataset.

The Israel example

Take three public-ish datasets that exist today:

  1. Real-time alarm data for Israel — historical and live, by region and time of day.
  2. Yad2 — the dominant Israeli classifieds site for rentals.
  3. Mamad data — which apartments have a saferoom, by building or street.

Individually each is a SQL table or a scraping target. Combined, in natural language, they become:

“Show me 3-bedroom apartments under ₪7,500 in the south with a saferoom, in cities with fewer than 5 alarms per month over the last year.”

That query is impossible in any existing UI. It requires:

  • Geographic filtering (south of Israel)
  • Cross-reference of alarm counts per municipality
  • Time-window aggregation (per-month, last 12 months)
  • Two-column join (alarms × listings × mamad)

A chat interface over an LLM with these three datasets as context (or as tool-calls) collapses 30 minutes of cross-referencing into 30 seconds. That’s the agentic workflow.

Why this is “headless”

The interesting design decision is what the agent isn’t doing.

  • It’s not building a custom UI per query.
  • It’s not generating a dashboard.
  • It’s not running a complex planner.

It’s exposing one input box, one output. The “agent” is the dataset wiring + a chat completion. The orchestration is hidden — that’s the headless part.

This is the form factor that scales. Every dataset that someone cares about deserves a chat interface like this.

What ICBMs taught me

The original framing — what got me thinking about this — is that the same week ICBMs were flying overhead, people were still trying to rent apartments. The cognitive load of “is this safe to live in?” is a real, recurring query. No real-estate site answers it. No government site answers it. A 30-minute chat interface over public data answers it.

That generalises:

  • Crime + housing for any city.
  • Air quality + schools in any country with sensor data.
  • Inspections + restaurants in cities with public health-code data.
  • CVE feeds + your S3 buckets for security.

The pattern is always the same: a domain expert knows what query they want to ask, the datasets exist, no UI exposes both at once. An LLM + a chat box closes the gap.

What an MVP looks like

  • One landing page.
  • One chat input.
  • Three datasets in the system prompt (or as retrieval tools).
  • One model — GPT-class is fine.
  • No accounts. No auth. No persistence beyond a session.

That’s a real agentic product. Not a planner. Not a multi-tool ReAct loop. A chat interface over a dataset that someone could not previously query.

The rest is just sales.