Pi by Placer.ai

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. ## When to use Questions that turn on measured physical-world behavior, e.g.: - 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, hospitality, entertainment, leisure ## When NOT to use General web lookups, company or world facts, coding, math, writing: Pi spends minutes, then declines. Send Pi only the Placer-data part of a task. ## How to use Pass the question at the scope the user asked, adding only the place, metric or timeframe when implied; extra scope costs minutes. Keep several asks in one call. "Talk to me about Lincoln Village in Chicago" → "Give me an overview of Lincoln Village Shopping Center in Chicago, IL". Returns a handle, not the answer: poll ``get_pi_result`` until it's done. ## Follow-ups Pi doesn't see earlier turns: write a self-contained ``question`` restating subject, metric and timeframe, without widening it, and pass the previous ``conversation_id`` to reuse its data. ## Personalization Pi tailors answers to the user's saved Pi profile (role, markets, standing preferences), usually flagging it ("based on your previous mentions..."). Context about the user you didn't send most likely comes from there. Put a user's correction in your ``question``; the profile itself can only be changed in the Pi web app, e.g. by telling Pi there. Uses credits; never modifies Placer 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", "done" (the answer is here), or "error". - On "working": ``progress`` (steps since your cursor, may be empty), ``progress_cursor`` (pass it back), ``poll_after_seconds``. - On "done": ``narrative`` (Pi's answer); ``analysis_notes`` (the analysis period, then caveats that qualify it); ``sources`` (web sources to cite; empty means no web was used, not that it's ungrounded); ``has_map``; ``tables`` (rows behind the answer, whole or the first rows with ``total_rows`` and ``truncated``; ``unit`` null if unknown; ``summable`` false where a sum or average is invalid); ``tables_note`` (why a table is missing or short). - ``pi_deep_link`` opens the analysis and its map in Pi. Pass ``conversation_id`` back to ``ask_pi`` (with a self-contained ``question``) for a follow-up. - ``error`` — a readable message when ``status`` is "error". Quote Pi's figures exactly; for a new total or average, ask Pi with the same ``conversation_id`` instead of computing it. Read-only: it never modifies data.

get_pi_result