A playbook for the Head of Marketplace Data
If you are a Head of Marketplace Data, this is your playbook. It covers what your team ships, where its week goes today, the use cases agents take over first, the autonomy you can safely grant in each domain, and what to show leadership after the first quarter.
Key takeaways
- •Who this is for. Teams that own trip, order, supply and location data indexed to places, used for pricing, ETAs, dispatch and maps.
- •The problem today. Evening pricing outages after zone edits, stale pricing features and month-long city launches.
- •What changes. Zone coverage is checked on every geofence change, so no trip ever falls between zones. Pricing features run on freshness SLAs, so pricing never acts on stale supply.
- •What stays with your people. Zone and pricing changes: they move revenue in minutes, so marketplace ops approves.
- •The result. Prices and ETAs that are correct every minute.
The PRD for agentic marketplace and geospatial data teams
This is the requirements document we would write with you for your team. Everything below expands on it.
| Who | Marketplace, maps, pricing and geospatial data teams at mobility, delivery and location companies |
| The job | Supply, demand and location data you can price on. |
| Environment | Kafka; H3 or S2 indexing; Databricks or BigQuery; feature stores; maps and routing services. |
| Constraints | Zone and pricing changes always go to a named approver. Location data is personal data in many places. |
| Success is measured by | Map update verified: from about 2 days to ~1 h; Geofence gap fixed: from about 4 hours to 8-15 min; Stale feature rerun: from about 2 hours to minutes; catalog upkeep closed autonomously 88% of the time. |
| Owned by | A Head of Marketplace Data, with domain owners as named approvers. |
| Pilot scope | Zone coverage checks at L2. |
What going fully agentic and autonomous means for marketplace and geospatial data teams
- •Put your data pipeline on autopilot. Zone coverage is checked on every geofence change, so no trip ever falls between zones.
- •Run the data back office without the busywork. The work that fills the week today moves to agents: evening pricing outages after zone edits, stale pricing features and month-long city launches.
- •Scale data without scaling headcount. Pricing features run on freshness SLAs and city launches run as missions, so the data you manage grows without the team having to.
- •Get the plumbing off your plate. Prices and ETAs that are correct every minute.
Who this is for
Teams that own trip, order, supply and location data indexed to places, used for pricing, ETAs, dispatch and maps. Titles include Marketplace Data Lead, Geospatial Data Product Manager and Maps Data Engineer.
The shift
Every marketplace decision is a location decision. Geofences, map updates and city launches change constantly, and pricing models act on the data within minutes. Agents keep spatial indexes, geofences and supply-demand tables correct at that speed.
The product you ship
- •Spatially indexed supply and demand
- •Geofences and zones
- •ETA and routing features
- •City and market launch data
Where the week goes
- •Geofence edits break joins.
- •Map updates shift ETAs.
- •City launches need new zones.
- •Pricing features go stale.
- •Spatial data costs grow.
Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:
Time spent on new data products moves from 18% of the week to 52%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.
Then and now
| Work | Today | With Data Workers |
|---|---|---|
| Geofence edits | Broken joins | Validated on change |
| Map updates | ETA shifts | Verified before use |
| City launch | Weeks | A mission |
| Stale pricing features | Found in drift | SLAs |
| Spatial cost | Grows | Tiered |
These are the impact metrics we move for marketplace and geospatial data teams:
- •Map update verified: from about 2 days to ~1 h
- •Geofence gap fixed: from about 4 hours to 8-15 min
- •Stale feature rerun: from about 2 hours to minutes
Across the routine work in this domain:
The biggest change is Map update verified: from about 2 days to ~1 h.
Use cases, in depth
A geofence edit that broke surge
Today. An ops edit leaves a gap between zones; trips in the gap get no pricing.
With Data Workers. Quality Monitoring flags unassigned trips, Incident Debugging traces the edit, Conductor holds the zone change at L2.
What changes. No trips fall through.
A city launch
Today. Launching a city needs zones, features and dashboards.
With Data Workers. Autopilot runs the launch as a mission.
What changes. Cities launch in days.
Fresh pricing features
Today. A late supply feed stales features.
With Data Workers. set_sla and reruns.
What changes. Pricing never acts on stale supply.
Agents working together: A geofence gap that dropped surge pricing
Minute by minute
Illustrative example. Zones live in a geo service; trips stream into a lakehouse; pricing reads features every minute.
| Time | Who | What happens |
|---|---|---|
| 18:10 | Zone tool | Edit leaves a gap |
| 18:12 | Quality Monitoring agent | Unassigned trips flagged |
| 18:15 | Incident Debugging agent | Edit traced; fix proposed |
| 18:22 | Spellbook Data Catalog | Ops lead approves |
| 18:23 | Pricing | Features complete |
Without the agents, trips in the gap price wrong all evening.
The agents on the job
| Agent | What it does for you | Tools it calls |
|---|---|---|
| Real-Time Streaming | Trip and supply streams | register_kafka_schema, register_stream_schema, detect_schema_change |
| Quality Monitoring | Zone coverage and freshness | set_sla, run_quality_check, get_anomalies, create_quality_tests_for_pipeline |
| Incident Debugging | Traces spatial anomalies | diagnose_incident, get_root_cause, prepare_backfill, execute_backfill |
| Pipeline Building | Spatial features and city launches | generate_pipeline, validate_pipeline, sandbox_test, deploy_pipeline |
| Data Context & Catalog | Governed zone definitions | trace_cross_platform_lineage, blast_radius_analysis, define_business_rule, generate_documentation |
| MLOps & Models | Pricing and ETA model drift | detect_model_drift, evaluate_model, register_model |
Data Context Wizard keeps one governed graph of definitions, lineage and owners that every agent and person answers from. Autonomous Data-Conductor runs each job from detection to a verified result. Spellbook Data Catalog is where your team approves, audits and rolls back, and asks questions in plain English.
What goes on autopilot
Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:
- •Zone coverage is checked on every geofence change, so no trip ever falls between zones.
- •Pricing features run on freshness SLAs, so pricing never acts on stale supply.
- •City launches run as missions, so markets launch in days.
Where your people stay in charge
Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, staging fixes, documentation and cleanup is usually first to run on its own.
- •Zone and pricing changes always goes to a named approver: they move revenue in minutes, so marketplace ops approves.
- •Pricing policy: this stays with people.
Once a deployment has matured, here is how that ladder plays out across task classes:
Catalog upkeep closes autonomously 88% of the time. For Zones and pricing, autonomous closure is 0% by design.
What happens when an agent is wrong
- •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
- •At L3 act, reversibly, every change keeps a rollback point, and Conductor verifies the downstream number after the change. If verification fails, the change is reversed and the domain drops a level.
- •No agent approves or promotes its own work. Autonomy only grows on evidence, per repair class, and repeated errors shrink scope automatically.
- •One org-wide stop halts all autonomous dispatch, and every action lands in a hash-chained audit trail you can export with generate_audit_report.
How it fits your stack
Data Workers connects to what you already run: Kafka; H3 or S2 indexing; Databricks or BigQuery; feature stores; maps and routing services. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.
- •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
- •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
- •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
- •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.
Governance and regulation
Location data is personal data in many places. Data Workers classifies and scopes it and logs every change.
Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.
The alternatives marketplace and geospatial data teams weigh
Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the right owner, blast radius, rollback, receipts, and current context about every other system.
Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt.
Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses the source systems, orchestrator, warehouse and BI, and Data Workers works across all of them.
In this space specifically. Geo tools index; Data Workers keeps the data and features on top correct.
The case for your CTO
What this replaces. Evening pricing outages after zone edits, stale pricing features and month-long city launches.
What your team gets back. Prices and ETAs that are correct every minute.
Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and source systems you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.
Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; zone and pricing changes stay at L2 with a named approver; and one org-wide stop halts all autonomous work.
Why now. Marketplace margins depend on data freshness.
The first win. Zone coverage checks at L2. The pilot below lays out the scope, what you see each week and the cost.
The climb: from assisted to autonomous to agentic
Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For marketplace and geospatial data teams, the climb looks like this:
- •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; zone and pricing changes always go to a named approver.
- •Autonomous, under your governance. Routine work runs on its own: zone coverage is checked on every geofence change, pricing features run on freshness SLAs, and city launches run as missions. Your team governs the agents instead of doing the upkeep.
- •The agentic enterprise. Marketplaces will treat spatial data as a live product, checked on every change, so pricing and dispatch never act on a broken map. City launches will take days.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how marketplace and geospatial data teams start
The pilot is how your team proves the value on its own data before committing.
- •What we connect. Kafka; H3 or S2 indexing; Databricks or BigQuery; feature stores; maps and routing services, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. Zone coverage checks at L2.
- •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
- •By week two. Zone coverage is checked on every geofence change and pricing features run on freshness SLAs start running on reversible work. Zone and pricing changes stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Map update verified: from about 2 days to ~1 h
- •Geofence gap fixed: from about 4 hours to 8-15 min
- •Stale feature rerun: from about 2 hours to minutes
- •the share of catalog upkeep closed autonomously, targeting 88% as the deployment matures
- •What you decide. Whether to expand to the next domain. The pilot fee is credited in full against the first year.
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
The pilot is the start of a longer curve:
By month 12, more than 48% of agent actions run fully autonomously while zone and pricing changes stay with a named approver.
FAQ
Does it work with H3? Yes.
Can it change zones? Zone changes are L2.
Real time? Streaming checks run continuously.
Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.
Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.
Sources
- •Uber Engineering, Visualizing city cores with H3: https://www.uber.com/blog/visualizing-city-cores-with-h3/
- •Data Workers pricing: https://dataworkers.io/pricing/
- •Data Workers open-source repository (tool registrations): https://github.com/DataWorkersProject/dataworkers-claw-community
- •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
- •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team