Smart Parking Multi-Agent System - Case Study

A practice design I use to make the Agentic System Design Checklist concrete. The starting point is an ordinary set of parking microservices that are purely reactive. Agents make the system proactive, using a hybrid manager-worker pattern.

Starting point

Four existing services:

• Sensor: real-time occupancy per space.
• Booking: reservations.
• User: profile and payment.
• Notification: alerts.

Why agency?

• Proactive help: re-plan if a jam builds up near the destination.
• Complex reasoning: dynamic pricing around local events.
• Personalisation: cheap, covered, shaded, EV charging, family-friendly.
• Robust error handling: if a few sensors drop out, mark the zone temporarily unavailable and use neighbouring readings.

Doing all of that with rules means thousands of lines of code that are still reactive.

Architecture

The driver agent sends a parking request to a zone agent; the zone agent asks sensor agents for occupancy; a reservation agent claims the space. Zones hand off to neighbouring zones when they’re full, and a manager agent coordinates the workflow and reports back to the driver.

The agents

Each agent is written up as Interface → Reasoning → Tools → Memory, then given an orchestration style (ReAct vs Plan-and-Execute).

Agent	Reasoning	Tools	Memory	Style
Driver (mobile app)	Extract entities from “I need a cheap covered spot near…” and build a structured request	Manager.requestParking(req), Notification.sendUpdate	Short: the conversation. Long: profile, vehicle, payment, past choices	ReAct
Zone	Watch traffic, capacity and EV chargers; alert neighbours; price dynamically for events; fall back to nearby sensors	Notification(msg, severity), Manager(response), Traffic.receiveUpdate, Events.getAll	Short: current status. Long: busy times, failure likelihoods	Plan-and-execute
Reservation	Match spaces to price; claim on request, lock in only after payment; handle refunds	Manager.getAvailableAtPrice, Payment.pay/refund, Zone.claim, Email.sendConfirmation	Short: active bookings. Long: reservation log	Plan-and-execute

The driver agent faces open-ended human input, so it reasons step by step. The zone and reservation agents do the same steps every time, and the reservation agent in particular needs ordering, atomicity and rollback, so a fixed plan wins.

Guardrails

• Prevent double booking (claim, then lock in after payment).
• Never reveal location history: the driver agent keeps it and doesn’t forward it.
• Validate the data that drives pricing; external feeds can be wrong or manipulated.
• Redact PII and anonymise orchestrator logs.
• Validate and rate-limit every tool’s arguments.

More on each in Guardrails and Human Oversight for AI Agents.

The lesson

Applying design principles to a multi-agent system comes down to three moves per agent: define its job, give it the right guardrails, and pick its orchestration pattern (how it interacts and loops). Draw the diagram, and say the trade-off of each new box out loud.