2026 usrse duct poster

[asmacdo]

• Fixes: US RSE 2026: con/duct poster cierge#16
  How con/duct can help development and research, especially when working with AI.

[leej3]

I feel it sells too hard. I am immediately curious how it compares to tools with overlapping functionality, across the spectrum from lightweight command history and measurement (history, Atuin, time, script, psrecord), through scheduler and experiment accounting (sacct, MLflow, Sacred, Weights & Biases), to heavier provenance and workflow systems (DataLad, ReproZip, noWorkflow, Snakemake, Nextflow). My pitch would be that con/duct occupies a lightweight middle ground between shell history and a full workflow or experiment-tracking system. Pointing out its position on that spectrum would help people understand the effort/value payoff. For example:

Unlike shell history, con/duct retains output and a sampled resource timeline; unlike scheduler accounting and workflow trackers, it can be applied consistently to an ad hoc local command; unlike deeper provenance systems, it produces a small, human-readable execution record.

Some claims may be a bit too strong... AI thoughts on this below in case it is helpful:

• Shell pipelines do not run unchanged as duct . The implementation uses subprocess.Popen() without a shell, so a pipeline requires something like duct sh -c 'a | b'.

• “Every wrapped run leaves a complete trace” and “lists every failure” conflict with the default --fail-time 3.0, which removes the logs for commands that fail in under three seconds.

• Monitoring is based on a POSIX session and periodic ps sampling, rather than an unconditional capture of the entire process tree. Detached descendants and resource spikes between samples can be missed.

• The SLURM-sizing story should acknowledge that sacct already provides scheduler-native resource accounting. Con/duct’s value there may be its immediate, portable timeline and association with stdout/stderr, as a complement to scheduler accounting rather than a replacement.

• Since the title emphasizes “agent-friendly,” it would help to show what is specifically agent-oriented. At present this appears to be a useful convention—agents wrap and later query commands—rather than a dedicated agent integration.

[asmacdo]

@leej3 Thanks for the review!

I think the "middleground between shell history and workflow systems" is the right balance, I've adapted that and added.
For the other limitations, I've only softened the language. Earlier drafts had exceptions and limitations spelled out, but it was too much for an abstract. (I have some explicit limitations that I'll include for the poster since I'll have more room)

I agree that it was selling too hard, do you think my softening does enough?