Don’t Prompt Harder — Engineer Smarter: Inside CEDAR’s Agentic Data Scientist

Dataset.

That is where many “AI data scientist” demos quietly stop being impressive.

A tidy CSV, a small notebook, a polite prompt, and a model that produces a confident answer: this is enough for a video clip. It is not enough for data science. Real data science is not a single question answered by a single model response. It is a sequence of choices: load this file, inspect these columns, define this metric, split the data this way, train this baseline, handle this error, explain this plot, revise the next step.

CEDAR, short for Context Engineering for Data Science with Agent Routing, starts from that less glamorous reality.¹ The paper does not claim to invent a superhuman autonomous data scientist. Good. We have enough machines wearing oversized job titles already. Its more useful claim is architectural: if LLMs are going to help with data science, the important layer is not just the prompt. It is the system that decides what information enters the prompt, what code is executed outside the model, how intermediate outputs are summarized, and how a human can inspect the workflow.

That is why CEDAR is worth reading as a mechanism paper, not as another “AI replaces analysts” story. Its value lies in how several engineering choices work together: structured requirements, interleaved plan-and-code blocks, agent routing, schema-constrained tool calls, local code execution, iterative code repair, and compact history rendering.

The slogan version is simple: do not prompt harder. Engineer the workflow.

CEDAR treats data science as a notebook, not a chat

The paper’s core move is to reject the idea that data science should be squeezed into one conversational exchange. Instead, CEDAR materializes the solution as a notebook-like sequence of numbered steps. Each step contains a natural-language plan and a corresponding Python code block.

This sounds ordinary until you compare it with the usual chat-based pattern. In a chat interface, the model often blends explanation, code, assumptions, and results into one flowing answer. That may be convenient for a toy problem, but it creates a serious inspection problem. When the final result looks wrong, the user must reconstruct where the workflow drifted: Was the data loaded incorrectly? Was the metric misunderstood? Did the model invent a column? Did a plotting step silently ignore missing values? Welcome to the glamorous world of debugging prose.

CEDAR’s plan-code separation gives the user a more inspectable object. The plan explains the intent. The code performs the computation. The output shows what happened. The next step can then respond to the actual state of the workflow rather than to an imagined one.

This design matters because data science contains two very different kinds of labor. One is interpretive: framing the task, explaining the method, choosing metrics, and describing results. The other is computational: reading files, transforming data, fitting models, calculating scores, and creating plots. LLMs are useful for the first category and unreliable when asked to perform the second category purely in text. CEDAR’s architecture quietly acknowledges that boundary.

The model should not “think” its way through arithmetic. It should write code and let Python do the arithmetic. Radical, I know.

The structured prompt is a requirements document in disguise

CEDAR begins with a structured form rather than a free-form prompt. The form separates general instructions from task-specific instructions. General instructions include items such as the expected number of solution steps, desired verbosity, and expected number of plots. Task-specific fields include the task description, data description, data location, metrics, inputs, outputs, and special instructions.

This is not just interface polish. It is requirements engineering.

Many failed AI data workflows do not fail because the model is “dumb.” They fail because the instruction is underspecified. A human says “predict churn,” but the model needs to know what counts as churn, which column is the label, what metric matters, whether leakage-prone columns should be excluded, whether interpretability matters more than accuracy, and what output format is expected.

A structured prompt reduces ambiguity before the LLM enters the loop. It also makes the user’s intent visible to the rest of the system. That matters because CEDAR’s later agents all receive the project summary and the history of generated blocks. The system is not merely reacting to the latest message; it is working against a compact specification of the data science task.

For business users, this is one of the most transferable lessons in the paper. The practical bottleneck in AI automation is often not model access. It is the absence of structured intent. A workflow that asks for task, data, metric, input, output, and special constraints is less sexy than a blank chat box. It is also much harder to misuse.

Agent routing separates “what to say” from “what to run”

CEDAR uses three LLM agents: a main orchestrator, a text agent, and a code agent. The orchestrator decides what should happen next. It can request a text block, request a code block, or finish the workflow. The text agent writes Markdown explanations. The code agent writes executable Python code.

The interesting detail is not merely that CEDAR has “multiple agents.” That phrase has become cheap. The important part is that the agents have different roles and are invoked through structured outputs. The orchestrator is not allowed to emit arbitrary prose that the application must later parse with crossed fingers. It produces schema-constrained JSON actions such as request_text, request_code, or finish.

The paper is careful about the distinction between the fields used for these calls. A text request uses a “spec,” because the downstream task is explanatory: describe, summarize, discuss, or frame something. A code request uses a “purpose,” because the downstream task is operational: load data, train a model, compute a metric, generate a plot.

That distinction is small but important. In an agentic workflow, vague internal messages become failure multipliers. If an orchestrator says “handle evaluation,” one agent may write a paragraph while another writes code. If the route explicitly says “request_code” with a concrete purpose, the system has fewer ways to misunderstand itself.

The business translation is straightforward: agent architecture needs role discipline. Calling everything an “agent” does not create a system. A system requires boundaries: who decides, who writes, who executes, who checks, and who stops.

Local execution is the privacy feature, not a side note

CEDAR’s code runs locally. Data is not uploaded wholesale into the LLM context. Python operates on local files, while only snapshots, aggregate statistics, instructions, outputs, and error traces are rendered into the model’s context. The paper also notes support for on-premise LLMs, so even those digests need not leave the user’s environment.

This is one of CEDAR’s clearest enterprise implications.

A cloud-only “upload your data and ask questions” workflow has obvious limits. Large files may exceed upload limits. Sensitive datasets may violate internal governance rules. Network transfer may be slow. More importantly, the organization may not want raw enterprise data leaving its controlled environment just because someone wants a scatterplot.

CEDAR’s pattern is more defensible: keep the data local, execute locally, expose only the minimum useful context to the LLM. This is not perfect privacy. Summaries can still leak information if poorly designed, and local execution does not automatically solve access control, audit logging, or model governance. But it is a materially different architecture from sending the full dataset into a remote conversational system.

The paper also describes Docker-based code execution, with containerized runtime environments and the possibility of restricting network access. That matters because generated code is not automatically safe code. If a system asks an LLM to write Python and then executes it, isolation is not a luxury. It is the seatbelt.

History rendering is where context engineering becomes real

The most useful part of CEDAR is not the agent diagram. It is the history rendering logic.

As the workflow grows, the system accumulates instructions, text blocks, code blocks, outputs, and error traces. A naive system might simply paste all of that into the next model call. That creates the familiar context problem: too many tokens, too much noise, and not enough signal. The model receives a landfill and is expected to find the useful scraps.

CEDAR instead renders history selectively. The paper describes several rules:

This is context engineering in the practical sense. Not “write a better prompt.” Not “add a system message with 14 adjectives.” Actual context engineering means deciding what the model should see, what it should not see, and how the visible state should be formatted.

The error-trace rule is especially sensible. Full tracebacks can be long and noisy. The tail often contains the actual exception and the most relevant line. For iterative code repair, that is usually the piece the code agent needs. Including the entire traceback is often less helpful than including the diagnostic ending.

The same logic applies to outputs. A full dataframe dump is rarely useful. The first rows, column names, shapes, and aggregate snapshots are usually more valuable. CEDAR’s history rendering turns the notebook history into a compressed working memory for the next agent call.

For business systems, this may be the paper’s most important exportable idea. The value of an AI workflow often depends less on the raw context window and more on whether the application knows how to curate state.

The demonstration supports viability, not superiority

CEDAR is demonstrated on canonical Kaggle-style tasks, including a competition involving LLM response classification. The application allows users to select models for the orchestrator, text generator, and code generator; provide structured instructions; inspect generated steps; run the workflow step by step or in autorun mode; and export results as JSON, Markdown, or Jupyter notebooks.

The paper also describes practical implementation details: a pure Python backend, a Streamlit frontend, generated artifacts stored in an assets directory, debug logs, plots, metrics, model cards, and the ability to import a saved JSON run and continue from a previous state. It supports GPT-4o through API use and Qwen3-Coder 30B through local hosting via Ollama, with Qwen3-Coder selected as an alternative because it is tuned for agentic coding.

These details are useful because they show that CEDAR is not just a conceptual architecture. It is an implemented application with a concrete user workflow.

But the demonstration should be interpreted carefully.

This distinction matters because readers may overread the paper. CEDAR is not presented as a benchmark-winning data scientist. It is a local-first, inspectable agentic workflow for automating beginner-level data science tasks under clear requirements and well-defined data.

That is already useful. It just is not magic.

The business value is workflow control, not “AI does data science”

The weakest interpretation of CEDAR is: “LLMs can automate data science.” That is both too broad and too familiar.

The stronger interpretation is: CEDAR shows an architecture for controlling AI-assisted analytical work. The model is embedded inside a workflow that constrains input, separates roles, executes code locally, repairs errors iteratively, and renders history compactly.

That architecture has several business implications.

First, structured task intake becomes a productivity tool. Many internal analytics requests fail because the requester does not specify the target metric, output format, or data constraints. A CEDAR-like interface forces those details into the workflow at the start.

Second, local execution reduces friction for private data. Organizations may be more willing to experiment with AI-assisted analysis if raw data remains in local storage and only controlled summaries enter LLM prompts.

Third, notebook-like outputs improve reviewability. A manager, analyst, or data scientist can inspect the plan, code, outputs, and artifacts rather than receiving a single opaque answer.

Fourth, agent routing creates operational clarity. The text agent explains. The code agent executes. The orchestrator routes. When something fails, the failure has a location.

Finally, history rendering turns context from an accident into an engineered resource. That is important for any enterprise AI system that must operate over multi-step workflows, not just data science.

Here is the more general pattern:

The ROI story is not “replace the data science team.” That would be the lazy headline. The better ROI story is reducing the cost of routine analytical setup, boilerplate coding, and first-pass workflow construction, while shifting human attention toward specification, validation, and interpretation.

In other words, the human does less typing and more judgment. A tragic outcome only for people who believed typing was the job.

CEDAR still needs stronger evaluation before enterprise claims become serious

The paper’s boundaries are clear enough if read carefully.

CEDAR focuses on context engineering and demonstrates viability on beginner-level data science tasks. It does not establish that the system consistently outperforms existing DS agents, human analysts, or carefully designed notebooks across diverse enterprise workloads. It also does not provide a large benchmark study isolating the contribution of each component.

That means we should treat the paper as an architectural demonstration, not a final empirical verdict.

Several open questions remain.

How well does CEDAR handle messy enterprise schemas where the data description is incomplete or wrong? How often does the generated workflow make subtle statistical mistakes that do not trigger code errors? Can the system detect when the chosen metric is inappropriate? How should it handle domain-specific constraints in finance, healthcare, logistics, or compliance-heavy analytics? What should the review layer look like when the user is not qualified to judge the generated analysis?

The authors themselves point toward natural next steps: independent agents that inspect solution faithfulness against the original intent and critique generated workflows to improve target metrics. That direction is important. Once an AI system can generate a plausible notebook, the next bottleneck is not generation. It is verification.

This is where businesses should be cautious in a precise way. The risk is not that CEDAR is useless. The risk is using a CEDAR-like system as if an inspectable workflow automatically equals a correct workflow.

It does not. A wrong analysis can still be beautifully formatted.

The lesson: the prompt is not the product

CEDAR’s most useful message is that AI-assisted data science should be treated as systems engineering. The model is one component. The surrounding architecture decides whether the workflow is transparent, auditable, repairable, and safe enough to use.

The paper’s contribution is therefore not a single algorithmic trick. It is a practical composition of mechanisms:

• structured requirements instead of vague prompting;
• notebook-style plan-and-code generation instead of one-shot answers;
• separate agents for routing, explanation, and coding;
• schema-constrained tool calls instead of free-form orchestration;
• local execution instead of uploading all data into a model context;
• iterative code repair instead of brittle single-pass generation;
• compact history rendering instead of context dumping.

None of these ideas is individually mystical. That is precisely the point. Useful AI systems are often built from unglamorous constraints arranged carefully.

For Cognaptus readers, the business takeaway is simple: if you are building AI for analytical work, stop asking whether the model can “act like a data scientist.” Ask whether your system can preserve task intent, run computations safely, expose intermediate reasoning, repair routine errors, and keep the right context visible at the right time.

Because the future of AI data science will not be won by the longest prompt.

It will be won by the cleanest pipeline.

Cognaptus: Automate the Present, Incubate the Future.