Reltio AgentFlow is opening the door to "hands-off" data operations, where AI agents handle routine stewardship with minimal human intervention. One of the highest-value applications is automating Reference Data Management updates from a simple file upload — no mappings, no ETL, no custom UI work. This piece walks through how to design and build an agent that can do exactly that.
Reference Data Management sits at the heart of any serious MDM landscape: countries, currencies, industries, product hierarchies, customer segments, the value lists every downstream application depends on for consistency. The traditional path to keeping that data current is brittle and slow — spreadsheets manually transformed into RDM-friendly formats, mapping specs maintained between source columns and target attributes, and a queue of small change requests bottlenecked behind IT or data engineering. AgentFlow is designed to dissolve exactly that pattern. Instead of asking users to learn schemas or click through mapping screens, you give them a workflow that feels close to "drop the file, describe what you want, and trust the agent to do the rest." This article describes how to build that agent.
Why an Agent for RDM Updates?
Most RDM update problems share the same shape. A data steward has a CSV pulled from a source system, the agent has a target lookup with known semantics (Country, Industry, ProductCategory), and the work in between is mechanical — match columns to attributes, validate, upsert, report. Done well, an AgentFlow agent collapses that work from a multi-day cross-team task into a conversational interaction that completes in minutes. The user uploads, types a sentence describing intent, and reads a structured summary of what changed. The "smart assistant for reference data" framing matters because it sets the right design ambition: not an API wrapper with a chat front, but an actual collaborator that understands the file in front of it and explains what it's about to do before it does it.
Target User Experience
Before designing implementation, pin down the experience you want inside Reltio. The user uploads a CSV directly in the AgentFlow workspace and describes the intent in natural language — for example, "update the Country lookup with these new ISO codes and descriptions." The agent inspects the file, decides which columns map to which RDM fields, validates basic data quality, and generates the appropriate RDM payload. It calls the RDM APIs to insert or update values, and returns a friendly summary explaining what changed, what failed, and what the user might still need to address.
Four design pillars enable this experience: direct file upload, intelligent processing of structure and content, no explicit mapping configuration, and tolerance for multiple input formats. Each translates into a specific architectural decision, and each is essential — drop any one of them and the user is back to filling out forms.
Architectural Overview
At a high level the solution involves four cooperating components. The AgentFlow agent itself is the orchestrator that interprets user intent and drives the workflow. An AI reasoning layer handles column and field understanding, format recognition, and mapping inference. A file ingestion and parsing layer accepts CSV or text and converts it into a structured internal representation. And an RDM update layer encapsulates the calls to Reltio's RDM APIs for creating and updating lookups, values, and attributes.
A typical interaction starts when the user uploads a file with an instruction. The agent retrieves and parses the file. The AI infers the schema and mapping — recognizing, for instance, that "Code" maps to code and "Description" maps to name. The agent generates the appropriate RDM payload as a series of upserts or partial updates, calls the RDM APIs, and captures the responses. It then summarizes the outcome and, if needed, recommends another iteration or correction. Think of AgentFlow as the conductor, the AI model as the analyst, and the RDM APIs as the execution engine. Each layer has a narrow job, and the system stays understandable precisely because they don't blur.
Step 1: Define the Update Use Cases
Resist the urge to build a universal agent on day one. The fastest path to something useful is to define a small set of concrete RDM scenarios and design the agent against them. The most common are value list creation and update (country codes, currencies, languages, units of measure), domain-specific lookups (industry classification, product categories, risk tiers, loyalty tiers), and crosswalk tables (source code to canonical code mappings, legacy to new system codes).
For each use case, decide three things up front: the RDM lookup type involved, the minimal field set you expect (typically code, name, status, effective date), and the semantics you want for incoming data — upsert that updates existing codes and creates new ones, insert-only that rejects updates, or a hybrid that requires confirmation before overwriting. These choices flow directly into your validation logic and the prompts you craft for the AI model. Get them right early and the rest of the build is mostly mechanical.
Step 2: Enable Direct File Upload
The user shouldn't need any preprocessing. The goal is "drop the CSV and go." That means accepting CSV as the primary format while being lenient about delimiters (comma, semicolon, tab), allowing structured text as a backup for tables pasted from other systems, storing the file in a temporary secure location for the duration of the run, and enforcing reasonable size and row caps for performance — typically 5–10 MB and tens of thousands of rows per execution.
Implementation usually involves a file input on the AgentFlow task UI (or an endpoint if you're integrating via API), passing the file reference into the agent's context so the parsing layer can retrieve it, and routing the raw bytes through whichever runtime you've chosen for parsing — Python, Node, or a service. From the user's perspective it should feel close to uploading a file to a web form, but with an AI assistant working on the other side of the upload.
Step 3: Intelligent Processing
This is where the AI earns its keep. The agent needs to detect file type and delimiter automatically, infer column meanings and map them to RDM attributes, and validate or normalize values where it can. A layered approach works well. The basic parsing layer uses a CSV parser to extract header names and rows, and samples the first few rows to recognize numeric codes versus text descriptions. The AI inference layer is then asked something close to: "You are an RDM assistant. Given the header names and data samples, map each column to one of: code, name, description, sourceCode, status, startDate, endDate, parentCode, or ignore if not relevant." A small JSON schema constrains the output, and optional hints about the target lookup type sharpen the accuracy. A validation layer checks that mandatory fields are present, flags suspicious columns (such as multiple candidates for "description"), and surfaces ambiguity to the user when confidence is low.
The objective is a clean, explicit mapping structure that the agent can apply mechanically across every row:
{
"lookupType": "Country",
"columns": {
"Code": "code",
"Country Name": "name",
"ISO2": "sourceCode",
"Status": "status"
}
}Once that mapping exists, the rest of the pipeline becomes deterministic.
Step 4: Remove Manual Mapping
Traditional data onboarding requires users to click through screens linking columns to target fields. The agent should kill that step. The AI decides the mapping, the mapping is recorded in the agent's reasoning output for traceability, and the user only steps in when something is genuinely ambiguous — for instance, an optional confirmation step on high-risk domains.
A few design choices make this dependable in practice. Use consistent header naming conventions across the templates you publish to your business teams. Maintain a small internal dictionary of synonyms (Code, CD, Value, Key all mapping to code) so the AI doesn't have to guess every time. And let the AI see past successful mappings as in-context examples, which raises hit rates noticeably on subsequent uploads. A useful enhancement is to persist the inferred mapping with the file or lookup type so future uploads with similar headers reuse it automatically — the agent learns the dialect of each domain over time.
Step 5: Support Multiple Input Formats
CSV is the natural primary format, but real life brings variety. Adoption climbs when the agent also handles standard CSV (commas, UTF-8), semicolon and tab-delimited files from legacy systems, and structured text pasted into a textbox — pipe-separated, Markdown-style tables, and similar. The simplest reliable strategy is to attempt CSV parsing with multiple delimiters and fall back to a heuristic split (newlines, then the most frequent delimiter character on each line) when parsing produces a single huge column. Whatever the input, normalize it into a single internal tabular format — headers plus a rows array — before handing it to anything downstream. From the agent's perspective the format question disappears; it always operates on the same shape.
Step 6: Generate RDM Payloads
Once the file is understood and the mapping is fixed, the agent translates rows into valid RDM API payloads. Each row becomes a candidate reference value. Existing codes are updated, new codes are created, and an optional deactivation step can handle codes that disappear from the latest file (use this carefully — silent deactivation is one of the easiest ways to break downstream systems). A typical per-row structure looks like:
{
"code": "US",
"name": "United States",
"attributes": {
"iso2": "US",
"status": "ACTIVE"
}
}Batching matters here. Chunk rows into batches of 500–1000 to avoid oversized requests, implement basic retry logic for transient failures, and capture per-row success and failure for the final report. Once batching is in place the agent is doing nothing but deterministic transformations and API calls. The "smart" part of the system is already behind it.
Step 7: Call the RDM APIs
The agent needs a small RDM integration layer that authenticates against Reltio (typically via client credentials) and exposes a handful of well-named functions to the orchestration logic. The most useful surface area is getLookupValues(lookupType, codes) for fetching what already exists, upsertLookupValues(lookupType, values[]) for the main update path, and deactivateMissingValues(lookupType, fileCodes) as an optional cleanup step. The orchestration logic fetches existing values to distinguish updates from inserts, builds upsert lists per batch, sends each batch, logs the responses, and accumulates statistics for the final summary.
From the agent's perspective these become tools. We typically expose three: tool.rdm.previewChanges for a dry-run that shows what would change without writing anything, tool.rdm.applyChanges for the actual upsert, and tool.rdm.exportLookup for pulling current values when the user wants a before/after view. Splitting preview from apply is the single change that does the most for user trust — it lets stewards see exactly what the agent intends to do before it does it.
Step 8: Conversation Flow
The agent shouldn't process silently. The interaction is itself part of the value. A good conversation flow walks through five beats. First, initial understanding: "I've detected a CSV file with three columns and 500 rows. It looks like Country data. I'm mapping Code → code, Country Name → name, ISO2 → sourceCode." Second, optional confirmation on high-risk domains: "Do you want to review and confirm this mapping, or should I proceed?" Third, a preview of impact: "I found 450 existing codes that will be updated and 50 new codes that will be created. No values will be deactivated." Fourth, execution with progress narration: "Applying batch 1 of 5 (100 rows) — done." And fifth, a final summary: "Updated 450, created 50, failed 0. You can export the updated lookup for verification."
That structure builds trust. The agent feels like a collaborator that explains its reasoning, not a black box that occasionally produces a status code.
Step 9: Edge Cases and Governance
Production RDM changes carry real risk, and the agent should be opinionated about its guardrails. On validation, reject rows with missing mandatory fields, flag duplicate codes inside the same upload, and run basic referential checks such as confirming parent codes exist before they're referenced. On environment handling, run new mapping patterns first in a lower environment and promote to production only after the agent's outputs match expectations; for high-impact updates, require an approval step or change ticket. And on auditability, log who initiated each agent run, which file was used, and the diff that was applied — store a snapshot of both the input and the generated payload for traceability. The agent can surface this in its final response: "Run ID 4837, initiated by sudhir@apptadinc.com, with 500 total changes applied to the Country lookup in environment prod-eu." That sentence alone has saved more change-control conversations than most documentation.
Step 10: Toward a Reusable Template
Once the core design is working for one domain, it generalizes naturally into a reusable pattern. Parameterize the lookup type so the same agent can target Country, Industry, ProductCategory, or any new domain you add later. Maintain domain-specific sample prompts and mappings so each domain's quirks are captured rather than rediscovered each time. Allow per-domain configuration of validation rules — ISO format for Country, allowed value ranges for ProductCategory, parent-child constraints for hierarchies. With those three layers in place, business teams can self-serve new RDM automation patterns with very little engineering involvement. What started as a single agent becomes a file-driven RDM agent factory.
A Concrete Example: Country Codes
To tie it all together, picture the everyday version. A data steward downloads the latest country list from a CRM and adds a few markets the company has just expanded into. They open AgentFlow, select the "Update Country RDM" agent, upload the CSV, and type: "Update the Country lookup with this list. Create any missing codes and update names where they've changed. Don't deactivate any values." The agent parses the file, infers the mapping, and shows a preview. The steward accepts. Within a minute the lookup is updated, and the steward gets a human-readable report and a link to export the new list for downstream verification. No mapping configuration. No developer ticket. No custom pipeline. Just an agent doing the work that used to require three teams and a week.
That's what AgentFlow makes possible — and RDM is only the start.
