Skip to content

Hi, I'm Atharv Patole.

I ship AI systems end to end: the data pipeline, the agent, the evals, and the interface the user touches.

Open to AI Engineer, Applied AI Engineer, Forward-Deployed Engineer, and AI/automation GTM roles.

New York City · Open to relocation · F-1 STEM OPT

// About

I build production LLM systems. That means staying current in a field that moves weekly: retrieval that actually grounds answers, agents that work reliably, evaluation that catches failures before users do. I learn from shipping, not from papers alone.

M.S. Computer Science, Pace University.
B.Tech Civil Engineering, Sanjay Ghodawat University.
Based in New York City.

// Skills

agentic ai
LLM agents · Multi-step workflows · Tool / function calling · LangGraph · OpenAI Agents SDK · MCP · Prompt & context engineering · Human-in-the-loop workflows
rag & retrieval
Graph RAG · LlamaIndex · Hybrid retrieval (BM25 + dense) · Semantic chunking · Semantic caching · Knowledge graphs · Pinecone · Chroma · Vertex AI Vector Search
evals & observability
LangSmith · Langfuse · OpenTelemetry · LLM-as-judge · Regression evals · Cost-per-query tracking · Prompt-injection defense · PII filtering
languages & backend
Python · SQL · TypeScript · JavaScript · Flask · REST APIs · Next.js · Vercel
data & cloud
AWS · GCP · ETL / ELT pipelines · PySpark · Docker · Kubernetes · PostgreSQL (Supabase) · SQL Server · MongoDB · DuckDB · Cloudflare R2
machine learning
Classification · clustering · Time series forecasting · Anomaly detection · Feature engineering · Model evaluation
geospatial
GDAL · GeoPandas · WhiteboxTools · MapLibre GL · PMTiles · Tippecanoe · GeoParquet

// Experience

Fulton Ring

Aug 2025 - Jul 2026

Data Scientist, AI Systems

New York, NY

Built and shipped multiple production LLM and data systems.

  • Teams and outside users had no way to ask a question about city data without waiting on an engineer to run it down. Built and shipped several production LLM search tools across different projects that answer in plain language instead, cutting manual review time roughly 40% on the primary one.
  • Retrieval kept surfacing plausible but wrong records because embeddings ignored the identifiers people actually reason with. Rebuilt the retrieval layer over Pinecone around structured metadata, then instrumented MCP tool-calling with LangSmith tracing and LLM-as-judge guardrails gating every release. Retrieval consistency rose close to 30%, and groundedness review dropped from hours to minutes.
  • Architects, investors, and other non-technical stakeholders across these projects had no route into the underlying data without borrowing time from a data team. Built standalone sites that put the data directly in front of them, on one trimming query latency on spatial files above 10GB by roughly 60%.

Community Dream Foundation

Aug 2025 - Jul 2026

Data Analyst

Remote, US

  • Reporting numbers coming out of the pipelines didn't always match what the source systems actually held, and nothing had caught it before it reached stakeholders. Traced the mismatches back through the pipeline by hand, then wrote Python and SQL checks that caught the same class of error automatically before every release.
  • The team pulled from internal tools and REST APIs that quietly disagreed with each other, and no one outside engineering could see the reporting layer to sanity-check it. Verified the data against source myself, then built dashboards so non-technical stakeholders could see the numbers directly instead of waiting on someone to explain them.
  • Issues found during testing had no shared record, so the same ones kept resurfacing every cycle without anyone connecting the dots. Documented every test scenario and worked directly with developers and stakeholders to close each one out for good.

Scon Infra

Jul 2020 - Jun 2023

Analytics Engineer

Mumbai

  • Finance and engineering were reconciling the same infrastructure planning figures by hand every month, and sign-off stalled every cycle waiting on someone to redo the math. Dug into the reporting logic and scripted it end to end across more than $12M in planning workflows, cutting recurring manual effort by about 35%.
  • Downstream models kept breaking whenever new source data came in, because no one had agreed on what a valid record looked like. Sat with the engineering team to define validation rules, then wrote the Python and SQL ingestion pipelines that enforced them, retiring the manual prep step entirely.
  • Executives were making planning calls off hand-assembled reports that took days to pull together, with finance and engineering working from different numbers. Defined shared governance rules and relational models spanning both sides, shortening decision turnaround by nearly 45%.

// Projects

SpiderNet

Ask a question in plain English about any New York City building or lot. The answer comes from real records, drawn on the map.

  • Python
  • LangChain
  • Pinecone
  • MCP
  • DuckDB
  • MapLibre GL
  • PMTiles
  • Next.js
  • GeoPandas
  • WhiteboxTools
  • GeoParquet
  • Tippecanoe

~0 map layerspublic REST API0 sensors~0 buildings~0 flooded

The AI system

A question in plain English turns into queries against real data, and the answer comes back grounded in records that exist. An LLM does the planning and calls tools over an MCP server I wrote by hand.

The tools read parcel records, the building and zoning code text, and the flood risk layer. They return the answer along with the geometry to draw it, so the reply and the map agree.

The data system

The data lives as GeoParquet on Cloudflare R2. DuckDB runs inside a Vercel serverless function and reads it over HTTP range requests, so a query pulls the bytes it needs instead of loading the table.

The map is MapLibre GL over PMTiles, about 30 layers. The front end is Next.js on Vercel.

The same data is available without the chat, through a free public REST API with an OpenAPI spec.

The flood risk model

One of those layers is a building-level flood risk classification covering roughly one million New York City properties.

The first approach failed

I started with Kriging plus XGBoost over sensor readings. It did not work. The sensors are not sited randomly, so the model extrapolated badly outside their footprint. Accuracy near the sensors was hiding the fact that the predictions everywhere else were not trustworthy.

I replaced it with a physics-based HAND-stage inundation method, run across all 241 eligible sensors.

The output is an enriched GeoParquet covering roughly 219,000 assessed buildings. Roughly 55,000 classify as flooded, each with a confidence score and a tiered flood depth.

Validation

  • Cross-checked against 311 complaints.
  • Leave-one-out sensor coherence analysis.
  • Compared against NYC DEP's Stormwater Map.
  • Distance-decay confidence lookup.

Tiled with tippecanoe to PMTiles and served live as the flood risk layer above.

// Achievements

1st place

Global Governance & Climate Hackathon

Attributes fires that cross national borders in the Amazon to their source, from satellite data.

Built with a teammate.

1st place

FOAK Hackathon

Designed the capital stack and monetization model that moved a CO2-to-graphite startup's first commercial facility toward bankability.

Built with a teammate.