--- title: "Conference Paper Review Assignment With AI Agents | Kylon" description: "How a program committee assigns reviewers by topic, conflict and load cap, checks the draft roster and handles declines and withdrawals, with the chairs deciding." url: "https://kylon.io/use-cases/paper-review-assignment" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Paper Review Assignment: Two Qualified Reviewers on Every Submission, Within Load Use Case7 min read # Paper Review Assignment: Two Qualified Reviewers on Every Submission, Within Load A program committee desk assigns two reviewers per submission under topic, conflict and load rules, books the track discussions and keeps the slate correct through declines, withdrawals and late conflicts. Agents propose and the program chairs approve. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Two reviewers per paper, three hard rules and a slate that keeps moving A program committee gives each submission two reviewers. The policy has three hard rules: the reviewer's topics must match the paper, the reviewer must not be a co-author or otherwise conflicted, and nobody goes over a personal load cap. Within those rules the best topic match wins, and ties break in a fixed order. Doing that for a few dozen papers is careful work. Keeping it right through declines, withdrawals and late conflicts is where it slips. Submissions sit in an Airtable base, the reviewer roster with topics, status, caps and current load is a Notion database, the policy and topic-match table are in Google Drive, and reviewers write in by email. When two reviewers decline their whole slate on the same afternoon, their papers have to move in a defined order while every reviewer's load stays true in Notion. ## Who works in the room People - Program chairs Own the assignment policy, approve every assignment and change, and sign the close-out - Track chairs Confirm topic fit in their track and run the track's discussion session - Committee administrator Records declines, withdrawals and declared conflicts as they come in Agents - MycoAssignment coordinator Assigns two reviewers per submission by topic match, conflicts and load cap, keeps every reviewer's load current and books the track sessions Airtable[Notion](https://kylon.io/integrations/notion)Google Calendar - NovaRoster checker Checks the draft roster line by line against the approved assignments and lists every correction, including papers left off Google DriveAirtable - RyanReviewer correspondence Reads declines and conflict notes and drafts one reply per reviewer thread naming the papers that moved [Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) The review cycle lives in a single Kylon room. Myco is the default agent, so any question about who reviews what lands with it. The draft roster goes to Nova, whose specialty is checking it, and messages from reviewers go to Ryan, which works the committee mailbox as the chair it is drafting for, checked on every call. When a decline arrives, Ryan opens a thread for Myco whose first message names the reviewer and the affected paper ids, and Myco leads it until the reassignment is approved. ## The review cycle, change by change Every reassignment runs under the full policy, and the program chairs approve the result before Airtable, Notion or the calendar changes. ```mermaid flowchart TD subs([Active submissions wait in Airtable]) assign["Myco assigns two reviewers per paper
by topic, conflicts and load cap"] ok1["Program chairs approve
before anything is written"] roster["Nova checks the draft roster, papers
missing from it included"] change([The committee administrator records
a decline, withdrawal or conflict]) reassign["Myco reassigns their papers
in ascending paper id order"] clear["Myco clears both slots
with no replacement"] replace["Myco replaces the reviewer
on that paper"] ok2["Track chair confirms any conflict,
program chairs approve"] reply["Ryan drafts one reply per decline
thread for a chair to send"] caps["Program chairs set
the corrected caps"] move["Myco moves only the papers
above a lowered cap"] close["Myco tallies each reviewer's papers,
topic match and load"] file["Program chairs file
the close-out records"] subs --> assign --> ok1 --> roster --> change change -->|decline| reassign change -->|withdrawal| clear change -->|late conflict| replace reassign & clear & replace --> ok2 --> reply reply & caps --> move move --> close --> file class assign,roster,reassign,clear,replace,reply,move,close agent class ok1,ok2,caps,file person class subs,change event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Initial assignment | Two reviewers per active submission, loads updated and five track discussion sessions booked | Myco, from Airtable and the Notion roster | The program chairs approve before anything is written | | Draft roster review | The coordinator's draft is checked against the approved slate, including papers missing from it | Nova | The chairs decide which corrections go back to the draft | | Reviewer declines | Both reviewers are marked on leave and their papers reassigned in ascending paper id order | Myco, then Ryan for the replies | The chairs approve and a person sends each reply | | Withdrawal | The paper is marked withdrawn, both reviewer slots cleared and both loads reduced, with no replacement | Myco | The chairs confirm the withdrawal | | Late conflict | The conflicted reviewer is replaced on that paper, and their other papers are re-checked against the full rules | Myco | The track chair confirms the conflict and the chairs approve | | Load cap correction | Caps are updated, and only papers above a lowered cap move | Myco | The chairs set the corrected caps | | Close-out | Each reviewer's paper count, topic-match total and load are tallied from current records | Myco | The program chairs file the close-out records | Stages of one review assignment cycle. Paper ids, tracks and caps in this example are illustrative. ## When the slate changes after it is published Declines come as short emails: a reviewer has a new job or a family matter and cannot take any papers this cycle. Myco marks the reviewer on leave and walks the affected papers from the lowest id up, giving each the best-matching reviewer with load to spare and no conflict. Because the walk goes in order, two papers competing for the same strong reviewer always resolve the same way, and Ryan drafts one reply on each decline thread naming the papers that moved. Not every change moves papers. A withdrawn submission frees two slots and reduces two loads, but nobody is assigned in its place. A raised cap changes nothing until a later change needs the room. A lowered cap moves only the papers above the new limit. Myco says in the thread which of these it is doing and why, so the chairs approve a scope as well as a list. ## What the checks catch - A co-author or same-lab reviewer slipping onto a paper during a reassignment - A reviewer whose Notion load still counts a withdrawn paper - An out-of-scope submission touched during a re-run, though the policy leaves it alone - A raised cap read as a reason to reshuffle papers that were already correctly placed - A paper missing from the draft roster altogether, not only lines that are wrong ## What stays with people - Approving every assignment and reassignment before Airtable or Notion changes - Judging a declared conflict the policy does not spell out - Sending each reply to a reviewer, which Ryan drafts - Setting load caps and signing the close-out ## Integrations in this workflow Kylon is not a conference submission system and does not replace the one the committee runs. It sits between the records and mailboxes the desk already has, so the handoffs happen in one place instead of across inboxes. - Airtable - [Gmail](https://kylon.io/integrations/gmail) - Google Calendar - Google Drive - [Notion](https://kylon.io/integrations/notion) - [Slack](https://kylon.io/integrations/slack) - **Airtable** holds the submissions with both reviewer fields, status and the close-out records - **Notion** keeps the reviewer roster with topics, status, load caps and current load - **Google Calendar** carries the five track discussion sessions, booked after the chairs approve - **Google Drive** stores the assignment policy, the topic-match table and the draft roster - **Gmail** is the committee mailbox for declines and conflicts, and a reply leaves only when a chair sends Ryan's draft - **Slack** is where track chairs flag conflicts and topic questions between emails ## Where to start Run one track through a full cycle first. Connect the Airtable base and the Notion roster, and give the room guidelines one rule: every change runs under the full policy in ascending paper id order, and the program chairs approve it before a reviewer's load or a paper's slate changes. > “Two reviewers per paper is the easy part. Keeping every load true after the fifth change is the work.” ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our paper review assignment desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, Gmail, Google Calendar, Google Drive, Notion and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the program chairs who approve every assignment and change, the track chairs who confirm topic fit and run track discussions, and the committee administrator who records declines, withdrawals and conflicts. Help me invite them to this Room. 3. Build a Review Slate App with Paper, Reviewers, Track and Status columns, one record per submission. Fill it from the active submissions in Airtable. 4. Check each draft assignment against the topic-match table in Google Drive, the reviewer roster in Notion and conflict notes in Gmail and Slack. Flag any paper without enough qualified reviewers, any load over the threshold we set and any conflict, and show me every problem line. 5. Draft one reply per reviewer decline thread naming the papers that moved. Hold every reply and every write to Airtable, Notion or Google Calendar until a program chair approves the reassignment and a person sends the draft. 6. Write our rules, the paper order we use for reassignments and who approves what into this Room's guideline, so every change follows our policy. 7. After each full track cycle, offer to turn the reassignment walk into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Course Section Scheduling: A Fall Timetable That Holds Through Leave and Closures Sections are matched to rooms and instructors under the scheduling policy, booked on the calendar and re-walked in one fixed order when leave, enrollment, building or equipment changes arrive. Agents propose each assignment and the scheduling lead approves it. Education & researchScheduling & dispatch ](https://kylon.io/use-cases/course-section-scheduling)[ ### Program Admissions: Waitlist Offers Made in Order, Cohort by Cohort Applications are cleared of withdrawals and duplicates, scored from transcripts and test reports and seated by cohort in one Kylon room. When offers lapse, seats grow or students defer, the waitlist moves in order and the admissions director approves each offer. Education & researchApprovals & reviews ](https://kylon.io/use-cases/admissions-waitlist)