The between-visit gap: how AI agents keep care plans alive
The weakest point in many care plans is the moment after the patient leaves.
The practitioner has decided what should happen. The plan sits in a note or
portal. Daily life begins. Nobody knows whether the next step was understood,
started, paused, abandoned or made impossible by something the clinic never
saw.
An agent can help, but only if it carries an approved plan rather than inventing
a new one. It should make the next step clear, track its state, ask targeted
questions, suppress pointless reminders and return progress or exceptions to
the practitioner.
The job sounds simple. Most systems get it wrong by confusing follow-up with
more messages.
A plan needs a state, not a PDF
Consider a hypothetical clinic visit. The practitioner approves three next
steps:
- complete a laboratory test before a specific review date;
- take a ten-minute walk after dinner on selected days, if feasible;
- record one short note when fatigue disrupts normal activity.
The plan may be clinically sound. Operationally, it is still incomplete.
Each action needs:
- an owner;
- a start point;
- a current state;
- a cadence, if one exists;
- a reason to interrupt;
- a point at which silence is appropriate;
- an escalation or review condition;
- a way to close or change the action.
Without those fields, software can display the plan but cannot carry it.
The between-visit state machine
A useful action should move through explicit states:
| State | Meaning | Appropriate response |
|---|---|---|
| Offered | The approved action has been presented | Confirm that the patient can see and understand it |
| Accepted | The patient intends to proceed | Establish the practical start point |
| Active | The action is under way | Track only the agreed signal or check-in |
| Deferred | The patient intends to start later | Record why and when to revisit |
| Declined | The patient does not intend to proceed | Stop reminders and return the decision if relevant |
| Blocked | A practical or clinical issue prevents progress | Route the right exception, not a generic failure |
| Completed | The defined action has finished | Stop prompting |
| Outcome due | A response, measurement or review point has arrived | Gather the agreed evidence |
| Outcome unclear | The evidence cannot support a conclusion | Return uncertainty for review |
| Reassess | The practitioner needs to decide what changes | Preserve the history and wait for authority |
This is not administrative neatness. It prevents the system from treating
every unfinished action as the same problem.
The quiet-state rule
Most engagement software asks, “When should we send the next prompt?”
A safer question is, “What new information justifies interrupting this
person?”
The agent should remain quiet when:
- the next step is clear and not yet due;
- the patient has deferred it to an agreed date;
- the patient has declined;
- the same reminder has already failed to add information;
- the workflow is waiting for a laboratory result or clinician decision;
- the signal is too weak to warrant attention.
Clinical decision-support research has repeatedly warned about alert fatigue.
The same lesson applies to patients. Repetition can look like support in a
dashboard while feeling like harassment in daily life.
Silence is a designed state, not a system failure.
Where Kali and Kay fit
The distinction between deterministic and probabilistic agents becomes useful
between visits.
Kali can carry structured, approved flows. It can present the agreed action,
record the patient's response, follow programmed branches, apply a known
cadence and update a state that the clinic can audit.
Kay can help with open-ended language. A patient may say, “I was travelling
and the plan fell apart” or “I understand the test, but I cannot arrange it
before next month.” A probabilistic conversational system can extract the
practical issue, ask a bounded follow-up or explain an existing action in
clearer language.
The hand-off matters:
- Kali owns the authorised action and its allowed states.
- Kay may interpret the patient's language inside the released boundary.
- Deterministic checks decide which state changes are permitted.
- A clinical exception returns to the practitioner.
- Neither agent changes the care plan on its own.
This blend gives the patient flexibility without allowing a conversation to
rewrite clinical authority.
A practical example: the missed laboratory test
Suppose the test has not been booked five days after the visit.
A bad workflow sends: “Reminder: please complete your test.”
A better workflow first checks:
- Is the action still active?
- Has the patient already declined or deferred?
- Is the booking information available?
- Has a reminder already been sent?
- Is the deadline close enough to matter?
If a message is warranted, Kali can ask a structured question:
Which best describes the situation: booked, planning to book, cannot access
the test, unsure what to do, or no longer planning to proceed?
If the patient chooses “cannot access”, the workflow should stop treating the
problem as motivation. Kay may ask for a brief explanation, but a deterministic
policy should route the resulting issue to the appropriate clinic role.
The system has learned something useful: the action is blocked, not ignored.
Progress should return to the same story
Between-visit data often becomes another disconnected stream. The patient has
an app. The practitioner has an EHR. The coach has a spreadsheet. The wearable
has a dashboard. Everyone can see activity, but nobody can see the decision
history.
Follow-through should return to the same patient story:
- what the practitioner approved;
- what the patient accepted;
- what happened;
- what changed;
- what remains unclear;
- what now needs review.
The record should preserve both action and non-action. A declined intervention,
a practical barrier and a decision to wait are all clinically and
operationally different.
What the agents must not do
Between visits, an agent must not:
- change a treatment plan because the patient gave an unexpected answer;
- interpret non-response as defiance;
- keep prompting after decline or completion;
- optimise for app opens rather than useful care state;
- turn a wearable change into a diagnosis;
- send an ambiguous clinical exception into a generic support queue;
- allow Kay's conversational output to overwrite Kali's governed state without
validation; - let Kali's rigid branch ignore a clear request for human help.
The clinic audit
Choose five current care-plan actions and ask:
- Can we name the owner and current state?
- Do we know the next meaningful event?
- Is there a quiet state?
- Can the patient defer, decline or report a barrier?
- Does the system distinguish “not done” from “cannot do”?
- Can the practitioner see the evidence and history?
- Does a clinical exception reach a named role?
- Does prompting stop when the action closes?
If the plan cannot answer those questions, adding an AI conversation will not
repair it. The workflow needs a spine first.
The real opportunity
The consultation is a decision point. Care unfolds afterwards.
The practical value of an agent lies in carrying approved work across that
gap, preserving the patient's agency and returning useful state to the clinic.
Kali provides the repeatable structure. Kay handles language and ambiguity.
The practitioner retains the authority to change the plan.
Read how a clinician-controlled recommendation should be produced,
see Kalibra's continuous-care workflow or explore
software for functional medicine clinics.
Sources
- Ancker JS et al. Effects of workload, work complexity, and repeated alerts
on alert fatigue in a clinical decision support system. BMC Medical
Informatics and Decision Making. 2017. - NIST. Artificial Intelligence Risk Management Framework 1.0. 2023.
- World Health Organization. Ethics and governance of artificial intelligence
for health. 2021. - Kalibra. Kalibra Intro. Supplied 19 September 2026.
This guide is educational and does not provide medical advice.
