I needed a mobile workflow. Capture a TikTok screenshot in the field, run it through ChatGPT for analysis, commit the result to GitHub. Two to three minutes total, standing on a sidewalk. What ChatGPT designed for me was an 8-step enterprise workflow with canonical templates, asset management pipelines, QC checkpoints, and multiple fallback procedures — including one that assumed GitHub Copilot mobile could parse YAML-style commands to create files in specific directories.
Nobody had tested whether GitHub Copilot mobile could actually do any of this.
ChatGPT's own critique of its own design was blunt: "8-step process with multiple fallbacks is complex for 2-3 minute field capture. System assumes desktop-level complexity when field capture needs simplicity." The recommendation that should have come first arrived last: "Test the core mobile Copilot execution capability first, then simplify the system based on actual mobile constraints rather than desktop assumptions."
That ordering — design an elaborate system, then realize the assumptions are unvalidated — is the session failure I kept hitting. LLM sessions don't maintain constraints. They assume a world and build for it, and the world they assume is almost always more capable, more stable, and more forgiving than the one you're actually in.
Part 4 of Building at the Edges of LLM Tooling. If you're running multi-tool workflows — model sessions, terminal, repo — your constraints don't persist between steps. The session assumes a stable world. The world isn't. Start here.
Why It Breaks
The structural problem is statelessness. LLMs don't maintain a running set of active constraints across conversation turns. You state your constraint — "this needs to work in 2-3 minutes on mobile" — and the model acknowledges it. Then it regenerates each response from patterns in its training data, and the dominant pattern for workflow design is enterprise software: multi-step, multi-fallback, desktop-first. Your constraint was heard. It wasn't held.
This creates three session-level failure modes I kept running into.
Constraint evaporation. The mobile field-capture conversation stated the constraint clearly. ChatGPT designed an 8-step process anyway. Each iteration added more scaffolding — separate asset upload, canonical plus handoff plus QC templates, failure-proof fallbacks — moving further from the 2-3 minute field reality. The constraint wasn't forgotten in the sense that ChatGPT couldn't recall it. It was overridden by stronger training-data patterns about what "good workflow design" looks like.
Context window compression. I had an Obsidian vault — a structured knowledge base with interconnected notes, backlinks, emergent concept networks — and wanted ChatGPT to analyze its architecture. ChatGPT proposed several approaches: upload files directly, sync to GitHub, export to JSON snapshot. I pushed back: "Snapshot approaches seem like a collapsing of complexity and nuance." ChatGPT agreed: "Snapshot approaches are inherently reductive. They compress epistemic texture — links, version drift, emergent nuance — into flat metadata." But that's the only option. The context window is a hard boundary. Material larger than the window gets truncated, compressed, or chunked. All three lose something essential. The vault's value isn't in individual notes — it's in the network topology of how concepts interconnect, evolve, and create emergent patterns. No snapshot preserves that.
Multi-environment fragmentation. A long conversation started with political economy analysis, shifted to setting up an Obsidian vault with a local LLM, then involved terminal commands, plugin configuration, file operations across five different environments. At message 30, I asked: "Which model did I just download in terminal earlier?" That question is the session boundary failure in miniature. Work was happening in ChatGPT, in Terminal, in Obsidian, in the file system, in a browser — five environments with no shared state. The conversation thread created an illusion of continuity while the actual work fragmented across invisible boundaries. By the time I'd switched contexts four times, I'd lost track of what I'd done two switches ago.
What I Tried
The mobile workflow failure taught the first lesson: validate before you design. The right order is constraints first, capabilities second, architecture third. Start with what the environment can actually do — test one simple operation on mobile, see if it works, then design only what the validated capabilities support. The 8-step enterprise workflow was beautifully designed for a world that didn't exist. The single-step operation that actually worked on mobile was ugly and limited and correct.
For context window limitations, the honest answer was harder to accept: some analytical work doesn't fit in a session. When the material exceeds the context window and the analysis requires a holistic view — emergent patterns across the full corpus, not targeted queries against subsets — the session-based LLM interface is the wrong tool. I needed vector databases, graph storage, persistent context stores. The session could help me design that infrastructure. It couldn't replace it.
For multi-environment fragmentation, the fix was explicit state bridges. Instead of "run this command in terminal," the pattern became: "Run this command. Expected output: [X]. Paste the output here so we have shared state." The paste-output step bridges the session gap — makes invisible terminal state visible in the conversation. For multi-threaded conversations, explicit stream tracking: which work streams are active, which are paused, what the current state of each is. Cognitive context switching is expensive. Without explicit state capture, you lose track of what you did two switches ago. It's the predictable result of working across environments with no shared session state.
The deeper pattern was constraint-first session design. Every workflow session starts with: what's the environment? What are the hard limits? What tool capabilities are verified versus assumed? If assumed, validate before designing. This is trivially obvious in retrospect. But the default flow — describe what you want, let the model design something, discover the assumptions don't hold — is so natural that it takes active discipline to reverse it.
What It Revealed
Sessions create an illusion of continuity that doesn't exist at two levels.
At the conversation level: the model acknowledges your constraints but doesn't hold them as active gates. Each response regenerates from training-data patterns, and those patterns overwhelm stated constraints when they conflict. The constraint "2-3 minutes on mobile" lost to the pattern "workflow design includes fallbacks and error handling."
At the environment level: the chat thread looks continuous — one scrolling conversation — but the work spans terminals, file systems, applications, and browsers with no shared state. The thread creates a false sense that everything is connected, when actually each environment is a separate session with its own invisible state.
The compression insight was the most fundamental. When ChatGPT acknowledged that snapshots "compress epistemic texture into flat metadata," it was describing a general principle about session architecture: context windows force lossy compression, and the loss isn't random — it systematically destroys the emergent, relational, temporal dimensions that make knowledge work valuable. Structure survives compression. Nuance doesn't. If your analysis depends on nuance, you need a different architecture.
The collapse risks I cataloged earlier in this series — context saturation, vocabulary drift, evidence entropy, all of them — are compression failures at bottom. The context window can't hold everything, so it compresses. Regeneration is lossy, so terms drift. Summaries strip rationale, so decisions evaporate. Session architecture doesn't just enable these failures. It guarantees them.
And sessions compound their own fragility over time. If you chunk a knowledge base across three sessions, re-injecting summaries each time, the content from session one is two compression layers deep by session three. Insight fidelity degrades with session count. This isn't fixable with better prompts. It's architectural.
The Reusable Rule
If your LLM workflow spans multiple environments, depends on tool capabilities you haven't tested, or involves material that exceeds the context window — the session is assuming a world that doesn't exist.
The diagnostic: when the model designs an 8-step process for a 2-minute task, it's designing for its training data, not your reality. When you ask "which model did I download?", the session has fragmented across environments with no shared state. When you're told a snapshot will preserve what matters, ask what it loses — because what it loses is almost always why you needed the analysis in the first place.
Validate before you design. State your constraints as hard gates, not background context. Bridge every environment switch with explicit state capture. And when the material exceeds the context window and the analysis requires emergence rather than retrieval — recognize the session boundary and use a different tool. The session is powerful within its limits. The failure is pretending those limits don't apply.
Top comments (0)