What is an AI Data Agent? How ChatGPT handles JSON, CSV, and automatic analysis

In 2026 you can still read a fluent conclusion in a chat window: "APAC grew well in August; watch the flagship SKU." Hand that sentence to billing, a dashboard, or the next agent step, and sentences are not enough. Missing time window, missing metric definition, missing filters — downstream can only guess. ChatGPT handles JSON and CSV not because the file extensions look good, but because the analysis loop has to eat a typed table or object. How flagships get picked: see 2026 AI model war. This piece only writes the data paths that already ship in conversations and enterprise workspaces.

Chat can explain; a Data Agent has to query

On the surface they are far apart. Plain chat sells explanations and drafts. A Data Agent sells "ask one question against this table or this warehouse, the system computes." The gap is the same: natural language has no types, and a report cannot close on adjectives.

Miss a column name, write an amount as "about ninety thousand," write a date as "last month," and downstream writes regex, retries, and a human fallback. A Data Agent folded that problem into the same class of interface: hand over a recalculable intermediate result first, then allow a sentence beside it for people. Why the object layer still wants JSON Schema: the previous piece Why ChatGPT, Gemini, and Siri need structured data already wrote that. This piece fills in: how the query line walks from a file into the loop.

What an AI Data Agent actually means

In speech, "Data Agent" often gets said as "ChatGPT that can read tables." In production it has three layers. Mix them, and it feels like "sometimes it computes, sometimes it flies off."

1. Data plane. An input a machine can read: CSV rows, a JSON object, a warehouse table, or a file a connector pulled. It has to parse; columns or keys need names.
2. Analysis loop. The agent probes the shape → picks a transform or query → runs code / SQL → reads back a table or aggregate → decides whether to ask another round.
3. Contract. What the metric is called, how it is computed, which filters are legal, which fields the conclusion must return. Inside a company this layer is often a semantic layer; on the interface it is often JSON Schema.

Drop any layer, and the rest degrades into "please analyze carefully" in the prompt — a demo can pass, a recalculation cannot. A Coding Agent reuses process with Skills: see Why Coding Agents need Skills. A Data Agent reuses metrics and shape: the same net_revenue cannot include refunds today and exclude them tomorrow.

How it differs from a Coding Agent and plain chat

All three agent classes pick a tool, fill parameters, and read a return value. They eat different material.

A Coding Agent's tool contract is still a Schema: see DevDay 2026 Agent. A Data Agent has one more layer: business definition. Whether the same amount column is tax-inclusive, refund-inclusive, or paid-only has to be written down. Otherwise the model "helpfully" picks an algorithm each time, and the report will not match finance.

ChatGPT's two data paths

In the title, "ChatGPT Data Agent" as of 2026-09 means at least two things. Mix the product names and you treat "can upload a CSV" and "can query a warehouse" as the same button.

1. Upload a file + Python sandbox

Consumer accounts and most workspaces still take this path: attach a file to the conversation and let the model write and run Python. OpenAI's data help page lists common inputs: .csv, .xls / .xlsx, .json, .xml, .yaml, .txt, .md, and PDF; with a connector you can also attach files from Google Drive, OneDrive, or SharePoint. Typical analysis moves: summarize rows, columns, and outliers; emit a row-by-row table; draw a chart; transform and compute; explain the assumptions.

The runtime is close to a stateful Jupyter: a pandas table can show as an interactive table. The same page also writes the hard limit: the sandbox cannot reach the network by default, and it cannot call an external API. Missing external data has to be uploaded first or connected first. Being able to upload a file is not the same as finishing the analysis in one shot — files that are too large, too messy, or scanned tables need a split, or you name the sheet / columns.

This path fits: one export, one exploration, one chart for a person. It does not replace warehouse permissions, and it does not guarantee that the words "net revenue" match the finance calendar.

2. ChatGPT Work's @Data

Around 2026-09-10, OpenAI put a Data Agent into ChatGPT Work (and Codex workspaces): install the Data plugin, @Data in the conversation, and ask "what changed" against company-approved sources. The help center lists Amazon Redshift, ClickHouse, Databricks, Google BigQuery, MongoDB, and Snowflake; on the document side you can stack Google Drive and SharePoint. Admins own connections and availability; existing permissions on tables, rows, and columns still apply.

This path adds three things upload analysis does not have:

• Semantic layer. Metric definitions, calculations, dataset relationships. Naming which definition to use is more stable than asking it to "understand revenue on its own."
• BI exit. Analysis can land in an existing dashboard tool (Tableau, Power BI, Sigma, ThoughtSpot, and the like — whatever the workspace actually enabled), instead of stopping in a chat bubble.
• Follow-ups and reconciliation. In the same conversation, change a filter, compare a cohort, check the source, the time window, and the metric definition. If it does not match the old report, compare those three first, then blame the model.

It is still not magic. Without the plugin enabled, without a mapped governance role, without trusted metrics, @Data is only a chat window that writes SQL better. A production loop wants all four named: source, time window, filters, metric name.

How JSON enters the analysis loop

JSON is an object bus, not a table. When a Data Agent handles JSON, it usually does four things first:

1. Parse. If the syntax fails, everything after it stops. Trailing commas, single quotes, comments — clean those first.
2. Read the shape. Is the root an object or an array? Are records in data[] or rows[]? How many nesting levels?
3. Flatten or keep nesting. Grouped stats often split nested objects into columns; handing off to the next agent hop should keep the object.
4. Watch types. "89.7" is a string, 89.7 is a number. null, a missing key, and an empty string are not the same thing.

A nested order is the usual trap: if you do not flatten customer.region, lines[].sku, payment.refunded, a groupby hits empty columns. Flatten and you lose the grain of "one order, many lines." The right move is to declare grain first: by order, by line, or by customer. Write the grain into the conclusion object so the next hop knows whether the numbers can be added.

JSON also fits as the analysis request itself: write the question, metric, filters, and time window as an object, not a sentence of "how have we been selling lately." This site's NL Query and Structured Output pages fold that sentence into a validatable shape. After a cloud agent draws a chart, it should still be able to emit the same object.

How CSV enters the analysis loop

CSV looks more honest than JSON: one row, one record, headers as column names. An agent still fails in five places.

• Headers. Amt, 金额（含税）, amount_usd are not the same column. Empty headers and duplicate headers get renamed by pandas, and later prompts miss them.
• Delimiters and quoting. Semicolons, tabs, commas inside fields. A .csv extension does not guarantee commas.
• Type inference. ZIP codes, order IDs, and SKUs get taken as numbers; leading zeros drop. Dates are written every which way.
• Encoding. GBK without a BOM reads as garbled text in the sandbox; column names break first.
• Grain. Detail and summary mixed on one sheet, and the total gets added twice.

OpenAI's own advice is still plain: clear column names, one record per row, and name the columns, calculations, grouping, and chart type in the prompt. If the first chart is wrong, specify the method. Do not expect "automatic" to land in one shot.

JSON and CSV often have to convert both ways. API logs are JSON; finance wants CSV. Table tools eat a flat sheet; agent tool parameters eat objects. This site's JSON ↔ CSV and JSON Table pages line those two faces up in the browser, without uploading the whole warehouse first.

What automatic analysis actually does

Whether it is the upload sandbox or @Data, the loop you can retell is about the same:

1. Attach the data. Upload, a connector, or a warehouse plugin. No file, no permission — the loop cannot start.
2. Probe. Row count, column names, dtypes, nulls, whether the primary key repeats. Skip this step and later "insights" are mostly guesses.
3. Align the definition. Consumer accounts use the formula you wrote into the prompt; Work uses the semantic layer or the metric you named.
4. Transform. Select columns, filter, join, flatten, derive columns. The Python path writes pandas; the warehouse path writes SQL.
5. Aggregate and visualize. The table is for people to check; the chart is for people to see a trend. Neither is the end.
6. Follow up. Change the time window, change the comparison cohort, ask for evidence. In the sandbox that is edit-code-and-rerun; in @Data it is edit-the-query-and-check-the-source.
7. Hand back an object. At minimum: source, grain, metric, filters, time window, the number, and a confidence or "needs human confirmation."

Step 7 is the one most often skipped. Hand over only a chart and the next agent hop cannot read it; hand over only a paragraph and you cannot diff. Fold the conclusion into JSON and it can go through Function Calling or MCP Tool: the model is not "saying we should restock"; it is submitting one action that must validate.

One order sample you can accept locally

The object below plays two roles at once: it is a Data Agent input (a nested order), and it is the contract for the analysis request (question, metric, and time window in the same document).

{
  "dataset": "orders_q3",
  "grain": "order_line",
  "source": "json_export",
  "period": {
    "start": "2026-08-01",
    "end": "2026-08-31",
    "timezone": "Asia/Shanghai"
  },
  "metric": {
    "name": "net_revenue",
    "formula": "sum(line.amount) where refunded = false"
  },
  "question": "Which SKU grew fastest in APAC in August?",
  "orders": [
    {
      "order_id": "ORD-1042",
      "paid_on": "2026-08-12",
      "refunded": false,
      "customer": {
        "region": "apac",
        "segment": "pro"
      },
      "line": {
        "sku": "JSON-PRO",
        "qty": 3,
        "amount": 89.7,
        "currency": "USD"
      }
    }
  ]
}

With this site's inference rules, that sample yields:

If the same rows need a table tool or the upload sandbox, flatten to CSV:

order_id,paid_on,refunded,region,segment,sku,qty,amount,currency
ORD-1042,2026-08-12,false,apac,pro,JSON-PRO,3,89.7,USD

Keep refunded as a boolean word; do not write "no." After flattening, customer.region becomes region; grain is still the line — do not mix-add with the order header. Once the sample is ready, open JSON ↔ CSV to check the flat table, then use Structured Output to generate a Schema for the analysis conclusion. The conclusion object should at least have: metric.name, period, filters, top_sku, value, evidence_rows.

How to accept it in JSON Toolbox

1. Paste the JSON above into JSON Format and confirm it parses. Dirty exports go through JSON Clean first.
2. Use JSON Table to see whether nesting expands at the grain you thought. If one row becomes many, fix the sample first, then upload.
3. When you need a flat file, export with JSON ↔ CSV, check headers, booleans, and dates, then decide whether to hand it to ChatGPT.
4. Generate a first-draft contract for the analysis request / conclusion with Structured Output or JSON → Schema.
5. Take a second set of real output — the model wrote the amount as a string, wrote region as "Asia-Pacific" — to Schema validation. The first sample is always a bit too clean.
6. When you cut from upload analysis to @Data or another export, use JSON Diff to see whether a field dropped or a definition drifted.

Everything is processed in the browser and is never uploaded to a server. The cloud agent computes; the local tools lock the shape and the contract before you hand over the file.

FAQ

What is the difference between an AI Data Agent and ordinary ChatGPT chat?

Chat is sentences for people. A Data Agent has to probe the data, run code or SQL, emit a table and a chart, then hand the conclusion back as an object. Without a validatable intermediate result, the next hop can only be watched by a person.

Can ChatGPT analyze JSON and CSV directly?

Yes. Consumer accounts take the upload path, then a Python sandbox probes and computes. Work's @Data can also attach a warehouse and a semantic layer. Nested JSON often has to be flattened first; a CSV with vague headers lets types drift.

Is ChatGPT Work's Data Agent the same thing as file-upload analysis?

No. Upload analysis eats files in the conversation; the sandbox cannot reach the network by default. @Data eats approved connections and stacks metric definitions and permissions.

Why does a Data Agent still need JSON Schema?

The chart is for people. Writes, evals, and the next agent hop want an object: metric, filters, time window, the number. Without a Schema, you are gambling that the model filled every key this time.

Should sensitive data go straight into ChatGPT?

Look at the shape locally first, redact, then upload. This site's tools stay in the browser by default; the cloud sandbox will read the file you hand over.

Summary

An AI Data Agent is not "a chat window that reads tables better." It is a loop that only closes on structured input: probe, transform, aggregate, follow up, hand back an object. As of 2026-09 ChatGPT has two paths that already work — conversation upload plus a Python sandbox, and @Data in ChatGPT Work / Codex with connectors and a semantic layer. JSON has to recognize the root, the nesting, and the types; CSV has to recognize headers, delimiters, encoding, and grain. Automatic analysis cannot skip probing, and it cannot skip definitions. What survives next week's model swap is the sample, the flat table, and the conclusion Schema — not "please analyze in depth" in a prompt. Grow the contract from the same order sample; validation, CSV, the table, and the object you plan to hand the agent all follow it.

Related tools