The policy isn't written yet. That's a design constraint, not a reason to wait.
Region 7's AI guidance is still being worked out, along with what the Texas Education Code will require of any AI tool we use. Nobody in this room can control what that guidance says. Everybody in this room can build something that survives it.
Every version of that policy, whatever it ends up saying, will require the same thing: a human decision, documented, with a name on it. A workflow where the human step is "I read it before I sent it" will get shut down the day the guidance lands. A workflow with a named checkpoint and a named owner will survive any policy anyone writes.
You're in 103 because you already build things. The question today isn't whether you can chain AI steps together. It's whether what you build is still standing in October.
So for 45 minutes we're not going to talk about prompts. We're going to talk about where the human looks, why it matters where, and how you'd know if your workflow actually works without you in the room.
ChatGPT, Claude, Gemini, Copilot. If your workflow only survives in the tool you built it in, it's a prompt, not a workflow. The tool mix at your table is a feature.
Same rule as every other session today. In 103 it's not a rule at the end, it's a design step in the middle. You'll see where.
You leave with a blueprint that lives somewhere you'll reopen, that one other person has already run. That link is your exit ticket.
One task, torn down twice.
A campus support visit. Real notes, the messy kind. First the way most of us do it, then the same task with one thing moved.
Round oneThe one-prompt version
Here are my notes from my visit to the campus this morning. Analyze them and write my follow-up email to the principal. [notes pasted below] - walked 6 classrooms w/ AP, 2nd period - 4 of 6 had objective posted, 2 not aligned to what was actually taught - lots of teacher talk, little student talk. rm 114 was the exception, good turn-and-talk routine - exit tickets: only saw them in 2 rooms - principal mentioned PLC time is getting eaten by testing logistics again - last visit's action step was "common exit ticket in all 8th ELA" — didn't see evidence - hallway transitions were tight, better than Sept - AP asked about the walkthrough form, thinks it's too long - new teacher in 118 looked overwhelmed, principal knows
Good morning,
Thank you for hosting the walkthrough this morning. Below is a summary of observations and recommended next steps.
Key observations
- Instructional delivery: Across most classrooms, instruction was teacher-directed with limited structured student discourse. Room 114 demonstrated an effective turn-and-talk routine that could serve as a model.
- Lesson objectives: Objectives were posted in four of six classrooms; in two, the posted objective did not align with the instruction observed.
- Formative assessment: Exit tickets were observed in two classrooms.
Recommended action step
Focus the next four weeks on increasing structured student discourse. Consider having Room 114 open its classroom for peer observation, and add a discourse look-for to the walkthrough form.
I'll follow up on PLC scheduling and the new-teacher support plan in our next conversation.
Where was the human checkpoint in what I just did?
At the end. I read the email before I sent it. That's the checkpoint most of us have, and it feels responsible.
But by the time I'm reading the email, three decisions have already been made upstream: which observation mattered, what the action step should be, and how to say it to this principal. I'm reviewing the wording of a decision I never made.
What's the most expensive error that email could contain?
Not a typo. Not tone. It's that the AI picked the priority. It went with student discourse because I wrote more words about it. But last visit's action step was common exit tickets in 8th ELA, and I saw no evidence of it. That's the thread a coach would pull.
If I send this, the principal now has a written follow-up committing us to the wrong priority, and we're anchored to it for six weeks. Catching that at the email stage means rebuilding everything downstream. Catching it one step earlier, when it's still a list of candidates, costs thirty seconds and one crossed-out line.
Round twoSame task, checkpoint moved
Round two isn't better prompting. Same notes, same AI, same email at the end. It's the same AI doing less deciding, and one human doing the deciding where it's cheap.
Two ideas, and that's the whole teach.
Everything you build in the next fifteen minutes gets tested against these two.
Checkpoint economics
The checkpoint doesn't go where the output is most visible. It goes where the error is cheapest to catch.
Ask, of your own task: what's the error that actually matters? Not the typo. The one that sends the wrong thing to the wrong person, or commits you to a direction for a month. Then find the earliest step where that error already exists and could be seen. Put the human there.
The principal is working the wrong priority. Your next visit starts by walking it back.
Save the state, not just the prompt
Most of you already have a saved project, a custom GPT, or a Gem. That solves one problem: the instructions don't get retyped. This is the next one: the workflow has to remember what happened last time.
Step 1 of the campus workflow doesn't just need instructions. It needs last visit's action step, what the principal was told, and what the campus said its priorities were. None of that is a prompt. It's state, and a saved prompt doesn't hold it. If you have to reconstruct it from memory every time, the workflow is only as reliable as your memory.
So the last step of every workflow on this page writes something back: the decision that was made, the evidence behind it, the date. Next time, step 1 reads it. That's the "saved where, writes back to" field in the builder, and it's the one people skip.
What about agents?
You'll want to automate this. Some of you already have. Here's the ninety-second answer: automation multiplies whatever the workflow already is. An unreliable workflow with a named checkpoint, run by hand, produces one bad follow-up you catch. The same workflow automated produces forty, and you find out in a board meeting.
Build the manual version until someone else can run it and it holds. Then encode the AI steps, never the human ones. The human steps become stops the skill can't pass without you. There's a "this week" block at the bottom of the page for exactly that.
Three things every workflow on this page has.
These are fields in the builder below, not fine print. A blueprint missing any of them isn't finished.
List what goes in. Then ask of each item: would I paste this into a general AI chat? If not, that step gets redesigned: de-identify it first, summarize it yourself before it goes in, or keep that step human.
- Student names, IDs, IEP details, staff PII, personnel matters: never.
- The pattern from a data table is fine. The table with names isn't.
- Your partner will ask you this out loud during the handoff. Have the answer.
Success criterion 3, Safeguarding
Not "I review it." Which step, what error it catches, and who owns the decision. If the workflow ever gets handed to someone else, the owner is the person who is accountable when it's wrong.
- "Step 3, coach picks the priority, catches the wrong-priority error, owner: me."
- If you can't name the error it catches, it isn't a checkpoint. It's a pause.
Success criteria 2 and 5, Human Oversight and Consequence Auditing
How would someone receiving this output know AI was involved, if it matters? Sometimes it doesn't (a sorted list you'll rewrite). Sometimes it does (a communication going to districts). Decide once, in the blueprint, so you're not deciding under pressure.
- "Drafted with AI, reviewed by [role]" on the document, or nothing, but chosen on purpose.
- 103s model this for everyone else. What you write here is what your team will copy.
Success criterion 4, Transparency
Build the blueprint.
Type into the fields and it assembles on the right. Load the campus-visit example to see one finished, or pick a starter for your role at the bottom of the page if you came without a task. Two fields are marked to finish after the session if you run out of time.
The task
Purpose and intended outcomeName it the way you'd say it out loud, then what starts it.
What a good result looks like
Purpose and intended outcomeWho receives it, and what they do with it. This is how you'll judge the output.
Tool, and why that one
Approved tools; Thought PartnerThe AI you'll run this in and one reason it's the right fit for this job (a project, a saved instruction, file handling, what you already have open).
Inputs, and where they live
Data considerations; SafeguardingOne per line. Then the data check.
The steps
AI use, human checkpointsOne step per line. Start each line with AI: or HUMAN:. If you can't say which, it isn't a step yet.
The checkpoint
Human accountability and decision pointsWhich step, the error it catches, and who owns it. Put it where the error is cheapest to catch.
How I'd know it's wrong, and what I'd do
Risk assessment and mitigationWhat a wrong answer looks like from this workflow, and the move that fixes it. Accuracy, bias, who gets affected.
Disclosure
TransparencyHow the person receiving this knows AI was involved, if it matters. Decide on purpose, even if the answer is "it doesn't."
What gets saved, and what writes back
Saved stateWhere the blueprint and the standing inputs live so next time starts from there, not from scratch.
Handoff result
How others can use it; staff-ready evidenceFill this in after your partner runs it. Their first name, their tool, how many questions they had to ask, and the one thing you fixed.
Is it staff-ready? finish after
Evidence the workflow is staff-readyWhat someone on your team would need to run this without you, and whether they have it yet. Honest answer. The finished version of this field is an encoded skill, GPT, Gem, or agent that stops at every human step; that's the October deliverable.
Your blueprint
Copy pastes plain text. Paste it into a Google Doc or Word file, and that doc's link is what you submit. Anything still in italics is a field you haven't filled.
Now somebody else runs it.
Pair with the person across from you. Two pairs per table. This is the test, and it's also the only coaching you'll get today, so be a good partner: run what's on the page, not what you'd guess they meant.
- Hand over the blueprint. Nothing else.No explaining, no "what I meant was." If it isn't on the page, it doesn't exist.
- Partner asks the inputs question out loud."What's in the inputs, and would you paste it into a general AI chat?" If the honest answer is no for any item, stop and redesign that step together before running anything: de-identify, summarize first, or make it human.
- Partner runs steps 1 and 2 in their own tool.Their ChatGPT, their Claude, their Gemini, whatever they have open. Use the builder's real de-identified input, or a sample the owner supplies.
- Every time the partner has to ask the owner something, tally it."Where does this live?" "What do you mean by framework?" "Is this the priority list or the goals?" Each one is an input that's in your head and not on the page.
- Partner reads step 2's output and answers one question:Would the owner's checkpoint catch a wrong answer here? If the partner can't tell what "wrong" would look like, the checkpoint field needs work.
- Swap and do it again.Five minutes each direction. The timer's in the top bar.
- Fix one thing. Write it in the handoff field.Not three things. The one that would have stopped your partner cold.
How to read the count
Reliable. Someone else ran it from the page alone. That's the exit-ticket evidence.
Close. Each question names a missing input or a vague step. Fix those and it's there.
The workflow lives in your head, not on the page. Still worth submitting; the handoff field should say what you learned.
The count isn't a grade. It's the fastest diagnostic you'll get for whether a workflow can leave your desk.
Put it somewhere with a URL.
A paper blueprint dies in a camera roll. The whole point is that you open this again next Tuesday, so it lives in a doc.
Google Doc
- Open docs.new with your Region 7 account.
- Name it with the task name from your blueprint.
- Click Copy blueprint above, then paste.
- Share, then set to anyone at Region 7 ESC with the link can view. Copy the link.
Or, if you live in Microsoft
Word on OneDrive
- Open office.com, then Word, then a blank document.
- Name it, paste your blueprint.
- Share, then copy link, set to people in your organization can view.
Exit ticket
Your name as it appears on the roster, and the link to your blueprint doc. That's it.
If the button does nothing on your network, open the form directly. It carries whatever you typed above.
Came without a task? Start from one of these.
Every one of these has a decision in the middle that changes everything after it, which is exactly why a single saved prompt can't do them. The expensive error is named and the checkpoint is already placed where it's cheap. Load one, then make it yours.