Skip to content
Julien Fleuridas
FR — Passer en français
← All projects

Agents · Automation

Padel booking agent

Booking a padel court by sending a simple message: "book a padel court tomorrow at 6:30 pm in Chartres".

PrototypeJuly 2026 — ongoingTwo-person project

In short

Problem
Booking a padel court means opening an app, finding a club, comparing slots, adding players and splitting the payment. About ten steps for a very simple decision.
Solution
An agent that understands a sentence, looks up the real available slots, suggests one, then prepares the booking. And that can never pay without confirmation.
What it brings
Booking takes one message, and the decision to pay always stays human.
Where it stands
A prototype for our own use. The building blocks are coded and deployment is ready, but a full booking over WhatsApp has not been redone recently.
My role
I designed the tools the agent can use, the link with the booking platform and the lock that stops it from paying on its own.

The problem

Booking a padel court takes about ten steps: open the app, find a club, compare slots, choose, add the players, split the payment. When the decision itself fits in one sentence.

What the agent does

It reads a plain message, like "find a padel court around 7 pm near Bastille, there are three of us", and turns it into actions: finding nearby clubs, reading the real available slots, looking up the players in a contact book, preparing the booking and splitting the payment.

The most important choice

The agent never pays on its own. It prepares the payment and stops.

That is what took me the most thought. Getting an AI to understand a sentence has become easy. Deciding what it can do without anyone checking is much harder. And when money is involved, the answer is clear: nothing without confirmation.

Show technical details

Tools rather than text

To act, the agent calls tools declared in advance, each with a precise role: finding a club, reading slots, adding a player, preparing a payment. A single, very broad tool would have made its behaviour impossible to control.

Integrations

Three modules: the booking platform client, the contact book, and place lookup, which makes it possible to understand "next to the Eiffel Tower".

Messaging

Two messaging services connected separately. Since it is the service's only way in, depending on a single provider was the most obvious risk.

What is missing

Automated tests. For a tool that deals with bookings and payments, that is the priority.

Numbers

4

building blocks developed

slot search, message understanding, booking, messaging

Source · repository progress tracker

2

messaging services

two providers connected separately, so as not to depend on one

Source · repository webhook servers

3

integration modules

booking client, contact book, place lookup

Source · integration package tree

What I did

  • Architecture

    I split the project into four independent building blocks: search, understanding, booking and messaging.

  • Agent design

    I defined which tools the agent can call, and under what conditions.

  • Assisted development

    The booking client, the contact book and place lookup were written in Python with coding assistants.

  • Quality control

    I designed the payment lock: the agent prepares the payment, it never triggers it.

  • Integration

    I connected two messaging services, so as not to depend on just one.

Evidence

  • An agent that uses precise tools

    verified

    The agent does not write a random answer: it calls precise tools, such as finding a club, reading availability, adding a player or preparing a payment. Its behaviour stays checkable.

    Source
    repository tool definitions and call loop
    Verify with
    Reading the tool definitions and the processing loop.

  • It cannot pay on its own

    verified

    The agent prepares the payment and stops there. Paying always takes a human action.

    Source
    repository booking flow
    Verify with
    Reading the booking flow and the payment gate.

  • Deployment ready

    verified

    The configuration of the server and both messaging services is written down and versioned.

    Source
    repository deployment and messaging files
    Verify with
    Reading the configuration files and associated documentation.

Limitations

  • The service is not open to the public, and nobody but the two of us has used it.
  • Booking goes through the Playtomic app, for personal use. It is not an integration approved by Playtomic.
  • If Playtomic changes how it works, slot search stops working.
  • The code is private, so it cannot be browsed from this site.
  • There are no automated tests yet. That is the first thing to add.
  • It is a two-person project: not every building block is mine.

What I take away

  • The hard part was not getting the agent to understand the request, but deciding what it could do on its own. The payment lock took more thought than everything else.
  • Giving the agent several small, precise tools rather than one big general tool makes its behaviour predictable.
  • Connecting two messaging services instead of one took a day, and avoided relying on a single provider.

What it could bring to a company

  • Any appointment booking by message (garage, clinic, gym) can work the same way, with the same human sign-off before paying.
  • A customer service team can give an agent a few precise tools on its booking system, without opening up the whole database.

Technologies

  • Python
  • Anthropic API (tool use)
  • Playtomic
  • WhatsApp Business API
  • Twilio
  • Render

Related projects