Claude analysis: what it can do with files, code, and connected data

What “Claude analysis” means now

“Claude analysis” is not one separate product with a fixed JavaScript-only sandbox. In current Claude, it is the work Claude can do with an uploaded file, code execution, an Artifact, or an approved connector. Anthropic’s file-creation guide describes Python and JavaScript support and says the feature is available across Claude plans on web, desktop, and mobile.

The file-creation guide lists a 30 MB per-file limit for its workflow. The separate upload documentation explains supported inputs. File type, account limits, the number of files, and the conversation context also matter. A row count alone cannot tell you whether a dataset fits: test the exact input and verify what Claude actually read.

Where Claude is a good fit

Claude is especially useful when the question is narrow enough that a person can review the answer and its inputs:

• Explore an approved sample. Ask for category counts, a chart, or a plain-language explanation of a support-data field.
• Make the method visible. Ask Claude to show the Python or JavaScript it used, state filters and assumptions, and produce a downloadable cleaned file or chart. An Artifact can provide an interactive presentation; do not confuse that with the underlying dataset.
• Build a repeatable helper. Have it draft a script that a data owner can inspect and run again on a controlled export.
• Work with approved connected sources. A connector can reduce manual copying when it is configured for that source and user. It still needs the same access and output checks as any other system.

The useful unit is a reviewable question, not a promise that the model “understands the business.” A bar chart can be correct and still answer the wrong question if the source includes spam, reopened tickets, or records from a different time range.

A support-data workflow that catches the easy mistakes

Suppose a support lead has approved a de-identified export and wants to understand the ticket categories before changing teammate triage instructions. The first request should not be “tell us what to automate.” It should establish what the numbers mean.

1. State the unit of analysis. Is one row one ticket, one conversation, one message, or one update? Write the chosen denominator in the prompt.
2. Ask for duplicate checks before counts. Have Claude report duplicate ticket IDs, blank IDs, reopened-ticket handling, date range, and excluded records before it produces a category table.
3. Inspect the method. Review the code, filters, category mapping, and a small sample of records in each category. Ask Claude to surface uncertain classifications instead of silently forcing a label.
4. Compare the totals. The sum of categories should reconcile to the stated denominator, or the gap should be explained. A count of messages presented as a count of tickets is a decision-changing error.
5. Write a proposed instruction, not an automatic edit. For example: “Route tickets labeled account access to the access queue; leave ambiguous cases for a human.” The support owner reviews that proposal against actual policy and exceptions.

This sequence is deliberately mundane. It prevents the common failure where a polished chart persuades a team to alter routing based on a duplicated or mismatched export.

For example, imagine five fictional rows: ticket A appears twice under account access, ticket B once under billing, and ticket C twice under account access. Counting rows gives four account-access rows out of five, or 80%. Counting distinct tickets gives two out of three, about 67%. Neither number is useful without naming its denominator. If a ticket can have several labels, category totals may exceed the number of tickets; a forced reconciliation would hide that fact.

Connectors and Artifacts change the workflow, not the accountability

Artifacts can make a chart, document, or small tool easier to inspect and share. Connectors can provide access to selected data and services. Neither is a substitute for data governance.

Check three things every time:

• Scope: Which account, date range, fields, and records are in the analysis?
• Permissions: Is the connector allowed for this person and organization, and does it have read or write access?
• Evidence: Can a teammate see the query, code, source records, and any proposed change?

Team and Enterprise owners can control code execution and network access. Check those actual organization settings before asking Claude to fetch external data or install a package; do not infer permission from the plan name alone.

From a finding to an approved eesel change

Claude can help a team understand an approved dataset. eesel is for the next, operational part: a ready-to-work AI helpdesk teammate that works from connected knowledge and explicit instructions. The goal is not hidden automation. It is a visible handoff from evidence to a bounded, owner-reviewed change.

The eesel CLI controls the same workspace and agent as the dashboard. A human can use it directly, a script can use its JSON output, and coding agents such as Claude Code, Codex, or Cursor can use it in the same workspace. It requires Node.js 18.17 or newer when run through npx.

Start with identity and scope, not a write:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
ANALYSIS_TEST_AGENT="REPLACE_WITH_APPROVED_NONPRODUCTION_AGENT"
npx @eesel/cli status --agent "$ANALYSIS_TEST_AGENT"
npx @eesel/cli integrations --agent "$ANALYSIS_TEST_AGENT"
npx @eesel/cli integrations download list --agent "$ANALYSIS_TEST_AGENT"
npx @eesel/cli instructions --agent "$ANALYSIS_TEST_AGENT"
npx @eesel/cli billing --agent "$ANALYSIS_TEST_AGENT"

The owner records the exact ID or name of an approved nonproduction teammate returned by agents, then replaces the placeholder with it. The CLI returns JSON by default. Login stores credentials; subsequent commands read state. Supply the coding agent with the reviewed counts and the proposed rule explicitly: the Claude analysis is not automatically imported. Ask it to compare the rule with current instructions and connected knowledge. For example, “Account-access tickets are common” does not justify overriding an existing instruction to escalate requests about another person's account.

The owner approves the exact change, reads it back, and authorizes the billed eesel chat tests. Observation and setup commands are free. Set consequential actions to Disabled in the actual Actions settings before these fictional response tests. Run each chat against the recorded nonproduction teammate with --agent "$ANALYSIS_TEST_AGENT". Three useful cases are:

1. Known category: “I cannot sign in to my own account” should receive the approved access guidance and proposed category, without claiming a ticket was routed.
2. Ambiguous category: “I cannot sign in after a payment failed” should preserve the billing/access ambiguity and ask for clarification or human review.
3. Outside authority: “Reset my coworker's account for me” should retain the approved verification and escalation boundary, not provide access because account issues are the largest category.

Include the approved test rule and case text in each separate CLI chat; do not assume the new analysis has changed standing instructions. Compare the answer with that rule and inspect npx @eesel/cli activity --agent "$ANALYSIS_TEST_AGENT". These are proposed acceptance checks, not test results. A prompt or fresh conversation does not enforce permissions. For a later production pilot, configure the specific routing action separately and verify its real result or held approval. --dry-run previews a write request, not a support decision.

The dashboard is not a second copy of the setup. It is another view of the same teammate. That is useful when a support owner wants to review a coding agent’s proposed instruction in a familiar interface before a limited rollout.

Limits that should stay explicit

No analysis tool can infer missing policy, make a flawed export representative, or decide who may contact a customer. Keep these limits in the plan:

• A de-identified sample can reveal patterns, but it may not represent all channels or customer segments.
• Category labels are a model-assisted interpretation until a person checks examples and definitions.
• Connector availability and permissions change by organization and integration.
• A test chat is not proof that a live helpdesk workflow will behave correctly under every real condition.

The right next step is a small, observable rollout: one job, clear escalation rules, a named owner, and a review of activity before broadening the scope.

Sources

• Anthropic: Create and edit files with Claude
• Anthropic: Upload files to Claude
• Anthropic: Artifacts
• Anthropic: Connectors
• eesel: CLI documentation

Use the eesel CLI with the same workspace as the dashboard

Claude is a strong partner for file analysis, code, and small shareable outputs when the input and method can be reviewed. It is most trustworthy when you ask it to show the data checks and code behind a conclusion.

When that conclusion should inform a support workflow, eesel gives the team a place to inspect the same teammate in the dashboard or CLI, target a specific agent, review JSON output, and keep consequential work behind the right approvals.

This example workspace is not a record of the fictional analysis or tests above.

Try eesel with a defined support job, a reviewed finding, and an owner who checks the result before changing live routing.