Placer.ai Pi

Ask Pi — Placer.ai's analytical intelligence for the physical world. Pi turns measured real-world behavior into decisions, grounded in Placer data: foot traffic, visitor demographics and journeys, trade areas, cross-shopping, sales/spend, and more. Placer's data is its ground truth: foot traffic, visitor demographics and journeys, trade areas, cross-shopping, sales/spend, and more — an expanding set of physical-world datasets that reveal how people move through and interact with places. ## When to use Questions that turn on measured physical-world behavior and serve operators across the physical economy — including: - **Retail & restaurant brands** — store and portfolio performance, trade-area and site analysis, competitive benchmarking, cannibalization, white-space - **Commercial real estate** — site selection, tenant mix and co-tenancy, valuation and underwriting support, market feasibility - **Civic & economic development** — public-space utilization, demographic and mobility trends, development impact - **Finance, advertising, and beyond** — due diligence, category performance, market-share tracking, and other physical-economy use cases (hospitality, entertainment, leisure, consulting) ## When NOT to use Anything outside location intelligence — general web lookups, company or world facts, coding, math, or writing. Pi will spend minutes and then decline; handle those with your own tools and call ask_pi only for the Placer-data part of the task. ## How to use Give Pi the whole business question in one call; it runs a complete analysis and can take a few minutes, so ask once, fully — don't split one analysis across many narrow calls. ## Getting the answer — you MUST poll ask_pi does NOT return the answer. It starts the analysis and returns a handle immediately with ``status: "working"``. To get the answer, call ``get_pi_result`` with the ``conversation_id`` and ``message_id`` from this response, waiting ``poll_after_seconds`` between calls. Keep calling it while it returns ``status: "working"`` — a full analysis normally takes several minutes and many polls. Do not report back to the user, answer from your own knowledge, or give up while the status is still "working"; the analysis is running. ## Follow-ups Pi does not remember the earlier turn's wording, so ALWAYS write a self-contained ``question`` — restate the subject, metric, and timeframe instead of saying "that" or "the same". Pass the previous answer's ``conversation_id`` so Pi reuses the data it already pulled (same numbers, no re-discovery). The id carries the DATA forward; your question must carry the CONTEXT. Omit ``conversation_id`` for a fresh, standalone analysis. ## Returns A handle to poll, not the answer. - ``status`` — "working": the analysis has started and is running. - ``conversation_id`` — this analysis's conversation id. Pass it to ``get_pi_result``; open it via the deep link; and pass it back (with a self-contained ``question``) to ask a follow-up once the answer is in. - ``message_id`` — this specific analysis. Pass it to ``get_pi_result`` alongside the ``conversation_id``. - ``poll_after_seconds`` — how long to wait before the first ``get_pi_result`` call. - ``pi_deep_link`` — opens the analysis, with the interactive map, in Pi. Read-only: Pi analyzes and reports; it never modifies data.

ask_pi

Collect the answer from an analysis started by ``ask_pi``. ## When to use After every ``ask_pi`` call, and after every ``get_pi_result`` that comes back ``status: "working"``. This is the ONLY way to read a Pi answer. ## How to use Wait ``poll_after_seconds`` from the previous response, then call this with the ``conversation_id`` and ``message_id`` you were given. Pass back the ``progress_cursor`` from the previous "working" response so you only receive the steps you haven't seen yet. Keep polling while ``status`` is "working". A full analysis normally takes several minutes, so expect many polls; each call waits for a while before answering, so a poll loop is cheap. Do NOT stop early, substitute your own knowledge, or tell the user Pi failed while the status is still "working". After each "working" poll, tell the user in ONE short sentence what Pi is doing, in your own words, from the newest ``progress`` lines — never show the raw JSON. Stop only on "done" or "error". ## Returns - ``status`` — "working" (still running), "done" (the answer is here), or "error". - ``progress`` — on "working": the analysis steps since your ``progress_cursor`` (may be empty). - ``progress_cursor`` — on "working": pass this back on the next call. - ``poll_after_seconds`` — on "working": how long to wait before calling again. - ``narrative`` — on "done": Pi's written answer. - ``analysis_notes`` — on "done": data-honesty caveats that qualify the answer, e.g. a missing-data disclosure (may be empty). - ``sources`` — on "done": web sources the answer drew on, a list of ``{ordinal, type, url, title, cited_text}`` (type is web_search or web_fetch) to cite and verify web claims. Empty when no web was used — not a sign it's ungrounded; Placer grounding lives in the narrative and the deep link. - ``has_map`` — on "done": whether the analysis produced a map. - ``pi_deep_link`` — opens the analysis, with the interactive map, in Pi. - ``conversation_id`` — pass it back to ``ask_pi`` (with a self-contained ``question``) for a follow-up that reuses this analysis's data. - ``error`` — a human-readable message when ``status`` is "error". Read-only: this reads an analysis's state; it never modifies data.

get_pi_result