Skip to main content

Part 5: Build the Unstructured Onboarding Analyst Agent

This is the agent at the center of the lab. The Unstructured Onboarding Analyst reads that material, extracts clean structured candidate records, and publishes them into DataHub's AGENT_CANDIDATE source. It never matches, merges, or runs survivorship — DataHub decides that. Low-confidence or ambiguous identities are handed to a human steward rather than guessed.

Tool backing

The agent's eight tasks are each bound to a tool from the Customer360 MA API MCP source. That MCP source and its backing mock API are pre-registered by your instructor (see Prerequisites) — in this part Companion builds the agent's profile, tasks, and guardrails and binds each task to a tool from that shared source. Part 4 walked how the API was governed and the source registered.

Plan our Agent Build​

We now have a good working understanding of our data model, and we've built an integration to contain the determinstic logic for pushing candidate records. Our next step is building the agent to automate the onboarding process. To do this, we need to start by making a plan.

Our agent needs to be able to do the following things:

  1. Read BetaCorp's unstructured customer material and pull out the truth our simple string matching in Data Hub can't do.

  2. Turn the data it reads into structured candidate records for Data Hub and publish them via the AGENT_CANDIDATE source. Leave the actual matching and survivorship to Data Hub

  3. Use the tools in the pre-registered MCP source (Customer 360 MA API) for every read and write step

  4. Accept uploaded files (pdf and txt) so the agent can read an actual raw contract.

Copy this text, and ask our Companion session to make a plan to execute this.

Build the Agent​

Now that we have a plan, we can build our agent. Instruct Companion to build the agent we've planned.

  1. In Companion:

    Based on the plan we just developed, implement the agent in Agent Studio using the agent-management skill. Make sure that the agent name is prefixed called [builderInitials] Unstructured Onboarding Analyst Agent

  2. Confirm Companion reports the agent created with: the Professional voice and objective; eight tasks, each bound to its tool from the Customer360 MA Mock API MCP source; two guardrails; and file uploads enabled (file_inference_config allowed, with pdf and txt).

    The golden-record lookup is context, not a decision

    The lookup tool may return a candidate Acme customer id and a confidence level. The agent records it only as a hint for DataHub — never as "these are the same customer." When confidence is low or there are multiple candidate matches (the "Starke Ind." case), the agent routes to a steward exception and does not publish.

    File uploads — enabled here, used in Part 6

    The prompt turns on file input (file_inference_config with allowed: true, types pdf and txt) so that in Part 6 you can hand the agent the actual signed contract PDF instead of an artifact id. Uploads are capped at 5 files per invocation, 2 MB per file, 10 MB total (types include pdf, csv, txt, docx, xlsx). Without this setting an upload is rejected with "Agent does not support file uploads." The setting rides with the agent definition — the deployment you create next carries it.

Deploy the Agent​

  1. Ask Companion to package and deploy the agent:

    Package and deploy my [builderInitials] Unstructured Onboarding Analyst agent, and confirm the deployment reaches ACTIVE.

  2. Confirm the deployment reaches ACTIVE.

    Agent activation

    An agent activates by creating a package and then a deployment. Once the deployment is ACTIVE on the Agent Garden runtime, the agent is invokable conversationally — and, in production, from an Integration process (your instructor has a pre-built example).

Review in Agentstudio​

Companion did the building; now use the platform UI to review the result. This step is review only — do not edit the agent in the UI.

  1. In the platform, open Agentstudio → Agent Garden and open your [builderInitials] Unstructured Onboarding Analyst agent.

  2. Verify the profile shows an objective aligned with our description.

  3. Verify all tasks align and that each is bound to its relevant tools from the Customer360 MA Mock API MCP source.

  4. Verify the guardrail presence and alignment.

  5. Verify file uploads are enabled and the deployment shows ACTIVE.

    Phrase onboarding prompts carefully — the guardrail works

    During testing, a prompt phrased as "...and decide whether to publish a candidate or open a steward exception" caused the No Matching or Merging Decisions guardrail to fire and block the agent before any tool ran — the agent correctly refused to make a "decide which record" call. Re-running with a neutral onboarding phrasing — "take the appropriate governed action to record this artifact" — let the agent do its job and route correctly. This is the intended governance behavior. When you test the agent (Part 6), phrase prompts as an onboarding instruction, not as "decide whether these are the same," or the guardrail will (correctly) block it.

What You Now Have​

  • The Unstructured Onboarding Analyst agent with six read/reason tasks and two governed write tasks — built from a single Companion prompt.
  • Two Control Tower guardrails that keep the agent out of the match/merge lane and force a steward hand-off on ambiguity.
  • File uploads enabled, so the agent can read an uploaded contract directly in Part 6.
  • A deployed, ACTIVE agent — reviewed in Agentstudio — whose tools are already governed. You walked that governance in Part 4; next you run the agent end-to-end in Part 6.
The agent is built

You built an agent that reads the unstructured customer truth DataHub structurally cannot — and guardrailed it so it proposes and defers rather than deciding. Next, you will run the consolidation end-to-end and watch DataHub match and survive the candidates the agent proposes.