Inspiration
On one of our modules, the handbook says how the report is marked. Then, in the last lecture, the lecturer spent ten minutes saying what he actually wants to see, and none of it is written down anywhere. One of us copied it out word for word, because that is what gets the marks.
That gap is everywhere at university. What you are marked against and what your marker wants are not the same thing, and most students only find out after the mark comes back. We wanted a way to rehearse in front of the people who will mark you, before it counts.
What it does
Panel lets a student build a board of AI assessors modelled on their own markers.
- Assessors with notes. Copy a preset, rename it after a lecturer, and add what they have said they want. Those notes change what that assessor looks for.
- Panels. Each piece of work is a panel. It holds the brief, the mark scheme, your own weak spots, and the board that sits on it.
- Report review. Upload a report. Each assessor reads it independently and comments on specific paragraphs, then the board deliberates and says where it agrees and disagrees.
- Presentation practice. Present out loud. The board listens, steps out to confer, then comes back as a video call and questions you one at a time, with follow-ups that depend on your answer.
- A feedback report after every session. It gives a verdict, a rating against each marking criterion, ranked actions with the evidence behind each, and anything you should take to a human supervisor.
- Memory. The board remembers every attempt, so the next report says what improved and what was raised again.
How we built it
- Next.js, React, TypeScript and Tailwind, with every Claude reply validated by Zod.
- Claude (Haiku 5.5) runs each assessor as its own call, with a prompt built from the panel's context, who the assessor is, the student's notes on them, and what they said in earlier sessions.
- Mode switching. After each spoken answer, a small router call labels the answer and the student's intent. Our code, not the model, then picks one of six modes, which are pressing, probing, coaching, steering, holding the line and paused. A struggling student is coached, and a request for the answer is declined.
- One guardrail pipeline checks every reply. It will not rewrite the student's work, predict a mark, comment on tone of voice, or cite a paper it was not given. Every check that fires is shown in the report.
- Voice and video. Chrome's speech recognition hears the pitch. The questioning judge is a Synthesia interactive avatar streamed over LiveKit. Claude writes every question and the avatar only speaks it. The other judges play Synthesia listening clips.
- Design. A full design system in Figma, with the same tokens in code, and a set of 100 pen-drawn assessor avatars.
- Built with Claude Code and Codex, with Playwright for visual checks.
Challenges we ran into
- Three people's coding agents in one repo. We split the work into lanes with owned folders and a staging branch, and still had to untangle a second, competing engine that one agent had built.
- Speed. The board's deliberation first took 63 seconds. We cut it to about 20 by splitting it into parallel calls.
- The live avatar. It takes about 30 seconds to join a call, so we connect it early and fall back to an ordinary voice if it is not ready. Synthesia's live service also sets its own background, which we could not change.
- Keeping it honest. With no API key the app runs on sample replies, and we made every screen say so instead of passing them off as real.
Accomplishments that we're proud of
- A judge that asks Claude's question aloud, live, as a video avatar, and changes how it talks when you struggle.
- A board that refuses to do your work for you, and tells you when to go to a real person.
- Assessors that genuinely change behaviour from one typed lecture note.
- A product that looks like one thing, because the design system came first.
- 107 automated tests, and full runs verified on real Claude replies.
What we learned
- Most of this should not be an agent. Fixed steps that our code controls were faster, cheaper and far easier to trust than letting models decide what happens next.
- Guardrails are only convincing if you can see them, so we put them in the report.
- Agents build fast, but nothing is verified until a person has looked at it and heard it.
What's next for Panel
- A distinct voice for every assessor, and plain backgrounds on the live avatars.
- Turning lecture recordings into assessor notes automatically.
- Students on the same module sharing notes on the same lecturer.
- A literature assessor that checks your work against real papers, citing only what it finds.
- Accounts, and a phone layout.
Built With
- claude
- codex
