Agent-powered data platform on Databricks: how a global footwear brand scaled planning across 35+ markets

A red sneaker sells out in Seoul on a Tuesday. Seventeen days later, that number reaches a planner at head office. By then the style has cooled in Seoul, caught on in Madrid, and the reorder window has closed on both. Nobody made a bad call. The call simply arrived late.

For a global retailer, planning is only as good as the data underneath it. A leading footwear and apparel brand ran planning across 35+ markets, each sending sales and inventory data in its own way.

The challenge was not simply moving files faster. Every country operated slightly differently, creating constant data quality, enrichment, and validation issues. Planning teams spent significant effort reconciling data instead of acting on insights. As market expansion accelerated, onboarding new countries and managing exceptions became increasingly complex, making the existing model difficult to scale.

Infocepts rebuilt this as an agent-powered data platform on the Databricks Data Intelligence Platform. An agent-powered data platform is a data engineering system where AI agents, not hard-coded scripts, validate, enrich and correct incoming data, with business owners approving the exceptions that matter. It now runs across all 35+ markets. It cut the planning data cycle from 17 days to 4, a 76% reduction, brought ad-hoc refreshes down from 12 hours to about an hour, and let planning teams trigger those refreshes themselves instead of waiting on IT. Latency was the headline number, but the real change was a planning operation that scales as new markets come on, with data that teams can trust.

The challenge was bigger than delayed data

At first glance this looks like a speed problem: planning data took up to 17 days to become usable, in a category where a style can run hot for three weeks and then stop. But the delay was the result of something harder to fix.

Every market operated slightly differently. Data arrived in different formats. Product hierarchies varied by country. Attributes were sometimes incomplete or missing. Local exceptions needed specialised knowledge to interpret and resolve. So, merchandise and demand planners spent significant effort validating, enriching and reconciling data before they could use it with confidence, and much of that work depended on a small number of subject-matter experts who understood each region’s quirks.

The challenge was not simply moving files faster. As market expansion accelerated, onboarding new countries and managing exceptions became more complex, and an operating model designed for regional operations was now carrying a globally scaled planning function.

The factors underneath the delay:

• 35+ countries submitting data in different formats
• Product hierarchy inconsistencies across markets
• Missing or incomplete attributes requiring enrichment
• Country-specific planning exceptions
• Heavy reliance on SMEs for validation and issue resolution
• Manual data quality checks and remediation
• Slow onboarding of new markets
• Limited trust in planning data because of inconsistent quality and timeliness

Nothing in the process was fundamentally broken. Files arrived, reports refreshed, every step worked. The constraint was that manual governance and exception handling do not scale, and the cost of that fell on planners and a handful of experts. Any team running demand and merchandise planning

Why traditional data pipelines were not enough

The existing platform used conventional data engineering. Validation rules, mappings and transformations were largely hard-coded into the pipelines. That created three limits.

Rules could not easily adapt to change: A new market, a modified file format or an added business rule meant engineering effort, testing and deployment. Staying flexible got harder as the number of markets grew.

Data issues surfaced too late: Validation often happened after data had already moved through several stages. Each exception triggered an investigation involving business users, planners and IT, which extended timelines and repeated manual work.

Knowledge stayed concentrated with SMEs: Experienced planners and data experts knew how to interpret local exceptions and fill gaps. That knowledge was valuable and fragile, and it made onboarding new markets slower and more expensive.

International planning data is not predictable enough for deterministic logic alone. Every market introduces variation in structure, rules, attributes and exceptions, and writing rules for every possible case becomes harder as operations expand. The organisation needed a platform that could read data in context, manage variation across markets, and keep improving data quality as it scaled.

What is an agent-powered data platform?

An agent-powered data platform is a data engineering architecture where domain-specific AI agents handle the steps an engineer would otherwise script by hand. A conventional pipeline follows fixed instructions and fails when the input changes. An agent-powered platform reads what actually arrived, compares it against the rules, metadata, master data and historical patterns it holds, decides what to do, and either acts or routes the case to the right business owner.

The distinction is that the platform interprets, validates and improves data as it processes it, which is what makes the model scale across dozens of countries. This pattern has a name in the field: self-healing data pipelines.

It sits in the same family as Databricks AI Agents, the platform’s broader push toward autonomous, governed agent workflows.

The platform manages five functions:

• File validation: Structure, format and completeness of each market’s upload, whatever shape it arrives in.
• Data quality validation: Configurable rules aligned to the product master, applied consistently across every country.
• Exception identification and routing: Finding records that fail, working out why, and sending them to the right owner.
• Cross-system data validation: Confirming consistency once records are loaded.
• Data remediation and enrichment: Proposing or applying corrections and suggesting values for missing attributes such as style and colour.

Business users stay in the loop. Agents surface issues, identify root causes and recommend actions, and a named business owner keeps approval authority over anything that could affect planning outcomes. The SME knowledge that used to live in people’s heads is now encoded in the rules and metadata the agents work from, so it scales as new markets come on rather than depending on who is available.

What changed for the planning team

The validation, enrichment and reconciliation that used to fall on planners and SMEs now happens before the data reaches them. Most records clear automatically. The exceptions that need a person, fewer than 5% of cases, arrive with the issue already identified and a fix already suggested. And a merchandise planner who corrects a country file can reload it themselves in about an hour, without raising an IT request.

What this buys a planner is not a faster report. It is a shorter path from noticing something to acting on it, on data validated the same way for every country. A style selling through in one market shows up while there is still time to reorder or reallocate, not after the window has closed.

Why this was built on Databricks

The value of Databricks here was not the individual tools. The Databricks Data Intelligence Platform brought data engineering, governance, AI, application development and operational workflows into one environment. That let planning teams work directly with governed data processes while enterprise controls and traceability stayed intact.

The application planners use and the pipelines it sets running live in the same environment, under the same governance. The app was built with Databricks Apps, so there is no handoff between a web app hosted in one place and a data platform governed somewhere else, and no second access model to reconcile when a business user starts a job that writes to production tables.

Handing self-service loads to the business only works if every load is still logged, attributed and traceable. Unity Catalog enforces role-based access and lineage on every job a planner triggers, which is what makes self-service safe rather than risky.

For planners, this meant faster decisions. For data engineering leads and data product managers, it meant fewer maintenance cycles. For the business, it meant a planning platform that scales with international growth.

The transformation behind the numbers

We transformed a manually governed, country-by-country planning data operation into an AI-powered, self-healing planning platform that scales across 35+ markets while reducing planning latency by 76%. The organisation now has:

• A consistent planning data framework across 35+ markets
• Reduced dependency on specialised knowledge and manual work
• Faster onboarding of new countries
• Greater trust in planning data
• Human-in-the-loop governance on decisions that matter
• Self-service planning operations on a governed platform

The platform was delivered in 12 weeks. The next step is putting a trusted single number in front of sales and inventory teams.

For data leads: the component view

This section is for data engineering and data product roles. Skip it if you came for the planning outcome.

The end-to-end flow runs in four stages.

1. Upload and application layer: The end user uploads a file through MFT. The agent-powered data engineering application, running on Databricks Apps with a Streamlit interface, receives it.

2. Orchestration: A Databricks Job orchestrates the platform’s processing jobs: file validation, DQ validation, exception handling, data validation and data remediation.

3. Agent layer: Domain-specific agents handle analysis, execution and recommendations. Three supporting elements sit alongside them: guardrails covering PII and content filters, a knowledge base holding domain data and rules, and the tools the agents call. Agent orchestration uses the Strands Agents SDK.

4. Engine and framework layer: A recommendation engine sits behind the exception handling component, alongside the file validation, data validation and DQ validation engines. The surrounding framework provides versioning, audit, governance and RBAC. Metadata and processed data land in Delta tables governed by Unity Catalog.

For teams weighing where operational state should live in an agent-powered build, Databricks’ Lakebase accelerators post covers the managed-Postgres pattern that several partners now use as agent working memory. This build does not use Lakebase, but the tradeoffs it describes are the ones data leads face here.

Infocepts and Databricks

• Infocepts is a Databricks Silver Partner with Brickbuilder Specializations in Retail, Consumer Goods and Travel.
• Infocepts ranked #1 in the Databricks Elevate and Accelerate Rising Challenge, and holds 300+ Databricks certifications.
• OptiStore.AI was featured on the Databricks blog as a Genie-powered retail partner solution.
• Infocepts retail solutions are built on the Databricks Data Intelligence Platform.
• Infocepts presented eleven production-ready retail AI solutions at the Databricks Data + AI Summit 2026.

Infocepts also features in Databricks’ own round-ups of partner work. Its Databricks Observability solution appears in Databricks’ cross-industry Genie partner solutions and again in the Lakebase accelerators round-up. Both sit downstream of Databricks’ first partner-solutions post on conversational AI with Genie, which set out the partner-solution program this work belongs to.

Frequently Asked Questions

What is an agent-powered data platform?

It is a data engineering system where AI agents handle ingestion, validation, exception handling, enrichment and remediation, working from metadata, master data and configurable rules instead of hard-coded logic. A business owner approves anything that carries business consequence.

How is this different from a normal ETL pipeline?

A conventional pipeline runs fixed instructions and fails when the input changes. An agent-powered platform reads what arrived, compares it to the rules and master data it holds, and decides what to do. Fewer code changes are needed when file formats or markets change, which is what makes onboarding a new country quick.

How does it handle 35+ countries sending data differently?

The agents validate and enrich against a common product master rather than against per-country code. Format differences, hierarchy mismatches and missing attributes are handled as rules and metadata, so a new market is a configuration change, not a development project.

Can business users really trigger their own data loads?

Yes. Planners trigger ad-hoc loads from a web application without going through IT. Because the application runs on Databricks Apps under Unity Catalog governance, those loads stay inside role-based access controls and are fully logged.

How quickly is data available after an upload?

An ad-hoc load completes in about an hour, down from 12 hours. The standard cycle from file arrival to usable planning data is 4 days, down from 17.

Does this reduce dependency on subject-matter experts?

Yes. The regional knowledge SMEs used to apply by hand is encoded in the platform’s rules and metadata. SMEs still own the genuinely ambiguous exceptions, but routine validation and enrichment no longer wait on them.

Which Databricks components does the platform use?

Databricks Apps, Streamlit, Mosaic AI Agent Framework, Model Serving endpoints, MLflow, Unity Catalog, Delta tables, Jobs and AI Gateway.

Build an Intelligent Data Platform on Databricks

Use governed AI agents and self-healing data pipelines to improve data quality, reduce manual effort, and scale operations across global markets.

Talk to Our Experts