agents that argue over a barber's calendar so nobody has to

A salon owner was losing bookings to WhatsApp chaos. Instead of another booking form, I gave the schedule to a set of agents and let them negotiate — in plain language, on behalf of whoever asked.

pauseddeploy's paused, not the project

drop the main screenshot for this project

0DOUBLE-BOOKINGS SINCE THE CONFLICT RESOLVER SHIPPED

Overlapping requests used to mean whoever asked second got rejected. Now a resolver agent reshuffles adjacent slots, checks barber skill and service duration, and comes back with a counter-offer instead of a no.

4AGENTS IN THE PIPELINE

NLENTIRE BOOKING INTERFACE

MongoDBSCHEDULE + STATE

multi-stepEXECUTION MODEL

FIG.2 — WHAT HAPPENS WHEN SOMEONE SAYS "6PM SATURDAY?"

01express

someone typesplain language, no form

02intent

work out the askservice, barber, rough time

03scheduler

check realityduration, skills, existing slots

04resolver

negotiatereshuffle rather than refuse

05confirm

commit + notifywrite, then tell both sides

react front end — one chat box, no booking grid
node/express API — agent orchestration
mongo — schedule, barbers, service durations

DECISIONS, AND WHAT THEY COST ME

nothing here was free

I CHOSE: agents over a booking form
BECAUSE: People describe time messily — "evening-ish Saturday". A form forces them to be precise before they've decided.
IT COST ME: far harder to test; edge cases are infinite

I CHOSE: modular agent pipeline
BECAUSE: Each step is swappable, so I can improve conflict resolution without touching intent parsing.
IT COST ME: more hops, more latency per booking

I CHOSE: counter-offers instead of rejections
BECAUSE: A rejected customer leaves. An offered 6:30 slot usually doesn't.
IT COST ME: resolver logic got genuinely complicated

I CHOSE: MongoDB for the schedule
BECAUSE: Bookings and service definitions kept changing shape while I was still learning the domain.
IT COST ME: I'm now enforcing consistency in code that a relational DB would've done for me