SitePilot

• 

  Cover

• 

  Site

• 

  Dashboard

Inspiration

I am an Architect working in San Francisco, and I have always been interested in how technology can promote the improvement of design in our everyday lives. Oftentimes, good design is killed later by value engineering, financial difficulties, and design constraints introduce too late into the project. I want to eliminate these barriers by introducing high quality information quickly to designers and developers early.

What it does

SitePilot turns a property address into a structured site-intelligence record through a controlled agentic workflow.

The user enters an address and development goal. SitePilot determines the governing jurisdiction, identifies the lead permitting authority and relevant agencies, assembles a property-specific registry of candidate sources, explains why each source is relevant and identifies its limitations.

The user reviews and approves this research boundary. SitePilot then dispatches scoped research agents only to the approved sources.

Supported findings are mapped into a controlled site-fact catalogue and displayed in a property overview and fact ledger. Each supported field retains its source and evidence. Information that cannot be verified remains unknown, conflicting, unavailable, or marked for professional review instead of being presented as fact.

SitePilot does not replace a survey, title report, environmental assessment, zoning opinion, legal advice, or agency confirmation. It provides fast, traceable reconnaissance showing professionals what is known, where it came from, and what still requires verification.

How we built it

SitePilot is built in Python using Gemini 3.5 Flash-Lite, Google Agent Development Kit, Google Maps API, and Streamlit.

The system separates source discovery from fact extraction:

Source Scout (agent) determines jurisdiction and builds the candidate-source registry. Human approval establishes which sources the system may research. Research agents extract only the facts assigned to them from approved sources. A controlled catalogue defines the facts agents may populate and the evidence required. A fact ledger stores values, statuses, citations, unresolved questions, and verification requirements. A property overview derives its content from the ledger rather than generating an unrelated free-form summary.

This separation gives each agent a limited responsibility and makes the workflow observable. Users can see the proposed sources, approval state, research results, citations, and unresolved information.

Challenges we ran into

The first challenge was source variability. There is no universal website or API for site diligence. Even neighboring properties can fall under different overlays, special districts, utilities, or reviewing bodies.

The second challenge was controlling research breadth. Early versions gave one agent too many sources and facts, which produced slow runs, incomplete outputs, and occasional failures. We divided the workflow into narrower responsibilities and organized facts into controlled research batches.

The third challenge was converting unstructured web information into dependable application state. An agent could find a correct fact without successfully updating the property ledger. We had to make the ledger the authoritative state and connect every overview field to that structured record.

The final challenge was uncertainty. Public sources can be inaccessible, outdated, incomplete, or contradictory. Instead of forcing an answer, SitePilot preserves explicit unresolved states and identifies when professional verification is required.

Accomplishments that we're proud of

I built a working, consistent, agent-to-organized-information workflow.

SitePilot can determine a property’s jurisdiction-specific research path, expose that path for human approval, research within the approved boundary, and convert supported findings into structured property records.

I am particularly proud of the trust architecture:

Candidate-source discovery does not count as source approval. Source approval does not count as fact verification. Every supported fact retains provenance. Unsupported information remains visibly unresolved. The interface shows both what the system found and what it could not establish.

This creates a foundation that professionals can inspect, question, and improve.

What we learned

First, I had very little coding experience. It increased immensely during this project.

I learned that reliable agents depend as much on boundaries, schemas, state management, and observability as they do on model intelligence.

Source discovery and fact extraction are fundamentally different tasks. Asking one agent to perform both encourages source drift and unsupported conclusions.

Most importantly, I learned that the fact categorization - not the conversational response - must be the product. The agent’s work becomes useful only when it creates a persistent, structured, and auditable record.

What's next for SitePilot

The next step is to improve source ranking, deduplication, caching, retry behavior, and run-level instrumentation. Future runs will report core-fact coverage, retrieval success, citation completeness, latency, cost, and manually verified accuracy.

I also plan to connect the evidence layer to:

• Market rents and sales comparables
• Construction and operating costs
• Public incentives and development fees
• Scenario-based development pro formas
• Early massing and buildable-envelope studies

This would allow SitePilot to answer questions such as how many units a project needs to pencil, how an easement affects development value, and which public incentives materially change feasibility.

The current achievement is more fundamental: SitePilot turns one address into sourced, structured site intelligence before the architect begins designing.

Built With

• gemini
• google-adk
• google-maps
• json
• python
• streamlit
• visual-studio