Inspiration
Verra began with a frustration that bothered us for a long time. We noticed how much effort disabled people must put in just to leave home. Attending a local workshop or going for a coffee should not feel like a part-time job. Sadly for people with disabilities it often is. We spoke with friends who use mobility aids. We learned that websites rarely list accessibility details. They have to call venues and wait on hold. They ask repetitive questions about ramps or bathroom dimensions. Even then a ramp might exist at the back door but stay locked. The building might have an elevator but the restrooms are too difficult to navigate. This is a very draining burden. We wanted to build something that takes this headache away entirely.
So we kept coming back to the question: could an agent tackle this without taking control away from the person who needs the answer?
That became Verra.
We realized this tedious problem is exactly what AI agents are built to solve. And this hackathon gave us the tools and motivation for achieving our goal.
What it does
Verra is a fully personalized accessibility companion. It operates in real time instead of using outdated databases. We built it for the Everyday Agents track. It works like a background operating system that hunts for answers matching your exact physical needs. It handles venue verification quietly so you never have to lift a finger. This lets you reclaim your time and energy to enjoy what you love.
You simply save your specific needs and pick a venue. You decide which details you want to share. Verra takes over from there. It reads the public website of the venue and matches the findings with your needs. It always saves the exact source of its information. If anything is missing it drafts an inquiry for the venue using only the details you approved. Right now the process ends at creating this draft. Sending emails and syncing calendars are our next steps. You can explore these upcoming features in our demo.
How we built it
We built the web app using Next.js on Vercel. Supabase and Postgres hold personal workspaces and reports. Strict database functions ensure complete data ownership.
Requesting research creates a background job. Amazon EventBridge triggers a Lambda dispatcher every minute. This claims the work and starts the Amazon Bedrock AgentCore Runtime to run our Python Strands agent.
We use GPT-5.6 Luna as our core model. Strands manages all tool calls. Our retrieval tool has strict limits. It blocks private networks and restricts response sizes. It validates source quotations so unsupported findings never become confirmations.
AWS manages our credentials and logs. The background worker checks for cancellations while running and before saving reports. Retries are limited and expired leases recover automatically. The entire process runs safely without needing an open browser tab.
Challenges we ran into
The biggest challenge was that a venue entrance tells you almost nothing about the rest of the visit. Hardest part being trying to keep answers tied to the right questions. A useful fact about a door might be entirely irrelevant to the actual route someone needs. To solve this we kept every requirement strictly separate. Verra refuses to mark a visit settled while something is still unknown.
We also had to handle plans changing while the agent is working. If a user edits a venue or changes permissions the old job must stop immediately. We built revision checks and temporary leases to ensure an old job never saves against outdated details.
Deploying the agent brought its own lessons. We had to perfectly align container formats service permissions and database migrations. We also faced infrastructure hurdles. Our sign-in email is rate-limited on a shared sender. Because of this we built an account-free demo as a reliable way in.
Accomplishments that we're proud of
We are honest about our build status, separating what is live from what is just designed. We deployed a public site a personal workspace and an account-free demo. We are proud to build a reusable access profile so users write their needs exactly once.
Our AWS AgentCore integration features bounded page retrieval. It refuses private addresses and oversized responses. It validates that every finding actually appears in the source. We also built strong data isolation. Real SQL checks ensure accounts read only their own rows.
We ran a real Luna research task that saved source-backed findings directly into the app. AgentCore and the scheduled dispatcher are deployed and running cleanly. Our local checks passed 17 browser journeys and 25 database tests covering account isolation and cancelled plans.
What we learned
We learned that a confirmed answer stating your need cannot be met is still a very useful answer. We also realized the best way to solve this problem is by handling one specific arrangement over time. This works much better than showing a static directory entry. Most importantly, we recognize we have not done user testing with disabled people yet. This is the very first thing we need to fix moving forward.
What's next for Verra
Our next step is to connect the features we already built. We will send drafted messages directly to venues and track their replies. If nobody responds Verra will follow up automatically. We also plan to sync confirmed visits to your calendar and build maps for alternative venue searches.
Future updates will include notifications companion access and better data controls. Our main goal is to reduce the effort of finding answers while keeping you in complete control. Finally we aim to perform real user testing with disabled people.
Built With
- accessibility
- amazon-web-services
- artificial-intelligence
- assistive-technology
- automation
- autonomous-agents
- css
- everyday-agents
- frontend
- generative-ai
- gpt
- html
- javascript
- llm
- node.js
- playwright
- postgresql
- pytest
- python
- sql
- strands-agents-sdk
- supabase
- vercel
- wcag
- web-scraping



Log in or sign up for Devpost to join the conversation.