Marketplace · FranceIn progress
A role-aware assistant built on Claude with typed tools over the marketplace API. It books and confirms, collects deposits, drafts stories and daily summaries, suggests rebookings and helps clients reserve, with the tool list derived from the active space and approval before every write.
The marketplace's roadmap treats the assistant as a first-class interface, not a help widget. A shop admin tells it to book a client tomorrow at 14:00 and send a deposit link, to collect an outstanding balance by payment link or Tap to Pay, to draft a promotional story from authorised media, or asks for the morning summary of the whole shop. An artist asks for today's agenda, new reviews and their portfolio. A client asks it to find a slot for two services with the same professional, to rebook what they had last time at current prices, to buy a gift card or reserve a rental. The operations team uses it to inspect a failed operation and prepare a safe retry. Each role gets a different assistant because each gets a different set of tools.
The founder is non-technical, the app is built by a separate team, and the backend is ours. Every roadmap story from V2 onwards is written twice: in-app behaviour and agent behaviour per role, with the rule that app and agent must share the same permissions, business rules and reference data. That makes the assistant a backend project. We own it end to end: the tool layer over the REST API, the agent runtime on AWS, the approval flow, the operations console and, later, the channel adapters for Instagram, Facebook and WhatsApp, which the roadmap holds as conditional scope.
How the system is layered, from the people using it down to the data and the services it depends on.
The choices that made the difference, and why we made them.
A single account can hold a client space, a professional space and an artist space, and the owner switches between them without signing out. The assistant takes its tool list from the active space, so the same person gets booking and payment tools as a shop admin and only agenda, assignment and portfolio tools as an artist. Claiming a role in chat grants nothing; the server already knows who is asking and in which shop.
Reads are free. Writes go through two tools: a prepare step that reads live availability, price, deposit and policy and returns a proposal, and an execute step that only accepts an approval referencing that proposal. If the app changes the underlying data, or the user switches space, the proposal is invalidated and a late "yes" is rejected. The assistant cannot book last week's slot or charge a price that has since changed.
The assistant never gets a second copy of the business rules in a prompt. Confirmation paths, cancellation policies, commission, payout timing and gift-card credit all live in the API and are enforced there. When the assistant sends a deposit link, it calls the same code the app calls, and the appointment confirms itself through the same Stripe webhook.
Every agent operation is recorded with its request, the data that was checked, the confirmation, the result, its cost and any known failure. The operations team can find an operation, see what actually happened, and prepare a retry or a compensation that is executed only on an authorised decision. Partial failures are explained to the user rather than hidden.
The roadmap extends the assistant into rentals (condition photos compared before and after, mapped to the shop's damage schedule, with a human keeping the financial decision), gift cards and events, and into the shop's own Instagram, Facebook and WhatsApp channels using the same tools and permissions. Those channels are explicitly conditional on platform access and cost, and are described that way to the client.
Tell us what you're building. You'll get a straight answer on scope, timeline and cost, usually within one business day.