After a year building AI systems at Isomer for insurance operations, I've come to think that one of the biggest context engineering challenges isn't a prompt problem.
It's a state problem.
Here's what that looks like in practice.
An email arrives with a first notice of loss for claim CLM-12345. The AI extracts the details and checks the policy admin system. There's a discrepancy. The email references $50K in coverage. The policy system shows $25K.
The system flags the issue for human review. An adjuster contacts the policyholder. Six hours later, they confirm that $25K is correct. The policy was never upgraded.
The system resumes and tries to create the claim in the claims management system. That step fails. Its credentials were revoked during a routine security audit. An IT ticket is filed, and four hours later access is restored.
The system resumes again, knows it doesn't need to reconfirm the limit, and creates the claim.
At each point, the system has to remember what was extracted, what the policy check returned, what the human clarified, which step failed, and what remains to be done. This is where we kept hitting walls, and it's where a lot of AI pilots quietly die.
You can have perfect retrieval, a sophisticated memory store, and a well-tuned prompt. If context doesn't persist across time, failures and people, the system becomes fragile very quickly.
The enterprise context problem
In an enterprise, context is messy by nature. It lives across email threads, attachments, internal systems and external portals. Information is incomplete. Data is wrong. Details change in the middle of a process. Work pauses and resumes hours or days later. People step in, override decisions, and add information that didn't exist when the work began.
Most discussion of context engineering is about retrieval strategies, vector databases and memory systems. Those matter. But they tend to assume context is something you fetch at runtime, rather than something that evolves over time.
That assumption breaks down fast in production.
From prompts to state
We tried the obvious approaches. Dynamic prompts with injected data. Prompt pipelines that automate multi-turn conversations. Agentic systems built around reason, act and observe loops.
All were powerful, and all eventually hit walls. Dynamic prompts struggled when work paused or failed. Agentic approaches were flexible but brittle, and often opaque in ways that make a regulated business uncomfortable.
The shift came when we realized we were solving the wrong problem. We kept optimizing prompts and retrieval. What we needed was a durable system of record for context.
Durable state, ephemeral prompts
The change was simple but foundational: the workflow became our system of record.
Workflow state holds everything that matters: extracted document data, API responses, browser automation results, decisions made, and human inputs. Prompts are generated from that state, used once, and thrown away.
The cycle looks like this:
- Workflow state holds the extracted data, the checks, and prior decisions.
- A prompt is generated from the relevant slice of that state.
- The model responds with a decision or recommendation.
- The outcome is written back into workflow state.
- The next action is triggered from the updated state.
State persists across time, retries, failures and human intervention. Prompts don't.
That buys three things.
Context survives time. When a workflow resumes minutes or days later, the system generates a fresh prompt from current state. There's no reconstruction step and no guessing about what still matters.
Context survives failures. When a browser action fails, the failure is recorded, and the next prompt includes it. The system doesn't lose its place.
Context survives people. When an adjuster corrects coverage details or overrides a decision, the change goes straight into workflow state. The system and the people work from the same source of truth.
What it changed
Once we made the shift, ingestion, extraction and action stopped feeling like disconnected tricks. They started behaving like one system. Prompts became snapshots of shared state, not the place where meaning lived. Context moved out of the prompt and into the workflow.
That's a different emphasis from most of today's context engineering conversation, which is about RAG, embeddings and context window management. Those are component-level optimizations. For us, workflow state as the system of record is what made context engineering work in messy, real-world environments.
A few patterns have held up over the year:
- The mess is valuable. Enterprise data is scattered, incomplete and constantly changing. Learning to work inside that mess turned out to be one of our best sources of context.
- Better components don't fix an architectural mismatch. We could have improved retrieval forever; without a durable model of context, the system stayed fragile.
- Workflow orchestration is infrastructure. We first treated it as task coordination. It turned out to be the foundation.
- The hard part is all three at once. Surviving time gaps, failures and human intervention, often in the same claim, is the real test.
Where context lives
The context engineering conversation is still early. Retrieval and memory matter, but they're part of a larger architectural question: where does context actually live?
Where auditability, recovery and working alongside people matter, that question is unavoidable. Treating workflow state as the system of record has been our practical answer.
One last observation. When we adopted workflow orchestration, we thought we were building an agentic workflow system. That turned out to be wrong. Workflow wasn't the product; it was infrastructure. That's a story for another time.
If you're building enterprise AI that has to survive real-world chaos, ask yourself: where does your context live, and what happens to it when things go wrong?