Agentic, But Only Semi-Autonomous: Designing an EDA Pipeline You Can Trust

TL;DR

Ask an LLM to analyze a spreadsheet in one shot and you get a single, opaque decision — no visible reasoning, no way to check its numbers. Agentic EDA is a semi-autonomous agentic workflow instead: four LLM agents, each broken into a plan-then-act pair, where every judgment call is left to the model and every calculation, code execution, and file write is left to plain code. Autonomy here is handed out on purpose, not maximized — the pipeline's steps are fixed in advance; only what happens inside each step is left to the model. This covers what "agentic" actually buys you here, why semi-autonomous beats both a single call and a fully autonomous agent, and the real problems that surfaced building a live version of it.

Introduction

Exploratory Data Analysis (EDA) is the first pass over any new dataset — profile it, spot patterns, chart what matters, write up the findings. An agentic AI workflow, in the simplest useful sense, is a process where an LLM-based app executes multiple steps to complete a task, rather than answering in one shot — a framing — agentic_eda/ holds the four agents, a script that runs them end to end, a notebook, and a small web app that streams every step live.

flowchart TD

    A[Raw spreadsheet] --> B[Clean the data]

    B --> C[Look at each column]

    B --> D[Look at relationships]

    C --> E[Write the report]

    D --> E

    E --> F[Finished report]

Composition, in short:

1. A cleaning agent profiles the raw data, decides how to fix it, writes the cleanup code, and hands back a cleaned file.


2. Two more agents run independently against that cleaned file — one per column, one per relationship between columns.


3. Each of those two works in two visible turns: decide what's worth showing and why, then write the chart code — carrying its own earlier reasoning into the second turn instead of starting cold.


4. Any code a model writes runs in a sandboxed subprocess before anyone trusts it; a failure gets handed straight back to the same model, capped at a small number of fix attempts.


5. A final agent gathers every prior decision and every chart and writes the narrative; plain code lays out the finished document.

Step 3, roughly:

plan = ask_model(

    instructions="Decide which relationships are worth charting, and why.",

    context=data_summary_and_real_correlations,

)

chart_code = ask_model(

    instructions="Now write the chart code for exactly what you planned.",

    context=plan,   # the model's own reasoning, carried forward

)

One shared safety valve. Every piece of model-written code — cleanup or charts — passes through the same small piece of plain code before anyone trusts it: written to a temp file, run in its own process with a time limit, only counted as successful if it actually produced the expected output.

One shared on/off switch. Every agent can optionally report its own progress through a single optional callback. The script and notebook don't use it; the web app does — which is the entire reason a live interface could be built without touching how the agents themselves reason.

Challenges

1. Two runs stole each other's charts. The code that collects finished charts does it the simple way — it looks in a folder for new image files. Run two analyses at once pointed at the same folder, and each picks up the other's charts too. The fix: give every run its own private folder from the start, instead of untangling ownership after the fact.

2. A slow model call froze the whole web app. None of the model calls or code-checking steps are fast — some take minutes. Run one directly inside the web server and the whole server sits there unable to answer anyone else until it finishes. The fix: hand each run off to its own background worker, so the server stays free. A nice side effect: since the work no longer lives inside the request, closing a browser tab can't cancel a run that's already minutes deep and costing real money.

3. Long silences looked like a crash. An analysis step can go minutes without producing anything visible — indistinguishable, on screen, from a hang. The fix: make every agent report its small in-between moments too — "now planning," "now writing code," "retrying" — plus a heartbeat every ten seconds, so a quiet stretch reads as "still working," not "still there?"

4. Model-written chart code sometimes just didn't run. Every so often the model writes code referencing a column that no longer exists after cleanup, or an outdated charting call. The failure looks like any broken program's — an error message with output and traceback attached. Instead of ending the run, that message gets fed straight back to the same model as a follow-up: "here's what went wrong, please fix it" — capped at two attempts, so a genuinely broken plan doesn't retry forever. On screen this shows up as an honestly-labeled retry, not something hidden — it's the most interesting thing that happens in a run, not an embarrassment.

Conclusion

The trick behind this project isn't spreading work across four agents — it's choosing, on purpose, how much autonomy each step actually needs. Every judgment call sits between two plain-code steps: one handing the model a fact it didn't have to guess, one checking whether what it produced actually holds up.

The lesson generalizes past spreadsheets: autonomy is a dial you set per step, not a default you maximize. A workflow doesn't need to be highly autonomous to be agentic — it needs the model making real decisions at the steps that actually require judgment, and nothing else. Decide upfront which steps are safe to hand over and which aren't, fix that scaffold in code, and let the model reason freely only inside it.

Worth noting if you're weighing this for your own project: fixed steps with model-made decisions inside them are usually the sweet spot in practice, long before "the agent plans its own pipeline" earns its added risk. Save full autonomy for the one step that actually needs it.