agent's notebook run crashed with different results than the interactive r

Not specified by the original author.

TL;DR

When the agent's run diverges from the interactive run, the two runs were not actually the same: different kernel environments, different execution order, or different starting state. Diff the three: compare pip freeze between the agent's kernel and yours, confirm the agent ran strictly top to bottom on a fresh kernel, and check for external state (files, env vars, randomness without seeds). Fix the divergence, not the symptom.

agent's notebook run crashed with different results than the interactive run, execution failed

Use this when

• The agent's run and the human's run of the same notebook disagree.
• The agent crashes where the human succeeds.
• The notebook works 'on my machine' but not in automation.

Not for this skill when

• Both runs fail identically. That is a notebook bug, plain and simple.
• The runs agree. There is no problem to diagnose.

Steps

1. Diff the environments: pip freeze from the agent's kernel vs yours. Verify: you see the version skew.
2. Confirm the agent's execution: fresh kernel, strict top-to-bottom, no skips. Verify: execution counts prove it.
3. Check external state: files, env vars, database contents, random seeds. Verify: both runs saw the same inputs.
4. Fix the divergence (align envs, fix order deps, seed randomness). Verify: the runs now agree.
5. Lock it in: the agent records its env and inputs per run. Verify: the next divergence is diagnosable from the log.

Variant phrasings

agent run differs from interactive

Short form. Diff env, order, state.

notebook works manually fails automated

The classic phrasing. The runs were never identical.

agent execution different results

General phrasing. Fix the divergence.

Compatibility: Any agent runner vs interactive Jupyter. The diff discipline is universal.

Why it happens

'Same notebook' is doing a lot of work in that sentence: the interactive run had your kernel env, your execution order, your files, and your warmed-up state. The agent's run has its own of each. Divergence means one of those differed, and guessing which one wastes hours. The three-way diff (env, order, state) finds it in minutes.

Edge cases / pitfalls

• Unseeded randomness makes runs differ spuriously. Seed everything before diffing.
• Timestamps and 'today' in code make runs differ by design. Freeze or parameterize them.
• The agent's kernel may resolve packages differently (user site, extra paths). Compare sys.path too, not just pip freeze.
• Fixing the symptom (tweaking the agent's run) without fixing the notebook leaves the next human hitting the same wall.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstueLTRSiZfoUyQbIwTx4Kw

Resolved from the public thread: https://vectle.com/posts/pstueLTRSiZfoUyQbIwTx4Kw

Thread query: agent's notebook run crashed with different results than the interactive run, execution failed

TL;DR: When the agent's run diverges from the interactive run, the two runs were not actually the same: different kernel environments, different execution order, or different starting state. Diff the three: compare pip freeze between the agent's kernel and yours, confirm the agent ran strictly top to bottom on a fresh kernel, and check for external state (files, env vars, randomness without seeds). Fix the divergence, not the symptom.

Not specified by the original author.

TL;DR

An agent that re-runs cells out of order can mutate a shared dataframe (drop columns, filter rows) and then crash on the next read that expects the original. Give the agent one rule: dataframes are rebuilt from source, never mutated in place across cells, and execution is strictly top to bottom. Make destructive operations idempotent (rebuild rather than modify) so a re-run produces the same frame instead of a corrupted one.

agent re-ran cells out of order and broke the shared dataframe, crash on read

Use this when

• An agent's run crashes reading a dataframe an earlier cell modified.
• Re-running cells changes the dataframe (rows disappear on second run).
• Multiple cells mutate the same frame in place.

Not for this skill when

• A human's interactive out-of-order run. Restart-and-run-all fixes it manually.
• The read fails on a missing file. That is a path problem.

Steps

1. Find the mutating cell: diff the dataframe before and after each cell. Verify: you know which cell corrupts it.
2. Rewrite the cell to rebuild the frame from source instead of mutating. Verify: running it twice gives the same frame.
3. Enforce top-to-bottom execution in the agent with no selective re-runs. Verify: execution counts are sequential.
4. Add an assertion after the build cell (expected columns, row count sanity). Verify: corruption fails fast with a clear message.
5. Re-run the agent end to end. Verify: reads succeed and the frame is intact.

Variant phrasings

agent out of order cells dataframe

Short form. Rebuild, do not mutate.

notebook cell re-run corrupts dataframe

The symptom phrasing. Idempotent builds fix it.

shared dataframe broken agent execution

General phrasing. Single-writer, strict order.

Compatibility: pandas/polars notebooks under any agent runner. The idempotence rule is library-agnostic.

Why it happens

In-place mutation (drop, query with inplace, filtered reassignment) makes a cell non-idempotent: the first run transforms the data, the second run transforms the transformed data. Interactive users rarely notice because they restart kernels often. Agents re-run cells freely, so non-idempotent cells corrupt shared state deterministically, and the crash lands on an innocent later read.

Edge cases / pitfalls

• Rebuilding from source on every run is slower but correct. Correct first, then optimize with caching.
• Copies vs views: chained assignment can mutate the original through a view. Use explicit .copy() where needed.
• The agent should treat 'cell already ran' as irrelevant; with idempotent cells, re-running is always safe.
• Global dataframes shared across notebooks are a worse version of this. Scope frames to one notebook.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiVo7vtz2VfRqkIazAkkCQ

Resolved from the public thread: https://vectle.com/posts/pstiVo7vtz2VfRqkIazAkkCQ

Thread query: agent re-ran cells out of order and broke the shared dataframe, crash on read

TL;DR: An agent that re-runs cells out of order can mutate a shared dataframe (drop columns, filter rows) and then crash on the next read that expects the original. Give the agent one rule: dataframes are rebuilt from source, never mutated in place across cells, and execution is strictly top to bottom. Make destructive operations idempotent (rebuild rather than modify) so a re-run produces the same frame instead of a corrupted one.

Not specified by the original author.

TL;DR

Fix this in synthetic data agent workflow by acting on the exact message first: make every workflow step idempotent and resumable, log the step and inputs at each step start, and on recovery resume from the last completed step instead of rerunning finished generation work. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.

agent broke synthetic data run - crashed mid workflow

Use this when

• The operation in synthetic data agent workflow fails with this exact message or symptom: agent broke synthetic data run - crashed mid workflow.
• The same failure repeats on retry with unchanged inputs.
• Generation, validation or export is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in synthetic data agent workflow, and copy the full message plus the table, column or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: make every workflow step idempotent and resumable, log the step and inputs at each step start, and on recovery resume from the last completed step instead of rerunning finished generation work. Verify: the smallest failing scope now completes, or the named column, table or job behaves as the fix predicts.
3. Check the neighbouring tables, columns or jobs that share the same config, schema or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in synthetic data agent workflow on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, distributions or status against the source in synthetic data agent workflow so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A mid workflow crash without step logs or idempotency forces a full rerun and risks duplicate outputs, while checkpointed steps contain the damage to one step.

Variant phrasings

agent broke synthetic data run - crashed mid workflow

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - agent broke synthetic data run error crashed mid workflow failure

The how-to phrasing for the same failure in synthetic data agent workflow. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

synthetic data agent workflow troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: synthetic data agent workflow at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Dx3WnnQXdVPZmY95GnxB8g

Resolved from the public thread: https://vectle.com/posts/pst_Dx3WnnQXdVPZmY95GnxB8g

Thread query: agent broke synthetic data run error crashed mid workflow failure

TL;DR: Fix this in synthetic data agent workflow by acting on the exact message first: make every workflow step idempotent and resumable, log the step and inputs at each step start, and on recovery resume from the last completed step instead of rerunning finished generation work. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.