A concrete domain model with real workflow logic, not a prompt-only demo.
Case study
Student Assignment Tracker
An education tracker built with FastAPI, SQLite, and HTMX through an agent-assisted development workflow. It turned a real school-planning problem into a small product with clear entities, mobile-first flows, and a planned agent access layer.
Case study at a glance
The work is useful because it combines product thinking, technical modeling, and AI workflow design without overstating what shipped.
This page stays text-only and keeps deployment details general.
The planned API layer separates human UI tasks from programmatic agent access.
A real workflow needed a real app
The product goal was straightforward: manage classes, schedules, assignments, semesters, and grades in a phone-friendly education tracker. That required more than a list of tasks. It needed a data model, predictable status behavior, and screens that matched how school work is actually reviewed.
The architecture question was just as important. If an agent will eventually help operate an app, it should not depend on brittle screen scraping or direct database edits. It needs structured access with validation, errors, and review boundaries.
What shipped in the product layer
The application used FastAPI for server behavior, SQLite for persistence, and HTMX with vanilla JavaScript for lightweight interaction. The stack kept the app understandable and easy to iterate.
Assignment tracking
Assignments connect to classes and due dates, with status and final marks treated as part of the workflow rather than loose notes.
Semester and class modeling
Classes belong to semesters and carry practical school context such as teacher, room, credits, and schedule relationships.
Validation and active state
Rules such as active-semester detection and blocked overlapping semester dates keep app behavior aligned with the domain model.
How the agent-assisted workflow helped
The useful AI pattern was not asking for isolated code snippets. It was using an agent-assisted workflow to move from product need to data model, routes, UI behavior, tests, review, and follow-up architecture decisions.
That process also made the limits clearer. AI can accelerate implementation and review, but the app still needs explicit interfaces, predictable responses, safe write paths, and human judgment for architectural claims.
Human UI and agent access need different interfaces
The next architectural step was a designed and planned agent-facing API layer. It was not implemented. The design separated human screens from programmatic operations so that future agents would have a safer path to read context, propose changes, and receive structured errors.
What this project demonstrates
The Student Assignment Tracker shows practical AI-assisted software work: translating a real workflow into a web application, using a concrete stack, modeling domain entities, and identifying where agent access changes the architecture.
The bigger lesson is that agent-enabled applications need to be designed as systems. Useful AI integration depends on structured interfaces, clear data boundaries, predictable errors, and human review, not just better prompts.