A local-first notebook for AI workflows that need an execution trail

Discussions
1

I have been working on a small local-first tool for the part of AI-assisted work that does not fit cleanly in chat or in code.

The pain point: after a few model calls, file references, rewrites, and generated artifacts, it becomes hard to answer “what exactly produced this result?”

The shape I am testing is a notebook where each AI step is a cell. A cell can keep the task text together with:

  • model/provider routing
  • constraints
  • references to previous cells
  • expected file/text/image outputs
  • artifacts that can be inspected later

I am experimenting with a syntax for this called ICC DSL (Intent-Cell Coding). Tiny example:

c1 Draft
> openai.max
@file -markdown draft.md

c2 Review
> claude.max
%from c1
@file -json issues.json

c3 Patch
> openai.fast
%file.c2:issues.json
@file -diff patch.diff

I am mostly looking for feedback on the workflow model: would you want this kind of AI work trail as a notebook, or would you rather keep it inside editor state, scripts, agent logs, or orchestration code?

The thing I am trying to understand is where people expect reproducibility to live once AI work becomes more than a single chat turn.

5

Hey @Levitan-factory!

It’s definitely an interesting problem to solve. Just as perhaps an interesting point of reference, we worked on defining Cursor Trace earlier this year to try and standardized what tracking AI-generated code might look like

6

Thanks, this is very relevant.

I read through the Agent Trace RFC. The file/range attribution model, VCS revision, model identifier, content hash, and vendor-specific metadata fields are close to the kind of separation I am trying to reason about.

The main difference is probably scope:

  • Agent Trace seems focused on attribution for AI-generated code in a version-controlled codebase.
  • ICC DSL is closer to an authoring surface for the workflow before/during execution: routing, constraints, upstream cell references, and output artifact contracts.

But I can see a useful bridge between them.

For code-producing cells, an ICC run could emit or link to Agent Trace records for the actual file/range attribution, while ICC keeps the higher-level workflow lineage:

  • which cell definition ran
  • which upstream artifact it consumed
  • which model route was requested
  • which output artifact was produced
  • which verifier/branch decision followed

So Agent Trace could answer “which AI conversation/model contributed to these code ranges?”, while the notebook/run manifest answers “which workflow step produced the artifact that led to this code change?”

One question: do you see Agent Trace as intentionally code-attribution-only, or would you expect adjacent tools to use its metadata/related-resource model for pre-code artifacts too, like specs, review JSON, diffs, or generated docs?

7

Linked Resources could be home to this information!

8

Thanks, that makes sense. I had missed that related is attached at the conversation level, not only as generic top-level metadata.

That may actually be the clean boundary I was looking for.

The way I would map it from the ICC side is:

  • ICC run manifest keeps the workflow-level lineage:

    • cell id / run id
    • requested route
    • resolved inputs
    • upstream cell/artifact bindings
    • output artifact ids
    • verifier / branch result

  • Agent Trace keeps the code-level attribution:

    • repository revision
    • file path
    • line ranges
    • model/conversation attribution
    • content hashes

Then a code-producing ICC cell could emit Agent Trace for the concrete file/range attribution, and the Agent Trace related array could point back to the ICC run manifest or artifact that produced the code change.

Something like:

{
  "type": "icc-run-manifest",
  "url": "icc://runs/run_123"
}

or in an exported/local bundle:

{
  "type": "artifact",
  "url": "manifest/run_manifest.json#run_123"
}

That would let Agent Trace stay focused on code attribution, while ICC keeps the pre-code workflow state: specs, review JSON, diffs, generated docs, and the decisions that led to the code.

One follow-up question: do you expect related.type to remain intentionally free-form, or would it be useful for the ecosystem to converge on a few common types like artifact, run-manifest, eval, spec, or session?

9

No strong opinion there!

To be honest, I’m just here to let you know that Agent Trace exists. If you’d like to contribute, there is a GitHub repo here! GitHub - cursor/agent-trace: A standard format for tracing AI-generated code. · GitHub