Student Wallet

Inspiration

As a student managing my own semester budget, I built an earlier version of this idea which was a simple Android app to track my spending. It worked, but it was just a tracker: it showed me what I'd already spent, and left all the thinking to me. When the Agents for Humans Hackathon came up, I saw a chance to rebuild it properly not just as an app I have to check, but as an agent that actually watches my money and only speaks up when something needs a real decision to be made.

What it does

Student Wallet is an autonomous budgeting agent for students. It handles semester setup, logs income and spending, evaluates every transaction against pacing (adjusted for whether income arrives as a lump sum, monthly, or irregularly), suggests and executes reallocations when a category runs ahead, sends fixed-cost reminders, generates weekly/monthly/end-of-semester digests, and manages semester rollover. It has a protected Emergency category that always requires a reason before it can be used. Students interact with it either through a dashboard with quick-action cards, or through free-form chat with the agent directly.

How we built it

The backend is Python, with SQLAlchemy models covering semesters, categories, subcategories, transactions, income, reallocations, and every decision the agent has ever surfaced. The agent itself is built with the Strands Agents SDK, running on Claude Sonnet 4.5 via Amazon Bedrock, with 13 tools it can call to reason about and act on a student's real financial situation. A FastAPI layer exposes the agent as a simple chat endpoint, plus a couple of direct-database endpoints (/dashboard, /register) for anything that's pure math or lookup — no need to spend a model call on a number the code can compute directly. The frontend is a single-page HTML/CSS/JS dashboard with a floating chat bubble for anything the quick-action cards don't cover, plus a lightweight email-based account system so a student's data persists even if they reinstall.

Challenges we ran into

The Strands SDK's @tool decorator uses Pydantic to build each tool's schema which meant I couldn't pass a live database session as a tool argument, since Pydantic has no way to represent that. Every tool ended up managing its own database session internally instead. I also hit a real design bug during testing when my first version of the reallocation logic tried to record a category-to-category transfer using the income table, which broke a database constraint. I ended up building a dedicated ReallocationTransfer model instead. Also, since it was my first time doing this, it took me some time to learn to do everything by myself

Accomplishments that we're proud of

What we learned

Building an agent is a different mindset from building an app. The hardest design decisions weren't about the UI, they were about deciding what counts as a "real decision" worth interrupting a student for, versus something the agent should just handle silently. Getting that balance right is the whole point of an "everyday agent." plus, I'll definitely work in a team next time in order to get more opinions and build a better product.

What's next for Student Wallet

Full email verification, a native mobile app (the backend's API is already designed to support this), Bedrock AgentCore deployment, and mobile-money/SMS-based transaction parsing so logging spend can become fully automatic.

Built With

• amazon-bedrock
• amazon-web-services
• claude
• css
• fastapi
• github
• html
• javascript
• pydantic
• python
• sqlalchemy
• sqlite
• strands-agents-sdk
• uvicorn