A human interface is not the whole product. If software's main job is to make a person repeat clicks, an agent may eventually take those clicks away. But the database, permission checks, payment network and message delivery still have to work.
Here is how I would redesign one workflow for that future: a customer asks to move an appointment.
Today: a screen-led workflow
A staff member opens a calendar, finds the customer, checks the original appointment, looks up the available slots, changes the booking, sends a message and writes a note. The screen holds all the steps together because a person is doing the work.
An agent-facing workflow cannot just expose a button that says "edit booking." It needs specific operations and rules.
Give the agent a narrow set of tools
I would separate the capabilities:
-
get_booking(booking_id): return the current time, status and owner. -
list_available_slots(service_id, date_range): return slots the business can actually honor. -
propose_change(booking_id, new_slot): check policy and hold the slot briefly, without yet telling the customer it is booked. -
commit_change(proposal_id): make one durable change, with an idempotency key so a retry does not create two bookings. -
send_confirmation(booking_id): send the new details only after the commit succeeds.
The model can interpret a customer's request. The service should enforce the booking rules. If the slot disappears or the booking belongs to someone else, the API must reject the change clearly rather than letting the model invent a success.
This is the boundary between reasoning and execution. Anthropic's agent design guide distinguishes fixed workflows from more flexible agents. Its Model Context Protocol offers a way for systems to expose tools and context. OpenAI's function-calling guide likewise describes models requesting tool calls while the application executes them. These documents show the design route, not proof that every business workflow is ready to automate.
What cannot be left to the model
A useful agent tool needs a contract:
- Identity: who is requesting the change, and can they touch this booking?
- Consent: can the business contact the customer on this channel?
- State: what changed since the agent last read the record?
- Undo: when can a change be reversed, and what does that cost?
- Audit: which tool call changed what, and who approved it?
- Fallback: what happens when a rule, payment or availability check fails?
The old app may still need a screen for a person to review an exception. "No UI" is not the goal. Fewer unnecessary human steps is.
The infrastructure test
Before building a chat front end, ask a harder question: can a machine call the core service safely, and can the service say no? If not, the new interface only hides a brittle process behind fluent words.
My prediction is that more value moves to these callable capabilities and the systems that carry them. Telecom still delivers the call. A payment rail still settles the charge. A database still records the change. An agent changes who operates the workflow, not whether those systems exist.
At GrowEasy.ai, where we build AI-assisted sales workflows, this is the design question I keep returning to: when an agent hands a lead to a human, is that a chat message, or a durable, permissioned state change the next person can trust?
Tej Pandya, founder of GrowEasy.ai
Top comments (1)