From models to golden records: An agent that manages Boomi Data Hub end to end

Ever worked with someone who "just knows" how the production system behaves — who can tell you a batch silently failed before the error even shows up? That knowledge never makes it into a tutorial. It's what you only get from actually managing primary data in production — knowing that a batch can report success and still merge nothing, that the algorithm you pick for matching last names quietly decides which customers become one record, that a model in draft bends to your will but a published one will fight you every step of the way. It's specific, it's earned slowly, and on most teams, it lives in one or two people's heads.

The newest skill in the Boomi Companion portfolio writes that knowledge down in a form that an agent can use. The boomi-datahub skill lets AI systems like Claude Code design, deploy, and steward your Golden Records against a live Boomi Data Hub, and get it right far more often than a model working from training data alone.

Two moments that used to go sideways

The clearest way to see what changes is to watch two moments where this work normally goes wrong.

The first is authoring a match rule — and if you've opened that console before, you know how intimidating it looks before you've made a single choice: simple expressions or advanced ones, exact equality or fuzzy similarity, a row of similarity algorithms (Jaro-Winkler, Levenshtein, Soundex among them), each with a tolerance you're expected to already know. Set it too loose, and you merge two different people who share a surname. Set it too tight, and real duplicates slip through as separate records.

With the skill, you describe the intent, "match on email, and treat similar last names at the same postal code as the same person", and the agent builds the rule, then tests it. Data Hub can score candidate records against existing golden records without writing anything, the agent runs the proposed rule against real data first, reads the computed match strength against the threshold, and tunes the tolerance before a single record is committed. The guesswork becomes evidence.

The second is the batch that "worked." This is one of Data Hub's sharper edges: an upsert can return HTTP 202 Accepted while every record quietly lands in quarantine — a mistyped field name, a missing wrapper, a value outside an enumeration. Accepted means received, not merged. If you don't know that distinction, you will spend an afternoon certain the data is live. The skill checks quarantine after every batch, tells you what actually became a golden record, and names the cause for whatever didn't.

In practice, it reads back something like this:

Batch accepted — so I checked what that actually meant. Seven of nine records are golden. Two are in quarantine: one FIELD_FORMAT_ERROR (Prospct isn't a valid status), one REQUIRED_FIELD (record 4 has no email). Want me to fix both and resubmit just those two?

Both times, you set the direction, and the agent supplies the expertise that keeps it from breaking somewhere out of sight.

What the skill actually does

The boomi-datahub skill ships in the bc-datahub plugin and covers the stewardship surface end to end: designing models, complete with field groups, repeating collections, references between models, match rules, and tags; configuring contributing sources and walking the initial-load lifecycle that makes them update-capable; moving a model through Draft → Published → Deployed; triaging quarantine; and operating golden records.

What makes that harder than it sounds is that Data Hub speaks through two different doors. The Data Hub Platform API handles account-level administration: models, sources, repositories, deployment, and answers in JSON for most reads. The Repository API governs the data itself, golden records and quarantine, and is XML-only for requests and responses. Knowing which door a task belongs to is half of doing the work correctly, and the skill routes every operation automatically.

The cost of getting that routing wrong is unusually steep. A repository's base URL is a shared Hub Cloud host, so the URL alone never identifies a repository; the auth token does. Aim a valid URL at the wrong token, and you authenticate cleanly into a different repository, then watch a "universe does not exist" error appear against data you can see in the console. The skill treats that as a hazard to confirm against rather than a coincidence to trust.

Built for the silent failures

When Boomi Companion launched, our take on the integration skill was that it worked not because of what we put into it but because of what we left out. Data Hub asked for the same restraint, for a sharper reason: this is a domain where quiet failures outnumber the loud ones, and a skill that only knows the happy path is worse than useless — it's confidently wrong.

So the skill is built around the ways things break. Every quarantine cause is documented with what triggers it and how to resolve it. The asynchronous source-attachment lifecycle, a chain of requested states the Platform settles on its own clock, is handled by tooling that waits each transition out, so the next step never fires too early. And where the Platform has known defects that would silently store a model wrong, the skill knows to stop and flag it instead of guessing.

The tooling stays deliberately small. Operations run through a handful of single-purpose Bash scripts, one per noun: model, source, repository, deployment, quarantine, and golden record, that build URLs, pick the right API surface, and read credentials from the workspace's .env file so secrets never ride in as command-line arguments. The agent is told never to hand-roll a request, because hand-rolling is precisely how the wrong-door, wrong-token mistakes get made. And the riskier capabilities are opt-in: reading or changing golden and quarantined data requires Repository API credentials, so you grant that reach only when you mean to.

The skill is also clear about where its job ends. Building the integration processes that feed a hub is the job of the boomi-integration skill, and the two are made to sit side by side; one moves the data, and the other governs it. The Data Hub skill will even bootstrap the connection an integration process needs to reach the hub, then hand off at the seam.

Why intelligence alone isn't enough

The reason a strong model still needs a skill like this isn't capability, it's information. The behavior that makes Data Hub work is specific, and most of it lives nowhere public. That ID is reserved at the model root. That a string field caps at 255 characters. That a published model still accepts new fields but freezes the types of the ones already there. Once deployed, the universe ID and the model ID are the same value, while the deployment ID is something else entirely. None of that comes from reasoning; it comes from knowing.

That's the whole job of a skill: it closes the gap between a general-purpose model and someone who has actually operated the Platform. The model brings the judgment. The skill brings the facts that let the judgment land somewhere real.

Try it

Install the bc-datahub plugin for Claude Code, which ships the boomi-datahub skill. Give it a workspace with your Platform API credentials in .env, add Repository API credentials when you want golden-record access, and the agent is ready to work against your hub right away. If you're already running bc-integration, the shared Platform details carry straight over, no extra setup needed.

Like the rest of Boomi Companion, the skill is open source under the BSD-2-Clause license, free to inspect, fork, and adapt to other agent platforms. It's a publicly available developer offering, not a supported product, curated on a best-effort basis, and made better by what the community sends back to developer-offerings@boomi.com.

Primary data has always been the exacting foundation under good integration work: easy to get subtly wrong, and dependent on a few people who knew its rules cold. Those rules now travel with the agent. Point it at your hub and see what comes back golden.