Session Types and Flow-Based Batching: AI Session Management That Actually Works

You can coordinate multiple agents now. Your multi-agent coordination patterns handle parallel work, your vault provides shared context, and your fan-out pattern runs three sessions without contradictions. The architecture is solid. But here's what nobody tells you about multi-agent productivity: the bottleneck isn't your agents. It's you.

Monday morning. You open Claude Code to process backlog items — quick triage, five items, should take fifteen minutes. Forty-five minutes later, you're deep in an architecture analysis for item three. The other four items sit untouched. You didn't plan to do deep work. You planned to do triage. But the session had no guardrails, no scope constraint, no distinction between shallow processing and deep analysis. Every session looked the same. Every session defaulted to whatever captured your attention.

This isn't a willpower problem. A 2025 METR study found experienced developers were 19% slower when using AI tools on real codebases — not because the tools were bad, but because the interaction pattern destroyed their flow state. Stop coding. Prompt the agent. Wait. Review the output. Reject. Re-prompt. By the time you get usable output, the deep focus that made you effective is gone. It takes 15 to 20 minutes to reach a productive flow state. Every context switch resets that clock.

The fix isn't using AI less. It's using the right type of AI session for the right type of work.

The AI Productivity Trap — Why Deep Work with AI Agents Keeps Failing

The problem has a name now. The CIO's "AI Productivity Trap" describes what happens when practitioners apply one interaction mode to every type of work. The stop-prompt-wait-review cycle works fine for quick lookups. It destroys deep analysis. Running it for both is like using a chainsaw for surgery and woodcutting — effective at one, catastrophic at the other.

Cal Newport's Deep Work established that cognitive performance depends on matching your mental mode to your task. Shallow work — email, status updates, quick decisions — requires minimal focus and tolerates interruption. Deep work — architecture analysis, strategic writing, complex problem-solving — requires sustained concentration. They need different environments, different time blocks, different mental preparation. Everyone knows this for traditional knowledge work. Almost nobody applies it to AI-augmented work.

Here's what's missing. Steve Kinney's Claude Code course covers session commands — /clear, --resume, /compact. GitButler's guide covers session branches — auto-creating git worktrees for parallel work. claudefa.st covers session tasks — DAG-based dependency chains across sessions. All useful. All technical. None of them answer the foundational question: what TYPE of work is this session for? They manage the session's plumbing without ever classifying its purpose.

The missing layer is a taxonomy. Not of tools or commands — of cognitive modes. Different types of work require different interaction patterns with your agent. Quick backlog triage needs minimal context and rapid responses. Deep story refinement needs full vault access and thorough analysis. Architecture review needs your axiom-principle-rule framework loaded and counter-arguments enabled. Sprint retrospective needs evaluative criteria, not creative exploration.

When every session looks the same, you get the worst of both worlds. Triage sessions load unnecessary context (slow). Deep work sessions get interrupted by shallow items (shallow). Review sessions miss quality criteria because the agent doesn't know it's reviewing. The overhead isn't in having multiple configurations — it's in NOT having them. Every undifferentiated session pays a hidden tax in wasted context, broken flow, and mismatched interaction patterns.

Put concrete numbers on that tax. If the METR finding holds — 19% slower with undifferentiated AI interaction — a PO spending 3 hours daily with AI agents loses roughly 35 minutes to flow disruption. Per week, that's nearly 3 hours. Not because the agent is slow. Because the interaction mode doesn't match the cognitive demand. A triage session running with deep-work context wastes time loading and processing information the agent doesn't need. A deep work session interrupted by triage items loses 15-20 minutes recovering flow state each time. Multiply across a week of mixed, unclassified sessions and you understand why practitioners feel busy with AI but not productive.

The context engineering principle that taught you to fix context before fixing prompts applies here too. Fix the session architecture before optimizing the prompts within it. The same scope-intolerance that constrains your product decisions should constrain your AI sessions. A triage session that becomes deep work mid-session is a scope failure — and just like product scope creep, it degrades everything it touches.

Four Session Types for AI Workflow Productivity

The taxonomy below isn't theoretical. It emerged from specific productivity failures and the patterns that fixed each one. Four types. Each has a different cognitive demand, a different agent configuration, and a different success metric.

Type 1: Triage (15-30 minutes, shallow, batch processing). The morning inbox session. Process backlog items. Scan pull requests. Review overnight messages. The cognitive demand is classification and routing — not analysis. The agent needs minimal context: current sprint priorities, basic acceptance criteria standards, nothing more. Loading your full vault for triage is like bringing reference books to sort mail. The success metric is throughput: items processed per minute. Flow state requirement: none. Triage is designed for interrupted environments. You can stop mid-session and resume without losing anything because there's nothing deep to lose.

Your triage CLAUDE.md looks different from your deep work CLAUDE.md:

# Triage session configuration
role: sprint-triage
focus: Classify and route backlog items. Flag items needing deep analysis.
context_scope: current-sprint.md, acceptance-criteria-standards.md
output_format: one-line assessment per item with priority flag
constraints: Do NOT deep-dive. Flag for deep work session if analysis needed.

Type 2: Deep work (1-2 hours, focused, single-task). One problem. Full attention. Architecture analysis, strategic document drafting, complex story refinement. The agent needs full context: your entire vault, your decision framework, counter-arguments enabled, extended analysis mode. The success metric is quality of output, not speed. Flow state requirement: high. Protect this time. No Slack. No email. No switching to "quickly check one thing." Your first Claude Code workflow introduced the basics of working with an agent. Deep work sessions are where that foundation pays off — sustained collaboration on a single problem where the agent's full capabilities matter.

# Deep work session configuration
role: deep-analyst
focus: Thorough analysis of a single topic with full context
context_scope: vault/axiom/, vault/principle/, vault/rule/, vault/product/
output_format: structured analysis with counter-arguments and recommendations
constraints: Single topic only. Do not context-switch. Flag new topics for triage.

Type 3: Review (30-60 minutes, evaluative, comparative). Assess output quality. Compare approaches. Check consistency across documents. The cognitive demand is critical evaluation — different from both creation (deep work) and classification (triage). The agent needs access to prior outputs, quality criteria, and comparison frameworks. You're not generating new work; you're evaluating existing work. The success metric is issues identified. Flow state requirement: moderate. Analytical mode, not creative mode.

# Review session configuration
role: quality-reviewer
focus: Evaluate outputs against quality criteria. Compare for consistency.
context_scope: vault/quality-standards/, relevant prior outputs
output_format: issue list with severity and recommended fix
constraints: Evaluate only. Do not fix issues in this session — log them for deep work.

Type 4: Spike (30-60 minutes, exploratory, time-boxed). Research a new area. Prototype a concept. Test a hypothesis. Spikes are the most dangerous session type because they have no natural stopping point. You start exploring and three hours later you've gone deep into something that wasn't on your roadmap. The fix: always time-box spikes. Set a timer. The agent is configured for breadth over depth — wide search, creative exploration, minimal constraints. But the session itself is constrained by time, not scope. The success metric is hypotheses tested, not conclusions reached.

# Spike session configuration
role: explorer
focus: Broad research on a specific question. Test hypotheses.
context_scope: minimal — load relevant context as discovered
output_format: findings summary with "explore further" / "dead end" flags
constraints: Time-boxed to [30/60] minutes. Capture hypotheses, not conclusions.

The counter-argument you're thinking: "Four CLAUDE.md files? That's overhead I don't need." Fair. Start with two. Triage and deep work. One file swap. The distinction between "process items quickly" and "analyze one thing deeply" is the most valuable cognitive boundary you'll draw. Add review and spike later when you notice those patterns emerging in your work.

Flow-Based Batching: Scheduling Claude Code Session Management by Cognitive Mode

You have session types. Now: when do you run each one?

Flow-based batching means scheduling AI sessions by cognitive mode, not by calendar availability. The insight from Csikszentmihalyi's Flow research: flow states require a match between challenge and skill level. Triage sits below the flow threshold — it's routine processing, and that's fine. Deep work hits the flow zone — challenging enough to engage fully, achievable enough to sustain focus. Review is evaluative — a different mental mode than creation. Spike is exploratory — playful focus, curiosity-driven.

Your cognitive capacity shifts predictably across the day. Morning: processing mode. Your brain handles accumulated items efficiently but hasn't warmed up for complex analysis. Midday to afternoon: peak focus. The window for deep work. Late afternoon: evaluative mode. Energy drops for creation but works well for critical assessment. These are general patterns — your personal peaks may differ. The point isn't the specific schedule. It's that session types HAVE a schedule, and it follows cognitive rhythms.

Here's a weekly template for PO work:

Monday morning: Triage session (20-30 min). Scan the weekend's backlog changes. Classify items as ready / needs-refinement / blocked. Route to the right session type for later in the week. This is the same backlog refinement workflow from the Foundation track — now explicitly classified as a triage session.

Tuesday-Thursday afternoons: Deep work sessions (1-2 hr each). One topic per session. Tuesday: story refinement for the highest-priority items flagged during Monday triage. Wednesday: architecture review on the tech debt proposal. Thursday: stakeholder document for steering committee. Each session gets its own CLAUDE.md variant. Each session is protected time.

Friday morning: Review session (45-60 min). Evaluate the week's outputs. Compare story refinements for consistency. Check that architecture recommendations align with your axioms. This is where you catch the contradictions that multi-agent work can introduce — even with shared context from your coordination patterns, review catches what automation misses.

Spike sessions: Float. Don't schedule spikes in advance. They emerge when a question blocks progress or curiosity strikes. When they happen, time-box them immediately. A 30-minute spike on a new technology area. A 45-minute exploration of a competitor's approach. Always capture findings in a brief summary, even if the spike was a dead end. Especially if it was a dead end — that knowledge prevents duplicate spikes.

The synchronous vs asynchronous dimension matters here. Triage and deep work are synchronous — you work with the agent in real time, iterating on output. Some review work can be asynchronous: launch the consistency check, continue other work, return to results. Claude Code's background mode and the fan-out pattern from A7 enable this. Fire off three review analyses in parallel, then evaluate all three results in a focused review session. The agent does the comparison; you do the judgment.

Notice how session types map to multi-agent coordination patterns. Triage sessions often use single-agent or simple fan-out — process multiple items in parallel, each with minimal context. Deep work sessions use the shared-context-hub pattern — full vault access, full decision framework, one focused problem. Review sessions benefit from fan-out comparisons — launch parallel evaluations, then synthesize. The session type determines not just how YOU work, but which agent pattern fits. This is the integration layer between personal productivity and agent architecture.

One more pattern to name: the session mislabel. You start a triage session. Item three turns out to need architecture analysis. You're twenty minutes into what was supposed to be quick classification, and now you're doing deep work — but with triage-level context and triage-level agent configuration. The output will be shallow because the setup was wrong. The fix: a 5-minute classification step before every session. "What type of work is this?" If the answer takes more than 60 seconds, it's probably a spike. If a triage item needs more than 5 minutes, reclassify it as deep work, close the triage session, and open a deep work session with the right configuration. The classification step costs 5 minutes. The mislabel costs 45.

Build Your Session Type System This Week

Can you name your session types and explain which agent configuration each uses? If your morning triage processes 10 items in 20 minutes while your afternoon deep work produces one thorough analysis in 90 minutes — not because you worked harder, but because the agent configuration matched the cognitive demand — the productivity architecture is working.

Here's this week's exercise:

1. Audit your last week. Look at your recent AI sessions. How many were quick processing (triage)? Focused analysis (deep work)? Evaluating output (review)? Exploring something new (spike)? Most practitioners find they do roughly 60% triage, 25% deep work, 10% review, 5% spike — but every session used the same configuration. Name what you've been doing.

2. Create two CLAUDE.md variants. Triage (minimal context, fast responses, batch instructions) and deep work (full vault, thorough analysis, single-task focus). Two files. One swap. This is the minimum viable session type system.

3. Run a session-typed day. Tomorrow, start with a 20-minute triage session using the triage config. Process your accumulated items. Then switch to a 90-minute deep work session using the deep work config. The triage session will feel faster because the agent loads less context. The deep work session will feel deeper because you're not context-switching. The difference is architectural, not motivational.

4. Add the classification step. Before every session: "What type of work is this?" If you can't answer in 60 seconds, it's a spike. If triage takes more than 5 minutes per item, it's deep work in disguise. Reclassify. The cost of misclassification is always higher than the cost of classification.

5. Build your weekly template. After one week of session-typed work, your patterns will be visible. When do you do your best deep work? When is triage most efficient? Map your session types to your cognitive rhythms. The schedule is a default, not a prison — but having a default beats having no structure at all.

You've structured how you work WITH agents. Different session types for different cognitive modes. Different configurations for different work. But every session type described here is active — you trigger the agent, it works, you review the output. What about agents that work for you without being triggered? Contextual watchers monitor quality dimensions in the background — the scope watcher that flags acceptance criteria gaps, the consistency watcher that catches contradictions across sprint stories. They're not sessions you run. They're agents that run for you. The difference between a system you operate and a system that operates alongside you.