You're on Feast: Feast Defines and Serves Your Features. Data Workers Makes Sure the Tables Behind Them Are Right
On Feast for feature views, point-in-time training sets and online serving? Keep it. Data Workers keeps the source tables behind every feature view right, behind approvals.
Your features live in a Feast repo. Feature views are Python definitions in Git, feast apply writes them to the registry, get_historical_features builds point-in-time correct training sets, and a scheduled materialize-incremental copies the latest values into Redis, DynamoDB or ScyllaDB for get_online_features at inference. The feature server can run as an MCP server for agents, and since v0.64 in June, Feature Quality Monitoring profiles null rates, distributions and freshness per feature (v0.66.0, August 21, is the current release). Feast defines and serves your features very well. Data Workers owns the question underneath: whether the tables those feature views point at are right, and when they aren't, getting them fixed through their owner, behind approvals, with a receipt.
Whatever is wrong in the table under a feature view, a missing day or a broken key, flows straight into training and serving. That table belongs to the data team.
Key takeaways
- •Feast keeps its job. The registry, point-in-time joins, materialization, online serving, Feature Quality Monitoring and the MCP feature server stay where they are.
- •Data Workers watches the source tables. Per-day row counts your flows record, checks on BigQuery, Snowflake and Postgres, and dbt manifest lineage catch a broken feature source before it reaches training or Redis.
- •Models and features are nodes in the graph. Register each production model with its source tables and its feature view's features in the Context Wizard graph, and blast radius reaches them from any upstream dbt model.
- •Fixes go to owners. Data Workers proposes code changes as diffs, queues rebuilds through your orchestrator after a named person approves, and re-checks. The feature platform owner materializes in Feast.
- •Every fix leaves a receipt with the trigger, evidence, approver, checks, the window the owner loaded and the undo path.
- •Start with a pilot on two production feature views, read-only first, from L0 manual toward L4 autonomous.
Feast defines and serves your features. Data Workers makes sure the tables behind them are right.
Feast answers which features exist, how to join them without leakage, and what a model gets at inference. Data Workers answers what changed in the source table, what it reaches, who owns the fix and whether it held. Here is how they meet when a late file opens a gap between your offline and online stores.
An online travel marketplace serves two models from Feast: hotel_rank for search ranking and cancel_risk. The feature view property_daily_stats (bookings, average nightly rate and cancellation rate) reads features.property_daily_stats in BigQuery, one row per property per day, event timestamp at the end of the day, two-day TTL. A Prefect flow, property_features_daily, runs dbt Core at 02:00 to build it from raw.partner_bookings, which a booking partner's nightly file loads from Cloud Storage at about 01:15. The Feast Operator on GKE runs feast materialize-incremental as a CronJob at 03:00 into Redis. The team registered both models in Data Workers' context graph with the source table and features, plus a note that the 03:00 CronJob materializes the view. The flow's last task records one data point with monitor_metrics: metric row_count, the table as the source, and the rows for the newest event date, about 11,800 on a normal day. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Tue 23:50 | Cloud Storage | The partner's export fails after an outage on their side. Tonight's file does not arrive |
| Wed 02:00 | Prefect and BigQuery | property_features_daily runs on schedule. dbt builds features.property_daily_stats with no rows for Tuesday, because there is no file. Every dbt test passes |
| 02:04 | Data Workers | The flow records 0 rows for event date Sep 29 with monitor_metrics. Against the history recorded for that table, the monitor returns an anomaly |
| 02:06 | BigQuery | Data Workers runs run_quality_check on the table: nulls in avg_nightly_rate under the 1% threshold the team set, the property_day_id distinct ratio normal, rows above the floor. The days the table holds are whole; Tuesday is missing |
| 02:09 | Slack and Spellbook | Data Workers posts the finding to data on-call and the feature platform owner. blast_radius_analysis over the dbt manifest and the graph reaches the feature view's features and both registered models. From the team's CronJob note, it recommends holding the 03:00 materialization until the day lands |
| 03:00 | Feast | Nobody has read the card yet. The CronJob runs materialize-incremental, finds no Tuesday rows and records 03:00 Wednesday as the feature view's materialization end date |
| 04:20 | Cloud Storage and BigQuery | The partner's file lands, and the load writes Tuesday's bookings to raw.partner_bookings |
| 07:00 | Feast | The feature platform owner opens the Feast UI: the Freshness column shows the source's newest event timestamp 31 hours old. She reads the Slack card |
| 07:05 | Spellbook and Prefect | The analytics engineer who owns the property models confirms the file landed and approves the rebuild in Spellbook. Data Workers queues the Prefect flow run |
| 07:26 | BigQuery | The run completes. The flow records 11,764 rows for Sep 29, inside the band, and run_quality_check passes |
| 07:28 | Slack | Data Workers tells the feature platform owner that Sep 29 is back in the offline store and, from the CronJob note, that an incremental run at 03:00 would have moved the end date past those rows, so later incremental runs will skip them. She confirms the end date in the registry |
| 07:40 | Feast | The owner runs feast materialize -v property_daily_stats 2026-09-29T00:00:00 2026-09-30T08:00:00. Redis serves Tuesday's values |
| 08:10 | GitHub | Data Workers proposes two diffs. For the feature platform owner: the CronJob runs after the Prefect flow and materializes an overlapping 48-hour window, the guard Feast's production guide uses for late data. For the analytics engineer: the flow waits for the partner file before dbt runs |
| 08:45 | Spellbook | Both owners merge. Data Workers writes the receipt: baseline, checks, blast radius, approver, rebuild, the window the owner recorded loading, both diffs and the undo path, a BigQuery time travel restore recorded for the owner to run. The approved fact "property_daily_stats waits for the partner file; materialize with a 48-hour overlap" lands in the graph |
Every tool did its job, and Feast's monitoring showed the source aging. The problem lived between the tools: a late file and an end date that had already moved. Without the fix, Redis would have served Monday's values to the ranker for a day, and the next training set would hold Tuesday values production never saw. Data Workers caught the missing day, traced the reach, got the rebuild approved and told the owner which day to reload; every Feast decision stayed with her.
| Job | What Feast does | What Data Workers does |
|---|---|---|
| The definitions | Holds entities, feature views and feature services in the registry | Holds models and their features as graph nodes joined to source tables and owners |
| The training set | Builds point-in-time correct training sets from the offline store | Checks the source tables those joins read after every build |
| The serving | Materializes to the online store and serves at inference | Tells the owner which day a late source left out, so she reloads it |
| The signal | Shows a feature's freshness, null rate and distribution in its monitoring | Flags the missing day in the source before materialization runs |
| The fix | The owner materializes, changes the feature view or the job | Queues the dbt rebuild after approval; proposes job and flow diffs; re-checks |
| The proof | The registry and its materialization history | A receipt per fix: evidence, approver, checks, window, undo path |
Why doesn't Feast just do this itself?
Because Feast is an open-source library built to sit on the stores you already run and own none of them. That restraint is why it fits so many stacks: BigQuery, Snowflake, Redshift or Spark on one side, Redis, DynamoDB, ScyllaDB or Aerospike on the other, under an Apache 2.0 license as an LF AI & Data Foundation project. Its newer features stay on its side of the line: Feature Quality Monitoring measures the features, the dbt integration (alpha) imports dbt models as feature views, and the MCP feature server lets agents read online features.
Fixing a source table is a different product with a different liability: warehouse and orchestrator credentials, lineage across dbt models another team owns, a named owner's approval, an undo path and proof the fix held. A feature store that edited dbt models and reran another team's flows would stop being the neutral layer every model team adopts. Data Workers is the product on the other side of that line.
Every tool owns a slice. Data Workers covers the whole lifecycle
Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, building on the tools already there.
Feast's home stage is MLOps & Models, where it leads by design: point-in-time joins, materialization and online serving belong to Feast, and Data Workers keeps the tables under them right.
| Stage | Data Workers | Feast | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Feast's registry holds entities, feature views, feature services and sources. Data Workers joins tables, lineage, quality, owners and registered models in one governed graph. |
| Analytics & Insights | 8 | 2 | Feast serves features to models; it does not answer business questions. Data Workers answers questions about the data from governed context. |
| Data Quality | 8 | 5 | Feature Quality Monitoring profiles null rates, distributions and freshness per feature. Data Workers checks the source tables and fixes them through their owners. |
| Observability & Incidents | 8.5 | 4 | Feast shows a feature aging or shifting. Data Workers detects, diagnoses, fixes and verifies the data incident behind it, with a receipt. |
| Pipelines & Ingestion | 8.5 | 6 | Feast materializes from your offline store to your online store. Data Workers queues the upstream rebuild through your orchestrator after approval. |
| Schema & Migration | 8 | 3 | Feast imports dbt models as feature views (alpha). Data Workers shows a dbt change's reach and writes migrations with rollback for the owner. |
| Governance & Access | 8.5 | 5 | Feast enforces permission policies on its servers, with OIDC. Data Workers routes each data change to a named approver and keeps the record. |
| Security & Privacy | 8 | 3 | Feast secures its own servers. Data Workers proposes masking for data owners to approve and flags privacy risks in pull requests. |
| Cost / FinOps | 8 | 2 | Feast tracks no spend. Data Workers attributes Snowflake spend to dbt models through query tags. |
| MLOps & Models | 7.5 | 8.5 | Feast's home stage: point-in-time joins, materialization and online serving. Data Workers keeps the source tables under each feature view right. |
Scores are directional measures of scope, not benchmarks.
How Feast and Data Workers work together
Your people stay where they are: ML platform engineers in the Feast repo and UI, data scientists in notebooks, analytics engineers in dbt, and Claude, Cursor or GitHub Copilot for questions and code. Spellbook Data Catalog (in preview) is where the data team looks: each finding, proposed change, blast radius, approver and rollback, with approval requests in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor runs each fix (detect, diagnose, fix, review, verify, remember) behind per-domain guardrails.
Where Feast fits. Feast stays the system of record for feature definitions, materialization and serving, and connects over its Python SDK, feature server or MCP feature server today. Data Workers reads natively what sits under the feature views: BigQuery (with a service-account key), Snowflake and Postgres checks, the dbt manifest, GitHub pull requests and runs in Prefect, Airflow, Dagster or Azure Data Factory, among 50+ connectors. Your team, or its coding agent, registers each production model once with its source tables and features, plus notes such as when the materialization job runs: the materialization window lives in Feast's registry, and Data Workers knows the schedule from that note. The MLOps & Models agent also uses a point-in-time join ported from Feast's Apache 2.0 code and can draft a FeatureView definition (Inside the MLOps & Models Agent).
What Data Workers writes, and where. To Feast, nothing: the registry, feature views and materialization belong to the feature platform owner. Code fixes go to owners as diffs, and Data Workers opens the pull request for dbt changes when your team turns on the GitHub pull-request target. Rebuilds are queued through your orchestrator after approval; the owner runs any recorded undo. Approved facts land in the Context Wizard graph.
Setup today. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show. Your client can run Feast's MCP feature server next to them, so one assistant reads online features and your data operations; Data Workers' agents never call it.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
},
"feast": {
"type": "http",
"url": "http://feast-feature-server.internal:6566/mcp"
}
}
}Feast's side needs pip install feast[mcp] and a feature_server block with type: mcp, mcp_enabled: true and mcp_transport: http in feature_store.yaml. List the tools with /mcp in Claude Code, then ask "which dbt models feed features.property_daily_stats, and which registered models read it?"
One request, L0 to L4. The autonomy ladder is set per domain, so the marketplace domain can sit at a different level from finance reporting.
- •L0 manual. Connected, not acting. The team finds the gap when rankings drift at lunch.
- •L1 observe. Data Workers flags each baseline break with its blast radius and owners, and logs what each action would have needed.
- •L2 propose. It drafts the rebuild, the day to reload and the diffs; owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as rerunning a feature source's Prefect flow once its upstream load succeeds, it acts, verifies and records. Code still arrives as diffs.
- •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop end to end and posts the receipt for review. Materialization stays with the feature platform owner at every level.
Read more on safety, how approvals work, the autonomy levels and where your data goes.
What changes for your team
Teams on Feast already solved the hard ML problem. What still costs them time is the data under the definitions: the late file nobody saw, the ticket that bounces between the ML platform and analytics. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A missing day or broken key in a feature source arrives traced to its cause, fixed through its owner and recorded.
- •Data quality. Nulls, keys, row floors and per-day baselines are checked on feature sources after every build. Set a stricter null threshold for key features, since the default check allows up to 10%.
- •Cloud spend. Snowflake spend is tied to each dbt model through query tags, feature tables included.
- •Access. Grant changes a fix needs arrive as proposals; Unity Catalog grants apply after approval.
- •Audits. Each fix links the trigger, approver, checks, the window the owner loaded and the undo path.
- •Migrations. Each wave is planned with its parity checks, and the owner signs off before it closes.
The ML engineers guide covers the role. Also see You're on Tecton, You're on MLflow and You're on Amazon SageMaker.
Keep Feast, or consolidate?
Keep Feast if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Nearly every team keeps Feast. What they consolidate is the tooling around it: row-count asserts pasted into materialization jobs, offline-versus-online comparison scripts, and wiki pages mapping feature views to dbt models. For background, see Feast vs Tecton, what a feature store is, MCP for ML feature store agents, data lineage for ML features and data freshness monitoring. On BigQuery, see Data Workers on Google Cloud; for the models behind your features, You're on dbt. Building this layer yourself? Read build it ourselves with Claude Code and MCP servers: recording a baseline is the easy part; approvals, rollback and receipts are the work.
The case for your CFO
The outcome: models train and serve on complete, current feature data, and an upstream break is caught before it reaches a training set or the online store. Feast keeps training and serving consistent; Data Workers makes sure what they are consistent about is right.
The risk story is plain. Data Workers changes nothing in Feast: it never edits the registry or materializes. Code fixes arrive as diffs your engineers merge; rebuilds run only after a named approver says yes, and each leaves a receipt. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. The agents run in your infrastructure; your data stays in your systems, and the hosted Conductor sees workflow metadata only.
Why now: more models depend on online features every quarter, and a day of stale features rarely raises an alarm; it shows up as worse rankings or fraud calls weeks later. The first win is two production feature views registered with their source tables, per-day baselines and review on the dbt repo, read-only, with a report of every gap that would have reached training or Redis. Feast, your stores, your schedule and your owners stay the same. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Feast serves the features our models use; Data Workers makes sure the tables behind them are right, with an approval and a receipt for every fix."
Getting started
Start with a pilot. Pick the two feature views your business feels first, register their models with source tables and features, connect Data Workers read-only to BigQuery or Snowflake, the dbt project, pull requests and your orchestrator, have the source flows record per-day row counts, and let it report what it would have caught before you turn on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers read our Feast registry and feature views? Feast stays the system of record for those and connects over its SDK, feature server or MCP feature server today. Your team registers each production model with its source tables and features, plus notes such as the materialization schedule, and Data Workers works on those tables.
Can Data Workers run feast materialize for us? Materialization belongs to the feature platform owner. After a late source is rebuilt, Data Workers tells her which days came back and proposes the job change, such as an overlapping window. She checks the materialization end date in Feast and runs feast materialize.
Feast has Feature Quality Monitoring now. Why add Data Workers? Feast's monitoring measures the features. Data Workers works one step upstream: it checks the source tables, traces a break to dbt or the orchestrator, gets the owner's approval for the fix, re-checks and keeps a receipt. Keep both.
Does Data Workers detect feature drift? That stays with Feast's monitoring and your model monitoring. Data Workers checks the tables under the features and the baselines your team records, and traces a change to its cause when a feature moves.
We use Feast's OpenLineage integration. Does Data Workers use that lineage? Feast's lineage view stays in Feast. Data Workers builds lineage from the dbt manifest and the models and features your team registers in the context graph, and blast radius reaches them from any upstream dbt model.
Sources
- •Feast, home page, https://feast.dev/ (checked Oct 3, 2026)
- •Feast GitHub releases: v0.66.0 (Aug 21, 2026), v0.65.0 (Jul 20, 2026), v0.64.0 (Jun 13, 2026, Data Quality Monitoring), https://github.com/feast-dev/feast/releases (checked Oct 3, 2026)
- •Feast docs, MCP Feature Server, https://github.com/feast-dev/feast/blob/master/docs/reference/feature-servers/mcp-feature-server.md (checked Oct 3, 2026)
- •Feast docs, CLI reference, https://github.com/feast-dev/feast/blob/master/docs/reference/feast-cli-commands.md (checked Oct 3, 2026)
- •Feast docs, Running Feast in production, https://github.com/feast-dev/feast/blob/master/docs/how-to-guides/running-feast-in-production.md (checked Oct 3, 2026)
- •Feast docs, Point-in-time joins, https://github.com/feast-dev/feast/blob/master/docs/getting-started/concepts/point-in-time-joins.md (checked Oct 3, 2026)
- •Feast docs, Feature Quality Monitoring, https://github.com/feast-dev/feast/blob/master/docs/how-to-guides/feature-monitoring.md (checked Oct 3, 2026)
- •Feast docs, Importing features from dbt (alpha), https://github.com/feast-dev/feast/blob/master/docs/how-to-guides/dbt-integration.md (checked Oct 3, 2026)
- •Feast docs, OpenLineage integration, https://github.com/feast-dev/feast/blob/master/docs/reference/openlineage.md (checked Oct 3, 2026)
- •Feast docs, Permission, https://github.com/feast-dev/feast/blob/master/docs/getting-started/concepts/permission.md (checked Oct 3, 2026)
- •LF AI & Data Foundation, Feast project page, https://lfaidata.foundation/projects/feast/ (checked Oct 3, 2026)
- •Data Workers, Client setup, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers pricing, https://dataworkers.io/pricing/ (checked Oct 3, 2026)