Announcements
Customer names were hallucinated because Code Interpreter is a creative reasoning environment, not a strict passthrough for fetched data. When enabled, it can create structures, fill gaps, and generate synthetic data to complete tasks like Excel files or tables. In your flow, the Fabric data agent returned partial or aggregated data without enforced row-level labels. When asked to generate an Excel file, the interpreter detected missing required fields (e.g., Customer Name) and invented plausible values to satisfy the schema. This is an autonomy issue, not a bug—the interpreter had no constraints telling it that names must come only from Fabric or that fabrication was disallowed. Disabling Code Interpreter “fixed” the issue because it removed the model’s ability to author or reshape data, sharply reducing hallucination risk—at the cost of losing file generation. Microsoft’s implicit guidance today is to avoid Code Interpreter for authoritative or regulated outputs (financial, customer, contractual) unless data is fully serialized and locked. Safe patterns include:
Best practice: Generate files directly in Fabric (queries + Excel via notebooks/pipelines) and let Copilot only present or explain results.
Constrained use: Allow the interpreter only when Fabric returns fully materialized, schema-locked data—with hard “no fabrication” instructions (risk reduced, not eliminated).
Visualization-only: Use the interpreter solely for charts/formatting on final tables—no adding rows or text fields.
Recommendation for your setup: Keep Code Interpreter off for customer data, generate Excel in Fabric, and consider splitting responsibilities into a data agent (authoritative) and a presentation agent. Until schema-locked, no-fabrication modes are GA, the agent should not be the data author when correctness matters.
Thanks for the response. One clarification: the data agent did return the fields that were requested and displayed to the user (customer name and revenue). The issue was not that those fields were absent or required completion.
The problem seems to be that, when generating the Excel file, Code Interpreter did not consistently reuse the values already shown by the data agent and instead regenerated content in some runs. This also explains why the same setup worked for one user but not for another.
Given this behavior, disabling Code Interpreter for customer data exports is currently the safest option.
The data agent itself behaved correctly: it successfully retrieved the requested fields (such as customer name and revenue) and displayed them accurately to the user. There was no issue with missing fields or incomplete data retrieval.
The problem arises during Excel file generation, where Code Interpreter does not reliably reuse the already‑retrieved values. Instead, in some runs it appears to re‑generate or reinterpret the data, leading to inconsistencies. This also explains the non‑deterministic behavior you observed—why the same configuration worked for one user but produced incorrect results for another.
Given this behavior, the issue is not with the data agent or schema, but with the handoff between the data agent and Code Interpreter during export. Until guarantees exist that Code Interpreter will strictly consume provided data (instead of regenerating it), disabling Code Interpreter for customer data exports is the safest and most predictable approach.
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
Jump in, show your community spirit, and win prizes!
Expanding mentorship, skilling, and AI innovation
These are the community rock stars!
Stay up to date on forum activity by subscribing.
Valantis 277
11manish 206
sannavajjala87 156 Super User 2026 Season 1
