Skip to content
Pedro Gomes
All work

Clínica Aurora

An agent that books, reschedules and cancels appointments in a separate clinic system, and refuses when a business rule says no. The clinic system it writes into is published next to it, so you can check the other side yourself.

Open the demo (opens in a new tab)
The agent rescheduling an appointment while the clinic system panel and the decision log update live

Who has this problem

A clinic’s front desk spends the day moving appointments. An agent only helps there if it writes into the clinic’s system, and that is also where it can do damage: changing the wrong appointment, breaking a rule, or saying a change happened when the system never recorded it. This demo shows what the agent does in each of those cases.

My role

Agent runtime, separate clinic API, deterministic policy engine and operator interface.

How to try it

  1. Open the demo. There is no signup, and you get your own copy of the schedule.
  2. Ask in plain language to book, reschedule or cancel an appointment, and confirm when the agent asks.
  3. Then try to cancel an appointment that starts within 24 hours, or switch the clinic system off with the button, and see what the agent does.

Usage conditions

  • Anonymous session with its own isolated schedule. Nobody sees or edits anyone else’s.
  • At most 3 writes per conversation, enforced by the policy engine.
  • A daily cap on turns and a kill switch, because the demo runs on a paid API key.
  • Nothing persists after the session expires.

Public access has usage limits to keep AI service costs under control.

Decisions I made

  • Two separate processes, on purpose. The agent talks to the clinic system over HTTP, exactly as it would talk to a real client system. That is what makes the "break the system" button mean something, and it is why the clinic system could be published with its own OpenAPI for anyone to inspect.
  • Five business rules live in a deterministic policy engine, not in the prompt: a cancellation inside 24 hours needs a recorded reason, nothing moves into the past, nothing moves onto a taken slot, nothing is booked outside opening hours, and there is a hard ceiling on writes per conversation. The rules are a versioned YAML file, and the version travels in every audit line, so months later you can prove which rule decided what.
  • Confirmation before a write is enforced by the runtime, not requested in the prompt. A write runs only when the same operation was proposed in an earlier turn and the person answered after it. A model that gets talked into skipping the step still cannot skip it.
  • No tool invents a result. If the clinic system did not record the change, the tool returns a typed error and the agent hands the conversation to a person, instead of confirming something that never happened. Switch the system off with the button and watch it happen.
  • The conversation is an explicit state machine with five declared reasons to hand over to a person. A transition that was not declared raises an error.
  • The interface is in English, and the agent answers in whatever language you write in, switching mid-conversation if you do.

Limits that remain

  • The companion clinic system is a demo service that models a client API. It is not a commercial clinic product.
  • The agent handles booking, rescheduling and cancelling. It does not touch payments or medical records.