Where a person must approve: designing human checkpoints

A discharge summary is a good place to start

A 200 bed multi speciality hospital in Indore discharges forty to sixty patients a day. Each patient leaves with a discharge summary: diagnosis, procedures, medicines with doses, follow up dates and warning signs. Resident doctors write these at the end of long shifts, pulling details from case sheets, lab reports and nursing notes. Delays at discharge hold up beds, and a missed dose instruction can send a patient back.

An agent can draft most of the summary from the records the hospital already has. A doctor still reads every summary before it reaches a patient. The design questions are where that review happens, what the doctor sees, and how to make sure the approval means something.

Sort every action into three groups

List every action the agent can take, then place each one in a group.

Act without approval

Actions that are easy to undo, low in consequence and inside your own systems. Collecting lab results into a draft, filling a form field from a record, tagging a ticket, sending an internal notification. A person still sees the outcome, but nobody needs to say yes first.

Act after approval

Actions that leave the building, change money or records, or affect a person's health, credit or job. Sending the discharge summary to the patient. Posting a voucher in Tally. Sending a payment reminder to a borrower. Rejecting a job applicant. Changing a customer's order. These wait for a named person.

Never act

Actions the agent should not take even with approval, because a person should do them directly. Changing a diagnosis, approving a loan, deciding a refund above a set amount, deleting records. The agent may prepare information for these, but the action itself stays outside its permissions entirely.

Write the groups down and get the people who own each process to sign them off. In AksharAI these become action boundaries in the agent's guardrails, so the agent cannot take an action outside its group even if a prompt tells it to.

Put the checkpoint where the decision is

A common mistake is placing the approval at the very end, after the agent has made several choices in a row. The reviewer then sees a finished document and has to work out which parts the agent decided. It is better to put the checkpoint at the step where judgement is needed.

In the hospital example, the agent might first propose the list of discharge medicines by reading the medication chart. That list is the step that matters most, so the doctor confirms it there. The rest of the summary, built from the confirmed list, needs a lighter read.

Give the reviewer what they need to decide

An approval screen should show:

• The draft, with the parts the agent wrote clearly marked.
• The sources, linked or shown alongside. The doctor should see the lab value the agent quoted next to the agent's sentence about it.
• What the agent was unsure about. Flags such as "two different doses found for metformin in the chart" are more useful than a confidence score.
• What happens next if the reviewer approves.
• Simple controls: approve, edit and approve, send back with a note, or reject.

If reviewers have to open three other systems to check a draft, they will either take too long or stop checking.

Keep reviewers alert

When an agent is right most of the time, people start approving without reading. This is the real risk of human in the loop systems, and it needs active design.

• Show what changed. Highlight what differs from the usual pattern for this patient or this supplier.
• Route harder cases to more senior people. A summary for a patient with a complicated medication history goes to the consultant.
• Sample approved work. Each week, a second person rechecks a small sample of approved items. Mistakes found this way show whether reviewers are reading.
• Track edit rates. If reviewers almost never edit, either the agent is very good or they are not looking. Sampling tells you which.
• Limit queue size. A reviewer facing two hundred items at five in the evening will not read them properly. Spread the work or add reviewers.

Record who decided what

Every approval should log the reviewer's name, the time, what they saw and what they changed. In a hospital this sits alongside the clinical record. For an NBFC it supports audits. For any business, it answers the question "who sent this?" clearly, and it keeps accountability with people, where it belongs.

Limits to plan for

Human checkpoints slow things down by design, so the agent saves less time on approved steps than on unattended ones. Plan for this. A discharge summary that a doctor reads and corrects in four minutes, where writing it took twenty, is still a real gain.

Checkpoints also do not remove liability. In regulated work, such as clinical documentation or lending, the professional who signs remains responsible. The agent prepares, the person decides, and your policies should say so plainly.

Review design also depends on the people. If doctors find the screen awkward, they will work around it. Test the approval screen with the actual reviewers before launch and change it based on what they say.

Checklist

• Every agent action placed in act, approve or never act
• Groups signed off by the process owners
• Checkpoints at the steps where judgement is needed
• Review screen shows sources and the agent's doubts
• Harder cases routed to senior reviewers
• Weekly sample of approved work rechecked
• Every approval logged with name, time and edits

You can set action boundaries, approval steps and logging for each agent under Deployment and governance.