Meet Walter: agentic data onboarding, in plain English

Everyone is talking about agentic AI. Almost no one has shipped an agent that actually operates a production data platform end-to-end. Walter does. As of today, WeTransform admins can configure formats, define transformations, adjust mapping rules, and manage exporters in plain English. Setup is only the first minute. The rest of the platform now runs by conversation.

Data import platforms don't stop at setup. Neither should agentic AI.

Most launch stories about AI in data tools stop at the first screen. An assistant sets up a target format, maybe a workflow, then hands the account back and disappears. Onboarding gets faster. Everything after onboarding stays exactly the same: menus, panels, forms, click paths that only a trained admin can navigate.

That was never the interesting problem.

The interesting problem is what happens once a WeTransform account is live. A customer sends a file with a new column. A partner switches from CSV to XML. A country goes live and needs a different validation rule. An exporter needs to skip a segment. In a traditional platform, every one of those small changes is a menu-driven admin task. Multiply that by a few dozen sources, a few hundred rules, a handful of destinations, and the admin panel becomes the bottleneck it was meant to replace.

Walter removes that bottleneck. Setup is only where the story starts. The rest of the platform, including B2B SaaS use cases for embedded imports, now runs on natural-language commands issued to an AI agent that has full context of your account.

What Walter actually does

Walter is an AI agent embedded in the WeTransform admin experience. You talk to it. It runs the platform.

Concretely, Walter can:

• Create a new target format, define its columns, types, validation rules
• Set up a source (file upload, API endpoint, email, FTP) and connect it to a target
• Define a full transformation pipeline: parse, clean, enrich, map, validate
• Add or adjust a single mapping rule ("when the source column reads réf produit, map it to sku")
• Change validation logic mid-flow ("reject rows where price is negative, but only for supplier X")
• Wire an exporter (webhook, API push, SFTP, email) and configure retries
• Create and edit workflows that chain sources, transformations, and exporters together
• Show what an action would do before doing it, when asked to propose rather than execute

The conversation is not restricted to a wizard flow. Walter has read access to your account structure and write access scoped to what your admin role can already do. You can ask for a change, a diagnostic, or a proposal at any point in the account's lifecycle, not only during initial setup.

What we mean when we say agentic in a data onboarding context

Agentic is the most overused word in B2B SaaS marketing in 2026. Before it loses all meaning, we want to be specific about how it applies here.

Data onboarding platforms have moved through three generations:

Generation one, manual. Someone writes parsers. Someone else clicks through admin menus to define every format, every rule, every workflow. Every change is a ticket. Every new source is engineering work. This is the baseline most B2B SaaS import stacks still run on.

Generation two, AI-assisted. Machine learning starts to help inside the workflow. Column mapping gets a suggestion engine. Cleaning gets automated where the model is confident. Humans still configure, maintain, and drive the platform through its native UI. The AI is a helpful copilot inside the same menu-driven flow.

Generation three, agentic. An AI agent runs the platform for you, in plain English, across setup and ongoing operations. The admin UI is still there, and still usable, but it is no longer the primary interface. The primary interface is the conversation. You describe what you want. The agent does it.

Walter is a generation-three product. It is the concrete expression of the idea we developed in the agentic import layer B2B SaaS needs: agentic B2B SaaS is only credible if the first-mile customer data layer becomes agentic itself. Walter is what we shipped to close that gap. For context on the broader category, see AI Import Management explained.

From empty account to running transformations, with Walter

The clearest way to make the shift feel real is to walk through one lifecycle, end to end.

Day one. A new WeTransform account is created for a mid-market SaaS that ingests supplier catalogs from thirty-plus vendors. The admin opens Walter and types:

Set up a target format called supplier_catalog. Columns: sku (string, required), name (string, required), price_excl_tax (decimal, required, must be positive), currency (three-letter ISO), stock (integer, optional), category (string, optional). Reject any row missing sku or name.

Walter creates the format, applies the types, sets the validation rules, and confirms. Total time, under a minute. Compare with the equivalent menu path: create format, add six columns, configure each type, set required flags, add two validation rules, save. Probably fifteen minutes and a screenshot in a Notion doc for the next admin to reproduce.

Day three. The first supplier sends a file. The columns are in French, one is called réf produit, another is TTC for a price including VAT. The admin opens Walter:

For supplier "MegaFournisseur", map réf produit to sku, map TTC back to price_excl_tax after dividing by 1.20, and treat the currency as EUR.

Walter proposes the mapping and the derived transformation. The admin reviews the proposal, confirms, and Walter applies it. That specific supplier now has its own mapping profile. Onboarding a supplier that would normally require a support ticket and an engineering task is done in a single message.

Day fourteen. A new business rule arrives from operations: for two specific suppliers, negative stock values should be treated as zero rather than rejected. The admin opens Walter:

For suppliers "MegaFournisseur" and "AlphaGros", replace negative values in stock with zero instead of rejecting the row.

Walter isolates the rule to the two named suppliers, adds it to their transformation profiles, and shows a preview of the affected rows. The admin approves. No engineering ticket. No cross-team meeting to align on scope.

Day thirty. The finance team wants a nightly export of the consolidated catalog to their pricing engine. The admin opens Walter:

Every night at 2 AM, push the full consolidated catalog to https://pricing.internal/api/catalog, using the standard webhook auth. Retry three times on failure. Alert me by email if all retries fail.

Walter configures the exporter, the schedule, the retry policy, and the alerting. Ships the same day.

Setup, per-source mapping, business rule adjustment, exporter configuration. Four separate lifecycle moments. Zero engineering time. This is what "in plain English" actually means. Not a fancier setup wizard. A platform that responds to natural-language commands from setup to end of life.

What agentic operation changes for CTOs, product teams, and customer success

The productivity story is not the interesting part. The interesting part is where the bottleneck moves.

For CTOs, the answer to "who owns import configuration?" changes. Before, it was engineering by default, whenever a rule change or a new source involved anything non-trivial. Now, it is whoever knows the business rule, which is almost always someone in operations or customer success. Engineering is out of the maintenance loop and back on the roadmap. The Sellermania case study documents the productivity impact of moving import ownership away from engineering, and Walter compresses that shift further.

For product teams, the buyer's evaluation criteria shift. "How long does it take to set up a new source?" was already a common demo question. The new one is "how long does it take to change a rule six months in?" Traditional platforms have never had a good answer. Walter's answer is a single sentence.

For customer success and implementation teams, the biggest change is the death of the recurring "please can engineering look at this" ticket. Onboarding, rule changes, exporter tweaks, all move into the same conversation channel. The team that owns the customer relationship also owns the platform configuration, without needing engineering translation.

For every one of these roles, the underlying shift is the same: the platform is no longer a set of menus that only trained admins can navigate. It is a conversation partner that any qualified operator can drive.

What's next: Walter for your customers, not just for you

Walter today is available on the admin side, for teams configuring their WeTransform account. That covers every WeTransform customer, in-house and embedded. It is the right first step because it is where format multiplication actually gets solved.

The next step is bigger. WeTransform is designed to be embedded inside our customers' products, so that their customers can upload data in any format. Extending Walter to that second layer, the customer of our customer, is the direction we are heading. Imagine a B2B SaaS whose end users can configure their own import behavior, in plain English, inside the embedded WeTransform experience. Format multiplication solved not just for your team, but for every operator in your customer base.

We are not committing to a public date for that release. What we can say is that Walter is architected for it. The permission model, the credit model, and the natural-language interface all scale down to a customer-facing surface. When the timing is right, we will ship it.

For now, Walter is live inside every WeTransform admin account. If you want to see what agentic data onboarding actually looks like in production, book a 20-minute demo.