Module 1 — Build the Change Risk Assessor Agent

Goal: learn the describe → generate → validate → publish → run loop by building a simple agent that scores the business risk of a change to BenefitConnect.

What you'll build: an agent that reads a change request, scores it across five risk dimensions, and then decides whether the change needs a human review before testing starts.

1. Set up your working folder

mkdir change-risk-assessor
cd change-risk-assessor
mkdir samples

Download the two sample change requests from your instructor into samples/:

Change request	Scenario
CR-1001-button-label.pdf	Low risk: relabel a button in the enrollment wizard
CR-2004-adoption-life-event.pdf	High risk: add a new "Adoption" life event type

2. Give your coding agent the instruction

Open your coding agent and paste this:

Using the UiPath agent skill, generate a low-code agent named
"change-risk-assessor-agent". The agent takes two file inputs:

Inputs:
- in_ChangeRequestPDF — the change request / user story (PDF)
- in_SystemContextPDF — a short document describing the BenefitConnect area
  affected (business criticality, compliance sensitivity)

The agent evaluates the change across these five risk dimensions:
1. Business criticality — does it touch a critical path (enrollment,
   payroll data, compliance-sensitive fields)?
2. Change scope — how many components/screens/APIs does it touch?
3. Regulatory/compliance sensitivity — PII, benefits eligibility, audit
   trail impact?
4. Test coverage gap — is this area already covered by existing tests
   (per the system context document)?
5. Change type risk — new feature vs. modifying existing critical logic
   vs. a simple bug fix (modifying existing critical logic is highest risk)

Return output matching this structure:

{
  "out_riskLevel": "low | medium | high | critical",
  "out_riskSummary": "string — plain-language explanation of the decision",
  "out_riskAssessmentJSON": {
    "change_id": "string",
    "escalate": "boolean — true if this change needs human review before test planning",
    "risk_factors": {
      "business_criticality": { "result": "low|medium|high", "detail": "string" },
      "change_scope": { "result": "low|medium|high", "detail": "string" },
      "compliance_sensitivity": { "result": "low|medium|high", "detail": "string" },
      "coverage_gap": { "result": "low|medium|high", "detail": "string" },
      "change_type_risk": { "result": "low|medium|high", "detail": "string" }
    },
    "recommended_test_priority": "string — what to test first and why"
  }
}

- Any risk_factor result of "high" that relates to business_criticality or
  compliance_sensitivity should set escalate = true.
- Do not infer information not explicitly present in the two input documents.
- Write the system prompt with property-and-casualty/enterprise-SaaS change
  management best practices in mind.

3. Watch it scaffold

Claude Code will create a solution, set up the agent inside it, write the system prompt, configure the input/output schema, and run a validate step. Approve each step as it goes.

4. Upload and open in Studio Web

uip solution upload change-risk-assessor-solution --output json

Open the DesignerUrl from the output in Studio Web.

5. Run both sample scenarios

In Studio Web, click Debug, provide in_ChangeRequestPDF and in_SystemContextPDF, and run each scenario:

• CR-1001-button-label.pdf should return out_riskLevel: "low" and escalate: false
• CR-2004-adoption-life-event.pdf should return out_riskLevel: "high" or "critical" and escalate: true

Note

The wording of the output is generated by an LLM, so it will vary between runs. The structure and each factor's result should still match.

Stuck?

Your instructor has a known-good version of this agent's output. Use it to move on to Module 2 instead of spending the whole session debugging Module 1.

Done

You've built, published, and run your first agent. Module 2 builds its orchestrated flow on top of it.