Agentic data preparation only works when we treat data prep and analysis as specialized forms of programming. A general-purpose assistant bolted onto the side doesn't move the needle because it lacks the data context, interfaces, execution environment, and governance controls analysts rely on.
Our view: agents must operate inside the analyst's actual work surface. They need to understand visual workflows, SQL, spreadsheets, charts, and documents, then help analysts move from business intent to production without separating domain experts from the logic they know best.
The work must remain inspectable from first draft through deployment, with the analyst refining the workflow and the platform team preserving the controls that make it safe to run in production inside the same environment.
What agentic data preparation actually requires
An agent earns its place in data prep only when it is specialized across four dimensions. Prompt fluency alone isn't enough. A 2025 Gartner survey found that 63% of organizations either don't have or aren't sure they have the right data management practices for AI. The underlying data context and controls matter as much as the model.
First, agents need data context and semantics: universal data operations including types, quality rules, relationships, and lineage, alongside business-specific definitions that determine whether a workflow is correct.
Second, they need a visual work surface, because analysts explore and develop through visual workflows, SQL, spreadsheets, charts, and documents, not a chat window.
Third, specialized execution matters: workflows must connect to sources such as SharePoint, execute in memory for ad hoc work, and scale on Databricks, Snowflake, or BigQuery while downstream tools consume prepared data from the platform. Finally, enterprise governance is non-negotiable: every step must preserve a single source of truth, with data worked on inside the data platform under access controls, lineage, auditability, and platform-team standards.
This combination lowers friction for simpler tasks, much as vibe coding has lowered programming's entry cost. More importantly, it changes the economics of larger tasks by keeping generation, inspection, and deployment in one governed environment. That is what governed self-service should mean: analysts get their work into production without stepping outside the boundaries their platform team established.
How agents generate, refine, and deploy data workflows
The working loop is Generate, Refine, Deploy. AI agents for data prep create a first draft, but analysts remain responsible for inspecting the logic, testing the result, and deciding when it is ready for production. Agents don't run unattended, and they don't replace the business judgment that determines whether a join, aggregation, or quality rule is appropriate.
Generate → Refine → Deploy
During generation, agents interpret a business prompt using schemas, metadata, and prior work, then produce a visual workflow or document that is easy to review. During refinement, users preview data after each step, change existing logic, add new operations, and iterate until the output is correct. The analyst's domain context stays in the process rather than being translated through an engineering ticket.
The comparison to vibe coding and tools like Cursor is useful in one respect: intent produces a working first draft, but review still determines whether it is trustworthy.
Once approved, the workflow moves from interactive runs on sample or full data to scheduled production on the customer's cloud data platform. Versioning, tests, approvals, CI/CD, monitoring, and alerting carry it across the last mile. Source systems land data in Databricks, Snowflake, or BigQuery; workflows run natively on that platform rather than on Prophecy infrastructure, so data stays inside the customer's security boundary.
Platform teams keep the governance mechanisms of their chosen environment: Databricks uses Unity Catalog, Snowflake provides Horizon Catalog governance, and BigQuery applies its own access controls. Agents inherit those boundaries rather than creating a second governance model.
The specialized agents behind analyst-led data prep
No single agent covers all of data preparation. The current agent documentation identifies three specialized data agents: the Transform Agent, Documentation Agent, and Harmonization Agent. Each handles a distinct part of the work while keeping the analyst in control.
- The Transform Agent helps users find relevant datasets, ingest them, and build or modify visual workflows that cleanse, normalize, enrich, and aggregate data. Picture an operations analyst preparing a monthly fulfillment analysis. The agent can assemble the first-draft workflow from available schemas and the analyst's request; the analyst then checks the join grain, previews intermediate results, and adjusts the business rules before deployment.
- The Documentation Agent records the transformations applied to datasets, especially where regulated work requires a defined template. Consider a compliance analyst in finance preparing a review package. The agent can interpret the workflow, draft objective sections, and walk the analyst through questions that require subjective judgment. Documentation stays connected to the operations it describes instead of becoming a separate write-up that drifts out of date.
- The Harmonization Agent maps datasets from different customers or sources into a common data model so downstream processing can be applied uniformly. Say a claims analyst at a regional insurer receives partner feeds with different field names and structures. The agent can use example workflows, mapping documents, target definitions, relationships, and constraints to propose the harmonization. The analyst reviews ambiguous mappings and validates the resulting data before it moves forward.
These agents reduce routine engineering requests while preserving work that requires engineering expertise, and they put the analyst's business context directly into preparation and analysis.
Why this changes the operating model
Faster generation is useful, but it isn't the point on its own. The step-change comes when analysts can generate, inspect, refine, and deploy the same visual data workflow without handing business logic back and forth through a queue. Analysts and business users can query prepared data directly in Prophecy, while other applications consume it from the cloud data platform. Business intelligence tools are possible downstream consumers, not the endpoint.
This is also the fair contrast with desktop-focused tools such as Alteryx. Prophecy is built on the cloud data platform rather than moving governed work onto a separate desktop engine. Our Alteryx comparison details how native execution keeps workflows on cloud-platform compute and data within the customer's environment.
Platform teams keep control of access and production standards, while analysts keep control of meaning. If that is the operating model you want for your analytics team, book a demo.
