How Rely works / What the agent does

What the agent does, and where it stops.

Every action is approved for a specific workflow. Every stop names the person who accepts the work next.

Say, ask, do, and stop are different permissions.

Each behavior has its own rule, evidence, and failure path.

  1. 01Say approved information
  2. 02Ask approved question
  3. 03Do approved action
  4. 04Stop on configured signal
  5. 05Attach evidence
  6. 06Route to owner

Permission in one workflow does not generalize to another.

Say, ask, do, and stop are different permissions. Each behavior has its own rule, evidence, and failure path. The diagram shows Say approved information, Ask approved question, Do approved action, Stop on configured signal, Attach evidence, Route to owner. Permission in one workflow does not generalize to another.

The behaviour library

Four categories, four different rules

A capability listed here is not automatically active. The statement of work names the permitted actions, fields, owners, and fallbacks for your program.

01 · Routine work

Conditionally approved per workflow: outreach and inbound calls, bounded questions, scheduling, reminders, referral status, care-gap outreach, after-hours intake, and disposition write-back. The agent discloses that it is AI, follows approved wording and cadence, and routes anything it cannot complete. Scheduling permissions do not travel between programs. Contacting an outside organization receives separate clearance. Every attempt, including an unanswered one, receives a structured disposition and is reconciled to the source system.

02 · Data collection

Conditionally approved per field: caller intent, attempt history, reach status, nonclinical barriers, approved intake fields, stated exclusions, and the context packet for the next owner. Each field needs a purpose, destination, access rule, retention rule, and reconciliation path. Never attempted, unreachable, connected, and reached remain separate states. A reported barrier is not counted as resolved, and a patient-reported exclusion does not close a measure before the source system confirms it.

03 · Configured stops

Seven conditions end the agent's turn: a clinical question, safety-sensitive language, ambiguous intent, missing permission, bad data, system failure, or an out-of-scope request. The agent does not answer, guess, work around the boundary, or silently retry. It runs the approved route and fallback. A stop is designed behaviour, not closure. Exact triggers, destinations, acceptance windows, and fallbacks are configured and tested for the program before launch.

04 · Never

Prohibited in every program: diagnosis, prescribing or medication changes, clinical interpretation, independent urgency decisions, deciding clinical eligibility, hiding that the caller is speaking with AI, changing behaviour after one unusual case, or closing a case merely because time passed. Your licensed team writes eligibility and clinical rules; Rely applies only the approved logic. Novel exceptions enter change control, with evidence, regression testing, approval, a controlled release, and post-release monitoring.

After a stop

The work stays open until somebody accepts it

A stop creates owned work, not a transcript in a queue. The case carries the trigger, relevant context, prior attempts, permitted and prohibited actions, destination, and fallback. Assignment and acceptance are separate timestamped events.

Clinical questions, symptom interpretation, medication decisions, and urgent safety response go to your designated licensed team. Rely does not triage or decide urgency. Ambiguous or nonclinical exceptions may go to a Rely navigator where included in scope; otherwise they return to the customer owner named in the program.

  • Completed inside the agreed scope
  • Closed with a defined reason
  • Handed to an owner who explicitly accepted it

What holds the table up

Evidence required for every agent behavior

Three controls make the library auditable.

Tested before launch

Routine paths, exceptions, transfers, bad data, dependency failures, and every fallback are tested before live work.

Reviewed in production

Sampling, trace review, exception audit, source-system reconciliation, incident review, and controlled releases continue after launch.

Cleared per program

Data, disclosure, recording, consent, permissions, clinical stops, owners, and fallbacks receive separate, dated approval for each workflow.

Inspect the routine path and the stop.

A useful review follows one approved action through its stop, accepting owner, and fallback.