The project
Build a support triage agent with read-only tools, bounded execution and a reproducible evaluation suite.
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 ADK is and where it runs
Separate an agent framework from the model and its deployment. Apply the module decision to this project. Your checkpoint: You can justify the agent loop rather than adding one by default.
2. Kotlin setup and a minimal agent
Create a small runnable JVM program before adding tools. Apply the module decision to this project. Your checkpoint: You can trace one input through the runner to its final response.
3. Defining and executing tools
Use typed boundaries for application capabilities. Apply the module decision to this project. Your checkpoint: Tool safety is enforced even if the model ignores its instructions.
4. Sessions, memory and context
Control what each run remembers. Apply the module decision to this project. Your checkpoint: You can clear or replace session memory without losing authoritative business data.
5. Orchestration and execution budgets
Compose agents only where the separation helps. Apply the module decision to this project. Your checkpoint: You can show a measurable reason for each additional agent.
6. Evaluation and service integration
Test decisions and failure paths independently of model variability. Apply the module decision to this project. Your checkpoint: Your report separates model decision errors from tool implementation errors.
Acceptance criteria
- Keep sessions isolated by user
- Reject invalid tool arguments and unauthorized records
- Compare agent outcomes against a deterministic routing baseline
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.