Skip to main content
This example walks through building a care coordination workflow that an AI agent or integration invokes over A2A on your org runtime. V1 uses a HASP API key with workflow:invoke; the narrative still describes Dr. Patel as the clinical owner because audit and policy treat agent-triggered runs as delegated automation under org control.

​
What you’re building

ResourceDescription
Workflow (Agent-callable)Care coordination — invoked via A2A
Entitycare_plan — coordination record with status and next steps
IntegrationEHR REST API (update patient chart)
IntegrationScheduling system (book follow-up appointment)
IntegrationSlack (notify care team)
API key (V1)Org key with workflow:invoke for POST /a2a/...

​
Step 1: Create the project

Click New Project. Name it Care Coordination.

​
Step 2: Author the workflow

In chat:
“I need a workflow that an AI care coordination agent can invoke on Dr. Patel’s behalf. The workflow should: look up the patient’s current care plan, check for any open care gaps, book a follow-up appointment if there’s a gap, update the EHR chart with the action taken, and notify the care team in Slack. The agent should be able to do this without Dr. Patel being at her keyboard.”
The system:
  • Asks: “I’ll make this an agent-callable workflow — accessible to an AgentCaller acting under Dr. Patel’s authority. Does that sound right?” → Confirm.
  • Creates a care_plan entity with fields: patient_id, open_gaps, last_reviewed, next_appointment, status
  • Creates the care coordination workflow with trigger: agent invocation
  • Compiles steps: look up care plan → check for open gaps → condition → book appointment (scheduling integration) → update chart (EHR integration) → notify care team (Slack integration)

​
Step 3: Add the integrations

Add three integrations in Settings → Integrations:
  1. EHR API — Custom HTTP, base URL: https://ehr.acme-health.com/fhir/r4, Bearer auth
  2. Scheduling — Custom HTTP, base URL: https://schedule.acme-health.com/api, API key auth
  3. Slack — Slack incoming webhook, workspace: Acme Health, channel: #care-team

​
Step 4: Create an API key for A2A (V1)

In Settings → API Keys on the platform:
  1. Create a new key restricted to this org.
  2. Grant the workflow:invoke scope (and any other scopes your automation needs).
  3. Copy the plaintext secret once (hasp_key_live_…). Store it in your agent’s secret manager.
Dedicated Agent Access / AgentCaller credentials are planned; until they ship, the runtime accepts the same org API keys used elsewhere.

​
Step 5: Simulate an agent invocation

From the test/run console (the center pane for headless workflows), compose a trigger payload matching what you will later send as JSON-RPC params on A2A: 
{
  "patient_id": "pat_01JA7QG2...",
  "context": "Post-discharge follow-up check"
}
Click Run (Sandbox).

​
Step 6: Inspect the trace

The trace shows:
  1. api_key_validate — org API key valid; org matches runtime subdomain; workflow:invoke scope present
  2. entity_read — looked up care plan for pat_01JA7QG2. Found 1 open care gap: annual diabetes screening overdue.
  3. condition — open_gaps > 0 → true
  4. book_appointment — sandbox: “would have booked follow-up appointment on 2026-05-15 at 10:00 AM.”
  5. update_ehr — sandbox: “would have updated EHR chart with note: Follow-up booked for diabetes screening.”
  6. entity_write — care plan updated: status: follow_up_scheduled, next_appointment: 2026-05-15
  7. notify_slack — sandbox: “would have posted to #care-team: Patient [anonymized] follow-up scheduled.”
All integration calls edge-sandboxed. No real calls made.

​
Step 7: Release and connect the agent

After release, the workflow is live. Configure the CareCoordinatorAgent with a HASP org API key that includes the workflow:invoke scope (see A2A protocol). Discover the exact JSON-RPC URL from GET https://acme.usehasp.run/.well-known/agents.json: each capability card includes an endpoint field — POST to that URL (not a separate invocation_url field). 
POST https://acme.usehasp.run/a2a/care-coordination/care-coordination-run
Authorization: Bearer hasp_key_live_<your_api_key>
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "method": "invoke",
  "params": {
    "patient_id": "pat_01JA7QG2...",
    "context": "Post-discharge follow-up check"
  },
  "id": "req-001"
}
The run is attributed to your org and API key; every step is audited. Every integration call is real in production mode. (Dedicated AgentCaller OAuth credentials will add explicit delegating-user semantics on top of this path.)

​
Audit trail

Every invocation produces an audit record:
  • Org, API key (V1), workflow, and run identifiers
  • Full execution trace with step-level inputs and outputs
  • EHR API payload and response (PHI-processed)
  • Slack notification content (anonymized)
  • Care plan entity mutation with before/after values
Dr. Patel can review all invocations from the Studio audit log. She can rotate or revoke the API key used by the agent at any time; new requests fail immediately.

​
What changes between shifts

At the start of each shift, create or rotate a dedicated API key for the care-coordinator integration (narrow scopes, short-lived keys where policy allows). The agent configuration picks up the new secret; revoke the old key when the shift ends. When AgentCaller credentials replace key-based invocation, the same operational pattern applies per shift credential.

​
Extending the example

  • Multi-agent delegation: the CareCoordinatorAgent delegates a sub-task (e.g., medication reconciliation) to a MedRecAgent with a narrower scope credential — entity read only, no EHR write, no scheduling.
  • Escalation: add a step that checks if the agent’s scope is insufficient for the action required and escalates to a human via the on-call notification integration.
  • Approval gate: for actions above a risk threshold, require a human approval step in the workflow before the EHR write executes.