Why the Format of a Live Session Matters More Than the Topic
Ask any experienced instructor what separates a cohort that ships portfolio projects from one that quietly fades out by week four, and you will not hear "the syllabus." You will hear something structural: how the two hours on Zoom were spent, who spoke when, how the labs were sequenced, and what happened between sessions. The topic is almost fungible. The format is not.
That is why we treat the anatomy of a live session as a first-class engineering problem at Refonte Learning. A session is not a lecture with breaks. It is a designed sequence of cognitive states, deliberately interleaving explanation, demonstration, retrieval, and hands-on execution. Get the sequence wrong and even world-class content lands flat. Get it right and mid-career learners with full-time jobs still ship production-grade work.
This article walks through the exact format we run in 2026: the 90-minute session anatomy, the roles in the room, the tooling stack, the breakout lab mechanics, the recording flow, and the between-session scaffolding that ties it all together. If you are considering a cohort program (ours or anyone else's), this is the operational lens you should evaluate them against.
We wrote this as a companion to our broader piece on Refonte live session quality standards, which covers the qualitative bar. This piece is the mechanical companion: what actually happens, minute by minute, and why.
One caveat before we start. The format below is what we run for technical cohorts in AI engineering, data engineering, cloud, DevOps, and software engineering tracks. Softer disciplines (DevRel, product) share the skeleton but tune the ratios. Where relevant we call out the variations.
The 90-Minute Session: Why This Length, Not 60 or 120
We standardized on 90 minutes after running variants from 45 to 180 minutes across three years of cohorts. The tradeoffs are not subtle.
A 60-minute session forces the instructor to cut either the demo or the lab. You end up with a lecture. Learners rate it well in the moment because it feels efficient, but four weeks later they cannot reproduce anything. Retention data from post-cohort assessments consistently showed a 30-40% drop compared with longer formats.
A 120-minute session, on the other hand, exceeds working-adult attention budgets, especially for cohorts spanning multiple time zones where someone is inevitably joining at 9pm local time. Drop-off past the 95-minute mark is measurable and steep. Chat activity falls off a cliff. Camera-on rates halve.
Ninety minutes lets us run a full loop: 10-minute anchor, 25-minute concept and demo, 5-minute break, 35-minute breakout lab, 15-minute debrief and Q&A. It fits inside the biological attention window with one deliberate break, and it leaves 30 minutes of dead time before the next hour block so participants can pull water, use the restroom, or spill over into hallway conversations without derailing the schedule.
The 90-minute standard is also what tutors are prepared and paid to deliver, and it aligns with our tutor preparation standards, which allocate 4 hours of prep per hour of delivery. Extending the session length would either force cuts to prep quality or double the cost per session. Neither is acceptable.
One exception: capstone sessions and code review clinics run 120 minutes because the interactive review model requires more per-learner time. Those sessions are announced two weeks in advance and treated as a distinct format with a distinct participation contract.
The Roles in the Room: Trainer, Assistant, Producer
A Refonte live session in 2026 always has at least two staff members present, and for cohorts above 20 learners, three. The roles are not decorative. Each solves a specific failure mode we saw in early cohorts when a single instructor tried to do everything.
The Trainer owns the pedagogical arc. They deliver the anchor, run the demo, host the debrief, and make real-time decisions about pacing. They do not answer chat questions during the concept segment. That discipline matters: the moment a trainer starts multi-tasking chat, delivery quality degrades and the session slips off its timing rails.
The Teaching Assistant (TA) owns the chat channel and the breakout rooms. During concept delivery, the TA is triaging questions, marking which ones the trainer should answer live versus which get handled asynchronously. During breakouts, the TA rotates between rooms, unblocking learners who are stuck on environment setup or missing context. TAs are typically alumni of the same program, one or two cohorts ahead. This role is different from the mentor role; the distinction is unpacked in our post on mentor vs tutor differences.
The Producer (for larger cohorts) owns the tooling. They start recordings, launch breakout rooms, manage the polling and whiteboarding tools, and are the single point of contact when someone's audio cuts out or a shared notebook stops rendering. Having a dedicated producer sounds like overhead until you have watched a trainer lose 12 minutes of a 90-minute session debugging a Zoom breakout allocation.
The roles are explicitly separated because the cognitive load of each is high enough that combining any two degrades both. This mirrors how production incident response works: incident commander, communications lead, and technical lead are separate roles for the same reason.
Session Anatomy, Minute by Minute
Here is the actual template a trainer receives for a standard technical session. The times are not aspirational; they are the delivered structure, tracked and reviewed post-session.
Minutes 0-5: Arrival and Anchor Prep
Doors open five minutes before the official start. Trainer and TA are on camera, mic hot, welcoming people by name as they arrive. This is not filler. It is the first calibration of whether the audio, video, and shared-screen stack are functional for tonight's cohort. If someone's microphone is broken, we would rather know at minute -3 than minute 8.
Minutes 5-15: The Anchor
Ten minutes of context setting. The trainer states the session's single learning objective (one objective, not three), reviews the last session's key concept in one slide, and previews what learners will be able to do by the end of tonight. Crucially, the anchor also includes a live retrieval prompt: a question that forces learners to actively recall material from the prior session, submitted via poll or chat. Retrieval-based openers correlate strongly with next-session retention in our internal data.
Minutes 15-40: Concept and Live Demo
Twenty-five minutes of concept exposition interleaved with live coding or live tool operation. The rule is strict: no static slide runs longer than three minutes without transitioning to a demo artifact (a notebook cell, a terraform plan output, a Kubernetes manifest, a dbt model run). We do not lecture over static content. If the concept cannot be demonstrated live, it does not belong in the concept segment; it belongs in async reading.
Minutes 40-45: Structured Break
Five minutes off camera. Trainer confirms breakout room assignments are ready. TA drops the lab brief into the cohort channel with expected outcomes and a starter repo link.
Minutes 45-80: Breakout Lab
Thirty-five minutes of hands-on work in rooms of 3-5 learners. Every room has a defined deliverable: a working notebook cell, a passing test, a deployed sandbox resource. Rooms are not free-form study halls. The TA rotates. The trainer joins the rooms that flagged for help via the raise-hand signal or the shared status tracker.
Minutes 80-90: Debrief and Q&A
Back in the main room. Two or three rooms share what they built or where they got stuck. The trainer addresses the top three questions the TA flagged during the lab. The session closes with a preview of the async work due before the next session and an explicit reminder about recording availability.
Breakout Labs: Where Learning Actually Happens
If the concept segment is where knowledge is transmitted, the breakout lab is where it is built. This is the segment we obsess over most because it is where cohort programs most commonly fail.
A badly designed breakout is a Zoom room with four strangers, no defined deliverable, and 30 minutes on the clock. What happens next is predictable: the confident learner talks, the quiet learner disengages, and after 25 minutes everyone has done a fraction of what any of them could have done alone. This pattern is common enough that many learners now list "unstructured breakouts" as their top complaint about cohort programs in general.
Our breakout format is deliberately over-specified to prevent this. Each lab has:
- A single deliverable, phrased as an executable outcome. Not "discuss deployment strategies" but "deploy the provided FastAPI service to the sandbox cluster and paste the healthcheck URL in the shared doc."
- A starter artifact, usually a repo or notebook, so no one is fighting a blank screen.
- A defined role rotation for rooms of 4+: driver (keyboard), navigator (thinks ahead), scribe (documents blockers). Roles rotate at the halfway mark.
- A visible progress tracker, a shared Google Doc or Notion table where each room updates its status every ten minutes.
- An escape hatch, a documented "if you are stuck for more than 8 minutes, drop your blocker in the tracker and the TA will visit."
Room composition matters. We shuffle rooms every two sessions, not every session (relationships need time to form) and not never (the same three people together for eight weeks creates a subculture that resists external contribution). We also try to balance rooms by declared experience level, not to homogenize them but to ensure no room is entirely composed of learners who will all get stuck at the same point.
Breakout labs are also where the difference between cohort format and 1-on-1 mentoring becomes visible. Both have value, and we cover the choice in 1-on-1 mentoring vs cohort sessions. The short version: breakouts teach you to think with peers under time pressure, which is the actual condition of most engineering work. 1-on-1s teach you depth on your specific blockers. You want both.
The Technology Stack: What Runs Under the Session
The session format only works if the tooling is invisible. When a learner is thinking about Zoom breakout mechanics, they are not thinking about the material. So we standardized the stack and stopped changing it experimentally.
The primary conferencing platform is Zoom, chosen for breakout room reliability and the recording pipeline. We evaluated Google Meet, Teams, and several purpose-built cohort platforms in 2024 and 2025. Zoom still won on breakout room stability at cohort scale, which is the operation that fails most visibly when it fails.
The collaboration layer is a combination of Notion (for the session brief, lab specs, and progress trackers), GitHub (for starter repos and submitted work), and a Slack workspace for async discussion. Slack, not Discord, because more of our learners have Slack from their day jobs and adoption friction matters.
For code-heavy sessions, we use a shared cloud dev environment (GitHub Codespaces or a preconfigured JupyterHub instance depending on the track). This eliminates the "it works on my machine" opening 15 minutes that used to eat entire sessions. Learners still install locally as part of the curriculum, but the live lab never depends on their local setup being correct.
On the trainer side, we require a dual-monitor setup, a wired ethernet connection where possible, a broadcast-quality microphone (not laptop internal mic), and an uncluttered background. These are not aesthetic preferences. Audio quality is the single strongest predictor of learner-reported session satisfaction, ahead of content quality, in our post-session survey data. The full technical bar is documented in our post on technical requirements for live sessions.
One intentional omission: we do not use AI-generated real-time summaries or AI-driven engagement dashboards during the session. Both were piloted and both created a subtle effect where trainers started performing for the dashboard rather than for the learners. Post-session AI-assisted transcript search is available; live AI overlays are not.
Recording, Playback, and the Async Loop
Every session is recorded. This sounds obvious but the operational details matter, and the boundaries are non-trivial. Our full policy is documented separately in the session recording policy, but the format-relevant points:
The recording captures the main room only. Breakouts are not recorded, by design. This is what makes breakouts a psychologically safe space to be wrong out loud, which is the point of them. Learners know that when they enter a breakout room, the recording stops for them until they return to the main room.
Recordings are available within 24 hours, with chapter markers auto-generated from the session template (anchor, concept, lab brief, debrief). Chapter markers matter because a learner reviewing a session two weeks later almost never rewatches the whole 90 minutes; they jump to the concept segment they need. Without chapter markers, that review takes 15 minutes of scrubbing. With them, it takes 30 seconds.
The async loop between sessions is where a lot of the actual learning consolidates. Between session N and session N+1, learners have three things to complete: a short reading (15-30 minutes), an exercise (60-90 minutes), and a submission to the cohort channel (5 minutes). The trainer or TA reviews submissions before the next session and pulls two or three anonymized examples into the anchor of session N+1. This closes the loop and makes the async work visible, which is what makes learners actually do it.
Without this visibility, async completion rates drop below 50% by week three. With it, they hold above 80% through week eight. The mechanism is social, not technical.
Cohort Size and the Shape of the Room
We run cohorts between 12 and 30 learners. Below 12, breakout dynamics break down (you cannot form 3-4 rooms of 3-4 people and get the room-to-room diversity that makes debriefs interesting). Above 30, the trainer can no longer hold the room by name, and the session drifts toward broadcast mode.
The sweet spot is 18-24. It gives you 5-6 breakout rooms, enough diversity in the debrief, and a chat channel that stays readable rather than becoming a firehose. It also fits inside the cognitive load of a single trainer plus TA, which is our default staffing.
Cohort size interacts with format in ways that are not always obvious. A cohort of 15 can sustain longer debrief segments because each room can share. A cohort of 28 cannot: if each of 7 rooms shares for even 90 seconds, the debrief consumes 10 minutes and you lose the Q&A. So for larger cohorts we sample two rooms randomly per session and rotate which rooms present across the cohort's lifetime. Everyone presents at least twice over an eight-week cohort.
We also cap cohorts by time zone spread. A cohort with learners spanning more than 8 hours of time zone difference cannot practically meet live twice a week. So we run parallel time-zone-aligned cohorts (EMEA-friendly, Americas-friendly, APAC-friendly) rather than one global cohort with rotating times. The pedagogical loss of "global perspectives in every session" is real but smaller than the pedagogical loss of half the cohort being sleep-deprived.
Session Cadence: Twice a Week, and Why Not More
Standard cadence is two live sessions per week, typically Tuesday and Thursday or Monday and Wednesday, with a 48-72 hour gap between them. This is deliberate.
One session per week is too slow. The gap allows too much forgetting; anchors have to spend 15 minutes rebuilding context and effective learning time drops to about 60 minutes per session. Three or more per week is too fast for working professionals. Async work does not fit between sessions, and the sessions start feeling like a broadcast schedule rather than a learning arc.
Two sessions with async work between them creates a rhythm: consume-and-demonstrate live, apply async, return with questions, repeat. The 48-72 hour gap is long enough to hit the async work seriously but short enough that the context is still warm.
We also have one "office hours" slot per week, unstructured, optional, drop-in. This is not part of the format proper; it is a safety valve. About 30-40% of learners attend any given office hour, and the ones who do tend to be either the strugglers (getting unblocked) or the accelerators (going deep on something adjacent). The middle 40% skip office hours and do fine.
Cohorts run for 8-12 weeks depending on the track. For our AI Engineering Program at Refonte Learning, the live-session portion runs 10 weeks with an additional 6-week internship phase where session cadence drops to weekly and the format shifts toward code review clinics and mentor check-ins.
Assessment Inside the Session Format
Assessment in a live-cohort format looks nothing like traditional exams, and the format is designed around that. There are three assessment surfaces built into the session structure itself.
First, the retrieval prompts at the start of each session. These are low-stakes, ungraded, but visible to the trainer and TA. Consistent inability to retrieve prior concepts is an early signal that a learner needs a 1-on-1, not a stern email.
Second, the breakout deliverables. Every lab produces an artifact. The trainer sees the artifact, either in real time via the shared tracker or in the debrief. Learners who never produce artifacts, or whose artifacts consistently look like their room partner's, get a check-in call. Not punitive, diagnostic.
Third, the async submissions. These are the closest thing to graded work in the cohort, and they are reviewed with written feedback within 48 hours. The feedback is where the highest-value teaching often happens, because it is one-to-one and specific to the learner's actual code.
What we deliberately do not do inside the live session is high-stakes testing. Timed quizzes during a session change the psychological state of the room and turn peers into competitors. We save summative assessment for a proctored capstone at the end of the cohort, where it belongs.
This matters because assessment shapes behavior. If you want a room where learners help each other during breakouts, you cannot also grade them against each other during those breakouts. The format enforces the pedagogical choice.
What Changes for Different Program Tracks
The 90-minute anatomy is the default, but different tracks tune it. Worth naming the variations because they are format-relevant.
AI Engineering and Data Engineering tracks lean heavier on the lab segment (often 40 minutes instead of 35) because the tooling (notebooks, distributed compute, dbt runs) has more setup surface. Concept segments compensate by being tighter.
Cloud and DevOps tracks run more "chaos" labs where the starter environment is intentionally broken and the deliverable is to diagnose and fix it. The debrief is longer because the range of correct solutions is wider and worth walking through.
Software Engineering tracks run more paired programming inside breakouts, with strict driver-navigator rotation every 15 minutes. The debrief often includes a mini code review of one room's work, projected and discussed.
Career-adjacent tracks like our DevRel path (covered in the DevRel career guide) tune differently again: less code, more communication artifacts, and breakouts that produce written or recorded deliverables rather than shipped code. The 90-minute skeleton still holds.
Across all variations, the anchor, break, and debrief timings are fixed. Only the middle segment ratios flex. This makes the format legible to learners even when they switch tracks or attend a cross-listed session: the shape of the session is always the same shape.
Common Failure Modes and How the Format Prevents Them
Worth naming the specific ways cohort sessions go wrong, because a good format is legible through the failures it prevents.
The lecture drift: a trainer over-prepared with slides ends up broadcasting for 70 of the 90 minutes and learners passively absorb. The 25-minute cap on the concept segment and the mandatory 35-minute lab prevent this structurally. Trainers cannot lecture past minute 40 because they physically need to hand off to a lab.
The breakout collapse: rooms produce nothing because the deliverable was vague. The single-deliverable rule and the shared progress tracker prevent this. If a room hasn't updated its tracker at the 10-minute mark, the TA visits.
The chat firehose: 25 questions arrive in five minutes and the trainer loses the thread. The TA-owned chat channel prevents this. The trainer never reads chat during concept segments. Full stop.
The 20% dominance: a small subset of vocal learners takes 80% of the airtime. Room shuffling every two sessions and the driver-navigator-scribe role rotation prevent this in breakouts. In the main room, the trainer explicitly calls on rooms rather than opening the floor.
The technical wipeout: someone's environment breaks and 15 minutes evaporate. The cloud dev environment default and the producer role prevent this. Local setup issues are handled async, not live.
The trainer burnout: sustained delivery at this quality level is expensive. The 4:1 prep-to-delivery ratio, the TA support, and the strict 90-minute cap prevent trainers from running themselves into the ground within two cohorts. Our approach to preparing trainers is covered in tutor preparation standards.
Each of these failure modes has cost us real learner outcomes in real cohorts. The format we run in 2026 is the accumulated response to them.
Evaluating Any Cohort Program Against This Standard
If you are evaluating a live-cohort program (ours or anyone else's) the questions you should ask are format questions, not marketing questions. "How long are the sessions?" is a weak question because 90 minutes can be well-spent or badly-spent. Stronger questions:
- What is the ratio of lecture to hands-on lab in a typical session?
- What is the deliverable for a typical breakout, and can I see an example?
- Who owns the chat channel during delivery?
- What is the ratio of instructor prep hours to delivery hours?
- What happens to a learner who falls behind in weeks 2-3?
- Are breakouts recorded? (Correct answer: no, and here is why.)
- What is the cohort size range?
- How often do rooms shuffle?
- What is the async work rhythm between sessions?
A program that cannot answer these crisply has not thought about format. A program that answers them differently from us has thought about it and made different tradeoffs, which is fine. A program that answers them the way we do is running some version of what we run.
Format is not the only thing that matters (curriculum quality, trainer expertise, and post-cohort support matter enormously) but format is the thing most often skipped in evaluation because it is boring to talk about. It is not boring to experience. It is the entire difference between a cohort you remember five years later and a cohort you forget by December.
Closing: Format as a Pedagogical Contract
A live-session format is a contract between the program and the learner. The program says: we will show up prepared, structure your two hours, protect your attention, produce artifacts you can point to, and record what you missed. The learner says: I will show up on time, do the async work, engage in breakouts, and treat the room as a place to be wrong out loud.
Everything in the 90-minute anatomy exists to make both sides of that contract deliverable. The 25-minute concept cap protects the learner's attention. The TA role protects the trainer's focus. The breakout deliverable protects the learner from wasted time. The recording protects the learner from missed sessions. The 4:1 prep ratio protects the trainer from delivering half-baked material. It is a system, and each part depends on the others.
If you want to see this format in operation before committing, the AI Engineering Program at Refonte Learning runs public info sessions using the same anatomy described above, at a compressed 45-minute length. It is not the full cohort experience, but it is a faithful sample of the format. Attend one, watch the timings, and evaluate whether this is a room you want to spend two hours in twice a week for ten weeks. If the answer is yes, the rest of the program is designed to hold up to that expectation.
About Refonte Learning
Refonte Learning is operated by Refonte Infini Infiniment Grand, a French SAS (SIREN 949 841 605), with an operational office at 1 Poulton Close, Dover, Kent, United Kingdom, CT17 0HL. We run cohort-based technical training programs in AI engineering, data engineering, cloud, DevOps, and software engineering, combining live sessions, async work, and internship placements. Corporate registration is publicly verifiable at data.inpi.fr/entreprises/949841605.