SpotOn

An AI parking agent that coordinates permits, shared spaces, and waitlists to make community parking fairer and less frustrating for residents and property management.

Comment

Inspiration

SpotOn came from a real frustration I kept seeing in the townhome community where I live.

Our neighbourhood has shared visitor parking, but residents need to email security with vehicle details and the expected parking window. In practice, that simple process creates a lot of friction. Residents forget to send the email, visits run longer than expected, temporary parking needs come up, and sometimes legitimate visitors or residents end up with expensive tickets over a small administrative step.

I also noticed an accessibility problem. Some senior residents were not comfortable with the email-based process and needed help just to register a vehicle.

After experiencing the same problem myself and hearing similar frustrations in community group chats and town hall discussions, I kept coming back to one question:

Why should something as simple as having a visitor over require this much coordination?

The issue was bigger than parking. It was about coordination, context, and communication.

Not every useful agent needs to solve a massive problem. Sometimes the most meaningful opportunities are the small, repetitive headaches people have simply learned to live with.

That frustration became the starting point for SpotOn.

What it does

SpotOn is an autonomous community parking agent designed to reduce the repetitive work involved in managing shared parking. SpotOn is not trying to reinvent parking. It is designed to remove the repetitive coordination around it.

Residents can use natural language to:

  • register visitor parking
  • request temporary parking for their own vehicle
  • join a waitlist when all visitor spaces are full
  • release or cancel a space early
  • receive parking confirmations and availability notifications

For administrators and security teams, SpotOn can:

  • look up unknown vehicles
  • compare them against resident vehicles and active permits
  • flag unmatched vehicles for review
  • provide context before a human decides whether further action is needed

The goal is not to replace community rules or human judgement. It is to make the coordination around those rules easier and less frustrating. The parking space itself is not the difficult part. The coordination around it is.

How we built it

SpotOn uses a React frontend, FastAPI backend, Strands agents, DynamoDB for application state, and Amazon SES for notifications.

The React frontend handles the resident and admin experience, while FastAPI acts as the application boundary. Requests that require agent reasoning are passed to Strands, where the agent selects the appropriate tool. The actual parking operations remain deterministic: Python code performs validation, updates DynamoDB, and sends notifications through SES.

I built two agents:

  • a resident agent for parking requests, permits, temporary parking and waitlists
  • an admin agent for reporting and checking unknown vehicles

Each agent has its own prompt and tools so the rules and responsibilities stay separated.

The resident agent has seven tools:

  • identify_resident — finds the resident by unit number and saves them for the session
  • check_parking_availability — counts free and occupied visitor spaces
  • create_permit — books a visitor into the first free space
  • get_resident_vehicles — lists the resident's registered vehicles
  • create_temporary_resident_permit — books the resident's own car when their driveway is unavailable
  • get_permit_status — checks whether a permit is still active
  • join_waitlist — adds a request to the waitlist when the lot is full

The admin agent has one:

  • report_and_check_vehicle — records a reported vehicle and checks its plate against resident and permit records

One of the core design choices was keeping the model away from direct database control.

The agent decides what needs to happen. Deterministic code controls how it happens. That separation became one of the core principles of SpotOn: use the agent for intent, context and orchestration, while keeping state changes and community rules inside controlled application code.

The agent can understand intent and choose the right tool, but the business logic handles the real state changes, validation and notifications.

Challenges we ran into

Building the Strands agents was actually the smoother part. The harder part was turning agent behaviour into a dependable application: preserving state, keeping permissions tight, deploying the runtime, and making sure the system behaved predictably outside my local environment.

The bigger challenges came from turning SpotOn into a real deployed application and getting it running on Amazon Bedrock AgentCore Runtime.

Some of the issues I ran into included:

  • IAM and least-privilege permission problems
  • CloudFormation and CDK deployment failures
  • KMS permission issues
  • stacks getting stuck in UPDATE_ROLLBACK_FAILED
  • packaging environment-specific configuration correctly
  • understanding AgentCore runtime requirements and session behaviour

A lot of these failures happened one at a time, where fixing one permission exposed the next missing dependency. :contentReference

Accomplishments that we're proud of

I am most proud that SpotOn became more than a chatbot demo. I am also proud that the project stayed focused on a small, real problem instead of trying to manufacture a bigger one. The value comes from removing a recurring headache completely, not from pretending parking is a moonshot problem.

It can take a real request, reason about what needs to happen, use tools, update shared parking state, trigger notifications, manage a waitlist, and still know when a decision should remain with a human.

The waitlist flow was especially rewarding to build. If the lot is full, SpotOn can add a resident to the waitlist. When another resident releases a space early, deterministic application logic can match that newly available space to the oldest valid request and notify the waiting resident. That flow is probably the best example of what I wanted SpotOn to become: one resident releases a space, another resident benefits from it, and the coordination happens without someone manually chasing emails or checking who is waiting.

I am also proud that the admin flow keeps a clear human-in-the-loop boundary. SpotOn can explain why a vehicle does not match current records, but it does not call the vehicle illegal, issue a ticket, or make an enforcement decision.

SpotOn can act autonomously where the rules are clear, and step back where judgement matters.

What we learned

The biggest lesson was that building an agent is not just about writing a good prompt.

The harder and more important question is:

What should the agent reason about, and what should deterministic code control?

I learned to use the model for understanding intent, gathering missing information and choosing the next action, while keeping application state, validation, permit creation, waitlist handling and notifications inside controlled Python code.

I also learned a lot about deploying agents on AWS, especially around least-privilege IAM, reading CloudFormation event history, packaging clean runtime environments, and understanding how AgentCore behaves in practice.

I also learned that useful agents do not always need huge problems. A small problem that happens repeatedly can create enough friction to justify automation, especially when the agent can remove coordination rather than simply answer questions.

Built with & disclosures

  • Built during the Submission Period: development began with the first commit on August 26, 2026.
  • Starter scaffolding: the React frontend was bootstrapped with Create React App (react-scripts). The agentcore/ folder, including its AWS CDK project, was generated by the Amazon Bedrock AgentCore CLI and then configured for SpotOn.
  • Frameworks and SDKs: Strands Agents, Amazon Bedrock AgentCore SDK, FastAPI, boto3, React, React Router and AWS CDK.
  • Models and AWS services: Claude Sonnet 4.6 on Amazon Bedrock, Amazon Bedrock AgentCore Runtime, Amazon ECS Express Mode, AWS Amplify Hosting, Amazon DynamoDB and Amazon SES.
  • AI assistance: I developed SpotOn primarily with Claude Code as an AI coding assistant. AI generation tools also helped create the SpotOn logo and parts of the landing page.
  • Demo data: all residents, units, vehicles, licence plates and permits are fictional and were generated for demonstration purposes using Mockaroo.

What's next for SpotOn

There are several areas I would like to continue improving:

  • Real authentication instead of unit-number-based identification
  • Live updates for waitlist offers and parking-state changes
  • More agent skills, such as extending visits and automatically releasing no-show reservations
  • Admin activity and waitlist views
  • Horizontal expansion: adapting the same coordination model to other shared-space communities rather than turning SpotOn into a larger vertical parking platform

SpotOn’s core pattern is reusable: known members, limited shared spaces, visitors, waitlists, notifications and human review.

That same pattern could work in schools, office campuses, hospitals, libraries, community centres and places of worship each with its own rules, community guidelines and workflows.

The goal is not to make SpotOn a massive parking platform. The goal is to take a coordination pattern that works and adapt it wherever that same kind of everyday friction exists.

Closing Notes

SpotOn does not need to solve a massive problem to be useful. If it can remove one recurring headache from the community that inspired it, that is already meaningful.

Share this project:

Updates

Submission history