🐛 Bug Description
Both LLM stages of the structure-retrieval feature request strict structured output through the Agents SDK output_type=, which sends a strict json_schema response_format: the draft-structuring agent in quantmind/flows/paper/_structure.py (output_type=PaperStructureTreeDraft) and the agentic retriever in quantmind/mind/retrieval.py (output_type=_RetrievalSelectionDraft). Providers that support only response_format: {"type": "json_object"} and not strict json_schema — DeepSeek, for example — reject the request, so both PaperFlow.build and AgenticRetriever.retrieve fail. This contradicts the multi-model support documented in contexts/design/mind/retrieval.md ("Multi-Model Compatibility").
🔄 Steps to Reproduce
- Set
DEEPSEEK_API_KEY and select a DeepSeek model, e.g. PaperStructureCfg(model="litellm/deepseek/deepseek-chat").
- Run
await PaperFlow(cfg).build(LocalFilePath(path=<any page-aware pdf>)).
- Observe the failure at the draft-structuring call;
AgenticRetriever.retrieve fails identically for the same reason.
✅ Expected Behavior
Structure build and agentic retrieve run on any provider the SDK can route, including json_object-only providers, consistent with the design's multi-model-compatibility claim.
❌ Actual Behavior
The provider rejects the strict json_schema response_format and the build aborts before producing a tree.
📋 Environment
📝 Additional Context
Offline tests mock agents.Runner.run, so no real response_format is ever sent; the "covers at least one non-OpenAI model" claim in the design is mock-only, which is why this stayed hidden until a live smoke run. OpenAI models, which support strict json_schema, work end to end.
Error Logs
litellm.exceptions.BadRequestError: litellm.BadRequestError: DeepseekException - {"error":{"message":"This response_format type is unavailable now","type":"invalid_request_error","code":"invalid_request_error"}}
File "quantmind/flows/paper/_structure.py", line 130, in structure
output = await asyncio.wait_for(run_with_observability(agent, ...))
🛠️ Possible Solution
Port the compatibility handling already implemented on branch feat/mind-memory (commit 1dc67ee — "fix(flows): real LLM-call compatibility — MCP lifecycle, JSON-object fallback, schema-strict bypass") to this feature's structuring and retrieval agents: fall back to json_object (or a non-strict mode) when a provider does not support strict json_schema, and validate the parsed output in code. Add a live smoke assertion against at least one json_object-only provider so this cannot regress silently.
Checklist
🐛 Bug Description
Both LLM stages of the structure-retrieval feature request strict structured output through the Agents SDK
output_type=, which sends a strictjson_schemaresponse_format: the draft-structuring agent inquantmind/flows/paper/_structure.py(output_type=PaperStructureTreeDraft) and the agentic retriever inquantmind/mind/retrieval.py(output_type=_RetrievalSelectionDraft). Providers that support onlyresponse_format: {"type": "json_object"}and not strictjson_schema— DeepSeek, for example — reject the request, so bothPaperFlow.buildandAgenticRetriever.retrievefail. This contradicts the multi-model support documented incontexts/design/mind/retrieval.md("Multi-Model Compatibility").🔄 Steps to Reproduce
DEEPSEEK_API_KEYand select a DeepSeek model, e.g.PaperStructureCfg(model="litellm/deepseek/deepseek-chat").await PaperFlow(cfg).build(LocalFilePath(path=<any page-aware pdf>)).AgenticRetriever.retrievefails identically for the same reason.✅ Expected Behavior
Structure build and agentic retrieve run on any provider the SDK can route, including
json_object-only providers, consistent with the design's multi-model-compatibility claim.❌ Actual Behavior
The provider rejects the strict
json_schemaresponse_formatand the build aborts before producing a tree.📋 Environment
📝 Additional Context
Offline tests mock
agents.Runner.run, so no realresponse_formatis ever sent; the "covers at least one non-OpenAI model" claim in the design is mock-only, which is why this stayed hidden until a live smoke run. OpenAI models, which support strictjson_schema, work end to end.Error Logs
🛠️ Possible Solution
Port the compatibility handling already implemented on branch
feat/mind-memory(commit1dc67ee— "fix(flows): real LLM-call compatibility — MCP lifecycle, JSON-object fallback, schema-strict bypass") to this feature's structuring and retrieval agents: fall back tojson_object(or a non-strict mode) when a provider does not support strictjson_schema, and validate the parsed output in code. Add a live smoke assertion against at least onejson_object-only provider so this cannot regress silently.Checklist