Master scheduling has always been one of the most technically demanding leadership tasks in a school building. A principal staring at a blank scheduling grid must simultaneously hold in mind the number of instructional minutes required by state law, the MTSS tier structure their building has committed to, the cafeteria’s serving windows, the specials rotation, a reading interventionist’s contractual lunch and prep requirements, the needs of students with IEPs, and the simple logistics of x number of children moving through hallways at the right times. A single overlooked constraint such as a part-time music teacher, a cafeteria window that closes at 1:00 can require rebuilding an entire grade level’s day from scratch.
The question we started with was simple: what if an AI model could hold all of those constraints simultaneously so the administrator didn’t have to?
That question led to the development of the AI-Assisted Master Scheduling Workflow with a structured, six-step process designed to guide building administrators through data collection, constraint mapping, draft generation, and equity auditing, with Claude serving as the constraint-holding engine at every stage. The workflow was not designed to replace the administrator’s judgment. It was designed to make that judgment more informed, more efficient, and less vulnerable to the kind of structural errors that only surface after three rounds of revision.
The Pilot: Taking It Into a Real Building
The first real test of the workflow came when I partnered with an elementary school to build a complete master schedule from the ground up for the coming school year. The school served students in Kindergarten through fourth grade across thirteen sections. The building had a reading interventionist, a strategist staff providing special education SDI services, a two-day rotating specials cycle, and the full complement of MTSS obligations of Tier 1 core, Tier 2 small group, and Tier 3 intensive reading intervention for every grade level.
On paper, this was exactly the kind of school the workflow was designed for. Complex enough to be meaningful, bounded enough to be manageable.
What we discovered in practice was something every experienced scheduler already knows: the constraints that matter most are the ones that arrive late.
The constraints that matter most are the ones that arrive late.
The cafeteria window from 11:00 AM to 1:00 PM, last grade eating by 12:40 was not formally entered when we began building. It surfaced mid-draft. Grade 4’s lunch had been placed at 1:40 PM. The entire afternoon had to be rebuilt from scratch. The specials master schedule which revealed that Grade 1 and Grade 2 would share the same 10:40–11:35 block, and that the music teacher was only a half-time educator available only until 12:30 arrived from the after the first specials rotation tab had already been built. That required another full rebuild.
The curriculum name appeared as “incorrectly in early drafts. It had already been placed into thirteen cells across three tabs by the time the error was caught.
None of these were failures of the AI. They were failures of the intake process of information that existed somewhere in the building but was never formally collected before drafting began.
The workflow performed well at what it was designed to do. When all constraints were in the room, Claude held them with genuine fidelity. The reading interventionist’s day was rebuilt multiple times as admin requests evolved with adding Tier 3 sessions for grades that were missing them, resolving simultaneous T2/T3 conflicts, moving lunch, adding cafeteria duty, extending pull windows and each version produced a verified day with no scheduling errors. The Excel workbook that came out of the process included a color-coded master schedule, a specials rotation tab matching the principal’s exact format, and a Friday shortened-day tab, all with verified minute totals.
But the revision cycles were longer than they needed to be. And the reason was almost always the same: a constraint that was known by someone in the building had not been entered into the process before the draft was generated.
The Reflection: What Did We Learn?
After the pilot concluded, I did what any good instructional process should do and I reflected.
The conversation that followed with Claude covered six specific areas where the workflow had friction:
1. The Cafeteria Window Needs to Be a Hard Stop in Step 1
It is the single constraint most likely to require a full grade-level rebuild if it arrives late. The word “wall” needs to be in the question. Administrators need to feel the structural weight of it before they begin.
2. Curriculum Names Need Their Own Dedicated Field
It sounds trivial. It is not trivial. A curriculum name that appears incorrectly across dozens of cells in a professional deliverable erodes trust in the document. The exact spelling, capitalization, and word order need to be locked in before the first draft is generated and not corrected in round four.
3. Building-Wide Structural Anchors Need to Be Collected Explicitly
The start time of morning routine. The time pack-up begins. Whether there is a building-wide SEL or Community Circle block and exactly when it falls. These are not context, they are constraints. They need to be in Step 1 alongside bell times.
4. The Specials Master Schedule Cannot Be Assumed
Part-time staff, shared blocks between grade levels, unavailable afternoon windows are structural facts that reshape entire sections of the schedule. The question in Step 3 now carries an explicit warning: a partial or assumed specials schedule is the single most common cause of full rebuilds.
5. Tier 2 and Tier 3 Conflict Detection Needs to Be Automatic
The conflicts that were caught in this pilot of a Tier 3 pull window falling during Tier 1 instruction, a Tier 2 and Tier 3 window assigned to the same students at the same time should never reach the administrator’s desk. The workflow now runs an automatic conflict scan after every draft before presenting it for review.
6. The Backfill Pathway Needs a Formal Structure
This pilot began with a schedule already partially in place, which meant we entered the workflow sideways and not from Step 1, but from somewhere in the middle. This will happen with other districts. Administrators often have something already built when they first encounter this tool. The workflow now includes a dedicated Backfill Entry Protocol: five specific questions that surface every structural constraint before any revision work begins, preventing the discovery-through-revision pattern that extended this pilot’s timeline.
How Claude Made the Changes & Not Just Suggested Them
This is the part of the process worth pausing on, because it illustrates something important about what AI assistance can actually look like in practice.
After the reflection was complete and after I had talked through what needed to change and why with Claude, the next step in a traditional workflow would have been to open the project instructions document, reread the existing text, identify where each change needed to be inserted, retype or carefully paste the new language, and verify nothing had been accidentally deleted or misaligned. For a document of this length and structure, that process takes time and carries its own risk of error.
The distinction between an AI that tells you what to change and an AI that goes in and changes it is the difference between a consultant who writes a memo and a colleague who sits down next to you and does the work.
Instead, Claude navigated directly to the Claude.ai project and opened the Master School Scheduling project, found the Instructions panel, clicked the edit button, selected all existing content, and replaced it with a fully revised version of the workflow incorporating every change from the reflection. The update was verified on screen. The new instructions were saved and live.
This is not a small thing. When you are a practitioner building a tool that will be used with other districts across a region, the ability to move directly from reflection to implementation without a manual retyping step in between compresses the improvement cycle in a way that matters.
The revised workflow that is now in the project reflects what was learned in the pilot. Every administrator who uses this tool with a new district next year will benefit from the friction that surfaced in this one. The cafeteria window will be asked about on day one. The specials master schedule will be required before the first draft. The curriculum names will be locked in before a single cell is populated. The conflict scan will run automatically. The backfill pathway will have a real on-ramp.
What This Tells Us About AI as a Thought Partner
There is a version of AI-assisted work that treats the technology as a search engine with better grammar where you ask it a question, it gives you an answer, you go do something with the answer yourself. That version is useful. It is not what this project was.
What this project demonstrated is something closer to a genuine thinking partnership. Claude held the constraints when there were too many to hold in a human head. Claude ran the math when the numbers changed. Claude flagged the conflicts before they became rebuilds. Claude produced the deliverables in the format the team actually needed. And when the reflection was done, Claude implemented the improvements directly into the system that will be used next time.
The administrator’s judgment was present at every decision point. Every structural choice such as where to place a Tier 3 window, how to handle a cafeteria conflict, whether to split a curriculum block was made by a person who understood the building, the students, and the stakes. The AI did not make those decisions. It made them possible to make well, by ensuring that every constraint was visible when it needed to be.
The Core Insight
That is what we mean when we say this tool serves as a second brain. Not a replacement for expertise, but an extension of it and one that remembers everything, holds everything, and when the session is over, can update itself for the next one.
Technical Details of Version 1.0 → Version 2.0
What Was in the Original Workflow and What Changed After the Pilot?
A transparent look at the real differences between the tool I built and the tool I improved with Claude
This section exists because I believe in showing the work. AI-assisted tools are only as good as the thinking behind their design and that thinking improves through use, failure, and honest reflection. What follows is an exact account of what Version 1.0 contained, where it fell short in the field, and what was added or changed to produce Version 2.0.
If you are curious about what the project instructions actually look like, or how a structured AI workflow gets built and refined, this is where to start.
How to Read This Section
The comparison tables below show the Version 1.0 state (what was missing or incomplete) alongside the Version 2.0 update (what was added). Following the comparison is a dedicated table of net-new features that did not exist in any form in Version 1.0. Every change shown here traces directly to something that caused friction, delay, or rework during the pilot.
Side-by-Side: What Changed
Net-New Features: Additions That Did Not Exist in Version 1.0
The following capabilities were not present in any form in Version 1.0. They were built entirely in response to what the pilot surfaced.
What Stayed the Same
Not everything changed. The core architecture of the workflow of six steps, Claude as constraint-holder, the administrator as decision-maker is identical in both versions. The following elements were not modified because they worked as intended during the pilot:
The Six-Step Structure
Steps 1 through 6 remain in the same sequence. The logic of the workflow did not change and only the depth and specificity of each step’s intake questions.
The Deficit Detection Rule
If total required minutes exceed available instructional time, Claude stops immediately and presents three resolution options. This rule was in Version 1.0 and remains unchanged.
The Two-Version Draft Requirement
Step 4 always generates Version A (literacy-first) and Version B (dedicated intervention block) for administrator comparison. This principle remains unchanged.
The Equity Audit
Step 5 requires naming the specific student subgroup absorbing every scheduling compromise. This principle was foundational to Version 1.0 and has not changed.
The Final Deliverable Package
Step 6 produces the same ten documents in both versions: Foundation Summary, Minutes Inventory, Constraint Map, Grade-Level Schedules, Integrity Checklist, Flexibility Notes, Equity Audit, Board Summary, Teacher FAQ, and the Excel master schedule workbook.
Questions This Section Is Designed to Spark
If you’re a building administrator, district leader, or a consultant reading this and finding yourself wondering any of the following, then those questions are exactly why this section exists.
• What exactly does the six-step workflow prompt look like? What do you paste into Claude?
• How does the Pre-Build Checklist actually work in the conversation and how does Claude refuse to move forward?
• What does the Excel master schedule deliverable look like, and how detailed does it get?
• Can I use this with a school that already has a draft schedule but wants help stress-testing it?
• How long does a full session take from Step 1 to a complete deliverable package?
• What happens when Claude finds a conflict in the draft and does it fix it automatically or ask you?
Want to See It In Action?
The complete Version 2.0 workflow prompt and project instructions are available through Mississippi Bend AEA. Contact the team to learn about upcoming workshop sessions, district pilots, and how to bring this process to your building or region.
