Skip to main content

Part 6: Run It End-to-End

Now the two layers cooperate. In this part you run BetaCorp's unstructured artifacts through the agent and into DataHub: the agent reads each artifact, extracts a structured candidate, and publishes it into the AGENT_CANDIDATE source — then DataHub runs its deterministic match and survivorship. The agent reads; DataHub decides. You will walk all six engineered outcomes and watch the governance story play out on the one ambiguous case.

You run each artifact conversationally against the deployed agent. (In production, an Integration process wraps the same agent in an automated onboarding flow — your instructor has a pre-built example — but the conversational path is how you run it here.)

Shared environment — observe the writes, don't multiply them

The agent publishing to AGENT_CANDIDATE writes into the shared golden record set. If everyone in the room publishes the same six artifacts into one repository, the golden records — and the numbers the Part 7 analyst reports — drift for everybody. In the shared workshop account, run this part in conversational / observe mode: invoke the agent and read its proposed candidate record and routing decision (publish vs. steward), but let the actual DataHub write be done once — by your instructor or pre-run. To run the full publish → match → survive loop end-to-end yourself, use your own trial (see the appendix).

The Reusable Onboarding Prompt​

Each artifact is a file in the sample-records bundle (see Prerequisites) — open the contract, note, or ticket to see the unstructured material the agent reads.

Run the publish-path artifacts (Northwind, Globex, Initech, Hooli, Wonka) with this prompt, replacing {ARTIFACT_ID} with the artifact you are onboarding:

Please onboard BetaCorp artifact {ARTIFACT_ID} into DataHub. Read the artifact, extract every legal entity, the corporate hierarchy, and commercial terms, check the golden record lookup for context, and then take the appropriate governed action to record each entity you find.
Phrase it as onboarding, not "decide if these are the same"

This prompt is phrased as an onboarding instruction. Do not phrase it as "decide whether these are the same" or "match this to the golden record" — the No Matching or Merging Decisions guardrail will (correctly) fire and block the agent before any tool runs. That is the governance design working as intended.

Outcomes 1–3: The Clean Matches (Northwind, Globex, Initech)​

These three artifacts each extract to a single entity that already exists in the Acme golden set.

  1. Onboard MSA_NW-2023-0412 (Northwind). The agent reads the contract, extracts Northwind Trading Company with aliases, tax 84-1102993, contract value USD 480,000 / NET30, renewal date, and products, finds a high-confidence golden hint (ACME-CUST-10241), and publishes a candidate. DataHub matches it onto the existing golden record on taxId.

  2. Onboard CRM_GBX-118 (Globex). The agent extracts Globex Corporation from the abbreviation in the note, tax 77-2048817, with a high-confidence golden hint (ACME-CUST-10588), and publishes.

  3. Onboard TICKET_INIT-4471 (Initech). The agent extracts Initech LLC and its contact from the ticket, tax 91-3320014, with a high-confidence golden hint (ACME-CUST-10912), and publishes. Contract value and renewal are left null because the ticket carried none — the agent does not invent values.

    What "publish" means here

    Each publish returns a DH-SUB-<id> submission id with decision DEFERRED_TO_DATAHUB. The agent explicitly states the candidate was submitted and DataHub will decide match and survivorship — it never says the records were merged. In conversational / observe mode the publish tool echoes that submission id and does not itself write to DataHub; the live publish → match → survive you see in a full run happens when the candidate batch is written to the Repository API (your instructor's pre-run of the candidate batch). Either way the agent only submits — DataHub then matches each candidate onto its existing Acme golden record via the taxId rule, with no duplicates created.

Outcome 4: Wonka — Net-New Clean Insert​

  1. Onboard TICKET_WONKA-2210 (Wonka). The agent extracts Wonka Industries, Inc., tax 39-7741200, USD 145,000 / NET30, contact Veruca Salt, and the golden lookup returns no match (net-new). The agent publishes a clean candidate, and DataHub creates a brand-new golden record.

Outcome 5: Hooli → Pied Piper — The Subsidiary the Contract Reveals​

This is the hard entity that proves the agent reaches truth the rules engine cannot see.

  1. Onboard MSA_HOOLI-2024-0033 (Hooli + Pied Piper). The contract's Schedule A clause names a subsidiary, Pied Piper Data Services, LLC, that the structured fields never carried. The agent:

    1. Extracts two entities — the parent Hooli, Inc. (tax 26-5519072, golden hint ACME-CUST-11030) and the subsidiary Pied Piper Data Services, LLC (net-new).
    2. Extracts the hierarchy link (Pied Piper → Hooli, parent golden id ACME-CUST-11030) and sets the subsidiary's parent_legal_name to Hooli, Inc.
    3. Attaches the commercial terms (USD 312,000 / NET60) to the Pied Piper subsidiary, where they belong.
    4. Publishes both candidates — parent first, then the subsidiary with its parent link — so DataHub can establish child → parent.
    Why this outcome matters

    The Pied Piper subsidiary existed only in a contract clause. No structured feed carried it. The agent reached it by reading the contract — exactly the unstructured truth DataHub's string-similarity engine is blind to — and recorded the hierarchy link so DataHub could establish the relationship. The agent surfaced it; DataHub linked it.

New: Upload the Real Contract​

So far the agent has fetched artifacts by id. As of this release, Agentstudio agents also accept file uploads directly in the conversation — so you can hand the agent the actual signed contract instead. Run the Hooli outcome again, this time from the document itself.

  1. Download MSA_HOOLI-2024-0033_PiedPiper.pdf from the sample records if you have not already.

  2. Ask Companion to invoke your agent with the file attached (point it at wherever you saved the download):

    Invoke my [builderInitials] Unstructured Onboarding Analyst agent with the file MSA_HOOLI-2024-0033_PiedPiper.pdf from my downloads attached, and this message: "Please onboard the uploaded BetaCorp contract into DataHub. Read the uploaded document, extract every legal entity, the corporate hierarchy, and commercial terms, check the golden record lookup for context, and then take the appropriate governed action to record each entity you find."

  3. Confirm the same engineered outcome reproduces from the raw document: two entities extracted (Hooli, Inc. and the net-new subsidiary Pied Piper Data Services, LLC with its hierarchy link and USD 312,000 / NET60 terms), and both published with DH-SUB-<id> submission ids.

    Give it a minute — and keep the onboarding phrasing

    A full run over an uploaded document takes a minute or two. Phrase the request as an onboarding instruction, exactly like the reusable prompt — "decide whether…" phrasings will (correctly) trip the No Matching or Merging guardrail. If the agent pauses to confirm the artifact id it read from the document, confirm it and the run proceeds. File uploads require the file input support setting you enabled in Part 5.

    Why this moment matters

    This is the lab's thesis in one gesture: you handed an AI agent a signed contract PDF — the exact kind of unstructured truth a deterministic MDM engine can never read — and it produced clean, governed, structured candidates for DataHub to decide on. No export, no staging, no hand-keying.

Outcome 6: Starke Ind. — The Governed Steward Exception​

This is the governance story. Run it with the steward-path prompt:

Please onboard BetaCorp artifact CRM_STK-902 into DataHub. Read the artifact, extract the entity, check the golden record lookup for context, and then take the appropriate governed action to record this artifact.

  1. Onboard CRM_STK-902 ("Starke Ind."). The agent reads the note and finds an unresolved identity with two conflicting signals — a Stuttgart/German plant pointing to Starke Industrial GmbH, and aerospace/defense plus an @stark-industries.com address pointing to Stark Industries. The golden lookup returns low confidence with two candidate matches (ACME-CUST-11144 and ACME-CUST-11145) and no single match.

  2. Confirm the agent does not publish. Instead it opens a steward exception (STEW-<id>, status OPEN, auto_published: false), passing both candidate matches and both conflicting signals to the data-stewardship queue. It states plainly that nothing was published to DataHub and that it did not pick a winner.

    The 0.92 threshold proves itself live

    Recall from Part 2 that "Starke Ind." cannot match Stark Industries (Jaro-Winkler ≈ 0.876, below the 0.92 threshold) and is blocked from Starke Industrial GmbH by the country gate. So even if a candidate were published, DataHub would not auto-merge it — the two golden records (Stark Industries, US; Starke Industrial GmbH, Germany) stay distinct. The agent's steward hand-off and DataHub's match rules both protect the same boundary: no guessing, no false merge.

The Final Consolidated State​

After all six artifacts run through the agent and the structured feed from Part 3, DataHub holds a single set of golden records:

  • The clean matches (Northwind, Globex, Initech, Hooli) merged onto their existing Acme golden records on taxId — no duplicates.
  • Wonka and Pied Piper created as net-new golden records.
  • Stark Industries and Starke Industrial GmbH preserved as two distinct golden records, never auto-merged.
  • "Starke Ind." held in a steward exception, with nothing written to DataHub until a human resolves it.
  • Cross-source survivorship confirmed: Northwind's golden record now carries NET30 payment terms from the BETACORP feed — a commercial field the Acme record lacked — surviving across estates into one golden record.

What You Now Have​

  • All six engineered outcomes reproduced live: three clean matches, one net-new insert, one revealed subsidiary, one governed steward exception.
  • Proof that the agent feeds and DataHub decides — including the near-duplicate that stayed distinct and the ambiguous case that deferred to a human.
The two layers cooperate

You ran unstructured BetaCorp artifacts through the agent and into DataHub and watched the boundary hold end-to-end: the agent extracted truth from contracts and notes DataHub could never read, while DataHub made every match, merge, and survivorship call — and a human steward, not the agent, owns the one ambiguous identity. Next, you will give all of this a voice — a conversational Customer 360 analyst leadership can simply ask.