Tiza: Practice between classes

• 

• 

  Architecture Diagram

One class. Different starting points.

Class ends. The work of making practice personal begins.

Built with Strands Agents on Amazon Bedrock. Designed around teacher judgment.

A tutor has just taught fractions. One learner needs to revisit what a denominator means. Another is ready to add unlike fractions. A third has no recorded answers yet: they need a check, not an assumption.

Tiza connects those different starting points to one shared lesson goal. It prepares practice for the teacher to review, records what learners actually do, and brings that evidence into the next lesson.

Inspiration

We started with the work that happens between classes: choosing exercises, adapting practice, checking answers and deciding what to revisit. Small classes can have very different needs, while the teacher still has the same number of hours in the day.

Our question was: what could an agent take off the teacher's desk while leaving the teaching decisions with the teacher?

That became Tiza's central rule: preparation can be delegated; publication requires human approval.

What it does

1. Set the goal. Review the practice.

The teacher chooses an objective, confirms the concepts and sets a practice budget. Tiza prepares individual drafts from a reviewed exercise bank. The teacher can inspect the questions, change a selection or exclude a learner before approving the current version.

Nothing reaches the class until the teacher approves it. Editing a plan requires a new approval.

2. Give learners a focused next step.

Learners answer one question at a time, ask for a hint when needed, and receive a saved-answer confirmation. Follow-up practice stays within the batch the teacher approved. Objective answers are checked on the server; short explanations can wait for teacher review.

3. Start the next lesson with evidence.

The next-lesson brief separates participation, answers awaiting review and learners who have not started. Each observation links to supporting attempts: the actual answer, hint usage and review history.

An unanswered question stays unanswered. It is not silently turned into a wrong answer.

The visuals use eight fictional learners. The recorded walkthrough shows locally prepared practice; the deployed Bedrock workflow was verified separately.

How we built it: Strands Agents at the center

Strands Agents turns Tiza's preparation step into a tool-driven workflow that ends with a concrete handoff to the teacher. We use the Strands Agent and BedrockModel with Amazon Nova 2 Lite on Amazon Bedrock, connecting model decisions to four narrowly scoped Python tools:

1. Read the lesson — read_cycle_context supplies the authorized lesson objective, concepts, practice budget and limited material excerpts.
2. Inspect reviewed candidates — select_validated_exercises exposes the exercise options selected by Tiza's deterministic policy, within each learner's practice constraints.
3. Save each learner's draft — save_assignment_draft lets the agent choose among those validated candidates and explain the selection. The backend checks the scope, ordered items and allowed exercise IDs before saving.
4. Hand control to the teacher — request_teacher_review succeeds only after every learner's draft has been saved. The teacher then reviews, approves and publishes through the application.

Strands coordinates the preparation. The teacher authorizes what reaches learners. Approval and publication are deliberately absent from the agent's tools. A Strands hook caps each run at 12 model calls, and sequential tool execution keeps the draft-to-review flow ordered. We record tool events, model usage and completion status so the product can show what actually ran.

We verified this integration on the deployed AWS application: a real Strands + Bedrock run persisted eight learner drafts, followed by teacher approval, publication, a learner answer and the next-lesson brief. This verification is separate from the locally prepared walkthrough shown above.

The application around the agent

The interface uses React and TypeScript, with FastAPI, SQLAlchemy and PostgreSQL behind it. Durable jobs and an outbox connect the API to Celery and Redis for background preparation.

The deployed demo runs on Amazon EC2, behind Caddy HTTPS. It uses the instance role for AWS access, Systems Manager Parameter Store for deployment configuration, and private Amazon S3 backups. We restored a backup into isolated PostgreSQL and checked the recovered record counts.

For this hackathon deployment, access uses a demo code and email is captured in Mailpit. Supabase and Resend adapters exist in the codebase, but they are not the authentication and email services used by this demo.

Challenges we ran into

Making approval mean something. Approval is tied to the exact plan version and recipients. A later edit cannot quietly reuse an earlier approval or rewrite a completed attempt.

Personalizing without inventing evidence. Missing answers should trigger an initial check, not a confident label about a learner. We keep observed attempts separate from suggestions about what to teach next.

Connecting a local demo to a real deployment. A health endpoint was not enough. We verified a persisted Bedrock preparation run, eight drafts, approval and publication, a hinted learner answer and the resulting brief through the deployed API.

Accomplishments that we're proud of

• A complete teacher → learner → teacher workflow, with the human approval step built into the product.
• A real deployed Strands/Bedrock run, separate from the deterministic local walkthrough.
• Traceable answers and teacher revisions, including an idempotent answer replay that did not create a duplicate attempt.
• Desktop and mobile UI checks, backend and browser workflow tests, and a tested database backup restore.

What we learned

The most useful boundary for an agent is a clear handoff. In Tiza, that handoff is a reviewable practice plan: the teacher can see what was prepared and decide whether to send it.

We also learned to distinguish a proposal from an observation, an accepted email from completed practice, and a working local demo from a verified model invocation. Those distinctions shaped both the interface and the backend.

What's next

Our next step is a teacher pilot to measure preparation time and the usefulness of the next-lesson brief. We have not yet measured time savings or learning gains.

From there: more reviewed subjects, multilingual practice and LMS integrations, guided by what teachers actually need between lessons.

A note to the judges: why Tiza belongs in Agents for Humans

Behind every lesson is another layer of work: deciding what each learner should practice, reviewing it and understanding what their answers mean. Tiza brings that work into one connected cycle, with the teacher's judgment at its center.

Strands Agents makes this delegation concrete. On Amazon Bedrock, our agent reads scoped lesson context, chooses among validated exercise candidates, saves individual drafts and requests teacher review. Each tool has a defined responsibility. The handoff is built into the workflow: the agent prepares; the teacher approves what reaches learners.

We invite you to judge Tiza across that complete cycle: from a lesson goal to eight reviewable drafts, from an approved assignment to a saved learner answer, and from that answer to evidence for the next class. We have verified this path in our AWS deployment, including a real Strands and Bedrock preparation run.

That is our case for Tiza: useful agency, explicit human authority and a working product that connects the two. Our ambition is to make individual practice practical for more teachers. The next step is to test that promise with them.

You teach. Tiza handles the practice.

Try Tiza · Source code · How we built Tiza · Our AWS deployment journey

Built With

• amazon-bedrock
• amazon-web-services
• caddy
• celery
• docker
• fastapi
• postgresql
• python
• react
• redis
• sqlalchemy
• strands-agents-sdk
• supabase
• tanstack-query
• typescript
• vite