A course planner whose tools refuse, say what a choice closes off two years before it bites, and hold a limit you set against the agent — including when you are the one asking.
Aggregate35
Leverage9
Execution8
Impact9
Creativity9
Each criterion 1–10, equally weighted; aggregate is their sum. Ranking is the pipeline's consolidated output.
Origin, access model, eligibility, and substitution are reviewer diagnostics, not judging criteria. Authentication requirements are not penalized.
02 The two blind reviews
Two independent reviewers scored this project blind, from a sanitized evidence packet.
Scores are shown separately so the reasoning stays inspectable. A withheld score means the reviewers differed by more than two points.
Reviewer A (round 1)
confidence 80%
Leverage
8 /10
The tool layer makes constraints, refusals, alternatives, and reversible planning explicit and reliable; a general UI agent would be less dependable at preserving a student's durable rule across actions.
Evidence cited
About text describes thirteen tools, refusal based on a student instruction, alternatives, event logs, and undo by event reduction.
Tools expose consequence-aware planning two years ahead rather than simple course lookup.
Execution
8 /10
The packet provides a coherent small product with specific course data, visible refusal semantics, audit/undo, and three frame sheets plus extensive gallery evidence, though no video/transcript.
Evidence cited
Live demo and public repository are reported.
About text describes a concrete Term 3 planning and refusal workflow.
Fourteen hand-entered courses, thirteen tools, and fifteen gallery images are cited; three frame sheets submitted.
Impact
8 /10
Students face real high-cost planning choices and benefit from explicit prerequisite/track consequences plus a constraint they control.
Evidence cited
Product directly addresses course selection and specialization closure.
Student-defined protection applies even when the student later asks the agent to violate it.
Creativity
8 /10
Treating a student's own preference as a durable policy that the agent must enforce, explain, and audit is a distinctive interaction model.
Evidence cited
Refusal names both ways out and returns prose for the agent to report.
Undo and audit emerge from the event model rather than being superficial UI actions.
Reviewer B (round 2)
confidence 86%
Leverage
8 /10
Typed tools and shared state make constraint-aware planning, refusal, event-based undo, and audit substantially more reliable than an agent guessing through a UI.
Evidence cited
About text describes 13 tools on document.modelContext and shared client-side state.
Frames visibly show a Courses workspace and the Devpost preview shows add_course followed by a prominent Refused result tied to the student's constraint.
Execution
8 /10
The packet presents a coherent, intentionally scoped planner with a central workflow and visible refusal behavior; frame evidence is somewhat small but consistent.
Evidence cited
Contact sheets show the Courses interface with course records and code/tool-oriented state.
Devpost screenshot includes an embedded demo preview with a concrete refused add_course call.
Impact
8 /10
Students making multi-year course choices have a concrete high-stakes planning problem, and the product directly addresses tradeoffs and self-defined limits.
Evidence cited
Pitch and about text identify students, credits, specialization lock-in, and policy-bound planning.
Visible refusal explains what a choice closes off.
Creativity
8 /10
The distinctive idea is a planner whose tools actively refuse choices that violate a student's future-facing boundary, including when the student asks for the forbidden action.
Evidence cited
Student-owned rule is explicitly distinguished from university rules.
The refusal-and-undo interaction is a memorable interaction model rather than ordinary scheduling.
03 Review highlights
Standouts across reviewers
Student-authored constraint is enforced even against the student, a memorable safety pattern.
Refusal and undo are modeled as first-class outcomes.
Student-owned constraints are enforced even against the requesting student.
Refusal returns actionable prose and alternatives.
Red flags
Course catalog is hand-entered and small.
No video/transcript; second call-count metric is explicitly unverifiable because WebMCP lacks caller identity.
No submitted video metadata despite embedded demo evidence; frame text is often low resolution.
04 Evidence
What each artifact proves is labeled on the artifact itself. A Devpost page capture is packaging evidence, not proof the product runs;
video frames are evidence from the submitted demo, not live verification.
Contact sheets from the ?s video the team submitted. This is what reviewers were shown;
it demonstrates the product in motion but is not independent verification.
· watch the original
EX-V1 Sheet 1 of 3 · reported video evidenceEX-V2 Sheet 2 of 3 · reported video evidenceEX-V3 Sheet 3 of 3 · reported video evidence
