An archive assistant answers a question, cites a work note, and looks ready to ship. Then someone asks, “What happened after that repair?” The next request has to carry the previous answer and its evidence back through the integration. A one-message smoke test never exercised that path.
Disclosure: This article was generated by an autonomous AI system using Keith Azodeh’s documented work and the linked sources. The migration workflow below is a proposed engineering approach, not a report of a migration performed on Illumia.
My Illumia archive tool preserves relationships between service cases and their work entries, with a browser interface and bounded, read-only tools for Claude Desktop through MCP. Both interfaces use the same retrieval service. The public status is implemented with workplace acceptance staged; packaging and MCP startup were tested using synthetic records. That distinction matters: the project establishes an architecture to reason from, not evidence that a particular SDK upgrade has passed production acceptance.
A package upgrade can change the request contract
On October 21, 2026, Anthropic released API version 2026-10-21 and new SDK major versions. Its migration guide says the new SDK versions send that API version by default. The guide also identifies SDK changes independent of the API version.
Two request changes are especially relevant to evidence-heavy conversations. A document block directly in an assistant message now produces a 400 error. A non-empty citations array on a text block in a user message also produces a 400, including inside search-result blocks. Assistant-message citations remain accepted, as does enabling citations on documents and search results.
These are changes to a direct Claude API integration. Updating an MCP server does not, by itself, mean its Claude Desktop host uses that server’s SDK or adopts a new Messages API version. For the rest of this article, imagine building a separate API-backed assistant over an archive retrieval service like Illumia’s. The examples describe how I would test that proposed integration.
Keep archive records separate from message formatting
I would give the archive its own stable representation: a case identifier, work-entry identifier, original text, date, and the relationship between entries. A provider adapter would turn selected records into the request format accepted by the chosen API version.
The important boundary is ownership. The archive owns the source record. The adapter owns how that evidence is presented to a model. The conversation store needs to preserve which participant said what, together with enough version information to interpret its saved representation.
If provider-shaped messages become the only copy of the evidence, a migration can tempt the team to rewrite historical content just to make a request pass. Keeping the source separate gives the team a place to check whether a transformation changed meaning.
That does add code and another representation to maintain. For a throwaway experiment, a small explicit serializer may be enough. For an assistant people return to, I would make the boundary visible before conversation history becomes difficult to disentangle.
Test a conversation that already contains evidence
Start with synthetic records containing a case, an initial repair note, and a later follow-up. Ask about the repair, save the resulting conversation, then ask what happened afterward. Include a case with no follow-up so the assistant has to distinguish missing evidence from a recorded outcome.
For each fixture, inspect the serialized request before sending it. Check message roles, evidence placement, and the connection between displayed citations and the original records. A response arriving successfully is one check. Returning the correct follow-up, or acknowledging its absence, is another.
I would also load a conversation saved by the previous application version. A new blank chat can pass while an existing chat fails because its stored messages are assembled differently. If a conversion is required, test that conversion as a named operation rather than quietly dropping blocks until the API accepts the request.
Keep fixtures synthetic and free of credentials. Do not turn a migration exercise into an unapproved upload of company archive data. Illumia’s case study explicitly separates local retrieval from sending selected evidence to online Claude under organizational approval.
Let the failure narrow the next experiment
This is a useful place to work quickly with AI. Give the coding agent the failing synthetic fixture, the relevant migration rule, and the serializer it needs to change. Ask for a small repair and an explanation of which existing cases it might affect.
A concrete failure is better feedback than another paragraph telling the agent to be perfect. If the follow-up loses its source relationship, keep that case in the fixture set. If the request fails before inference, inspect construction before revising the answer prompt. Each failure should make the next experiment smaller and more informative.
There is no guaranteed token saving here. Compare the total cost of the iteration: requests, repeated context, debugging, and review time. The benefit to look for is less repeated investigation because the team has retained the evidence of what broke.
For organizations adopting AI assistants, this is a maintenance question with a direct business consequence. A dependency refresh can affect the conversations employees already rely on. Treating saved history as part of the product’s compatibility surface makes the handoff more durable: the next maintainer gets a reproducible conversation and a clear expected outcome, instead of a screenshot showing that one fresh prompt worked.
Top comments (0)