The project
Build an in-app task assistant with a read-only tool and a separately confirmed task creation action.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What an in-app agent does
Understand the boundaries between agent reasoning and Android capabilities. Apply the module decision to this project. Your checkpoint: You can distinguish local orchestration from local inference.
2. Project setup and a fake-backed screen
Prove the mobile integration before adding real model calls. Apply the module decision to this project. Your checkpoint: Recomposition and configuration change do not duplicate agent execution.
3. Android tools and user confirmation
Expose useful app actions with explicit permission handling. Apply the module decision to this project. Your checkpoint: A stale confirmation cannot authorize a different action.
4. Sessions, recreation and process death
Decide which state survives each lifecycle event. Apply the module decision to this project. Your checkpoint: Every recovery path states whether work resumes, cancels or reconciles.
5. Local and protected cloud models
Use model adapters that respect device support and privacy. Apply the module decision to this project. Your checkpoint: The model route follows the user’s data policy under every fallback.
6. Mobile agent reliability and evaluation
Evaluate agent decisions together with Android lifecycle behavior. Apply the module decision to this project. Your checkpoint: You can demonstrate both correct outcomes and bounded mobile resource use.
Acceptance criteria
- Use the Android artifact rather than the JVM runtime
- Handle screen recreation and cancellation without duplicate execution
- Demonstrate unsupported local-model behavior and protected cloud access
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.