N O N - R E S E A R C H T I P S F O R R E S E A R C H E R S ( S U M M E R 2 0 2 6 ) Portable & Reproducible Research Environments in the Age of AI Agents Mai Nishimura | Senior Researcher | OMRON SINIC X 1 

S P E A K E R Mai Nishimura R E C E N T W O R K ACL '26 Main Agentic RAG × SLMs SLM · RL · Distillation RA-L Tactile Memory Retrieval Tactile Sensing · Representation Learning IROS '26 Retrieval-Augmented Training Tactile Sensing · Imitation Learning R. Kotoge, M. Nishimura, J. Ma — “Can Compact Language Models Search Like Agents? Distillation-Guided Policy Optimization for Preserving Agentic RAG Capabilities”, ACL Main, 2026 T.Kamijo, M.Nishimura, N.Shibasaki, J.Siburian, Cristian C.Beltran-Hernandez, M.Hamaya – “Tactile Memory with Soft Robot: Robust Object Insertion via Masked Encoding and Soft Wrist”, Robotics and Automation Letters (RA-L), 2026 J.Sibuian, Cristian C.Beltran-Hernandez, T.Matsushima, Y.Iwasawa, M.Hamaya, M.Nishimura – “PHASE: Compliance-Enabled Tactile Phase Retrieval for Few-Shot Insertion Learning”, IROS, 2026 • Working on database × AI × robotics • Parenting 2-year-old identical twins OMRON SINIC X | Senior Researcher JST PRESTO PI (Oct 2025 – current) "Autonomous Memory Systems for AI and Robotics" https://denkiwakame.github.io/ 2 

S P E A K E R Mai Nishimura • Working on database × AI × robotics • Parenting 2-year-old identical twins R E C E N T W O R K ACL '26 Main Agentic RAG × SLMs SLM · RL · Distillation RA-L Tactile Memory Retrieval Tactile Sensing · Representation Learning IROS '26 Retrieval-Augmented Training Tactile Sensing · Imitation Learning R. Kotoge, M. Nishimura, J. Ma — “Can Compact Language Models Search Like Agents? Distillation-Guided Policy Optimization for Preserving Agentic RAG Capabilities”, ACL Main, 2026 T.Kamijo, M.Nishimura, N.Shibasaki, J.Siburian, Cristian C.Beltran-Hernandez, M.Hamaya – “Tactile Memory with Soft Robot: Robust Object Insertion via Masked Encoding and Soft Wrist”, Robotics and Automation Letters (RA-L), 2026 J.Sibuian, Cristian C.Beltran-Hernandez, T.Matsushima, Y.Iwasawa, M.Hamaya, M.Nishimura – “PHASE: Compliance-Enabled Tactile Phase Retrieval for Few-Shot Insertion Learning”, IROS, 2026 All powered by Pixi OMRON SINIC X | Senior Researcher JST PRESTO PI (Oct 2025 – current) "Autonomous Memory Systems for AI and Robotics" https://denkiwakame.github.io/ 3 

A G E N D A Portable & Reproducible Research Environments P A R T I Packaging & Portability • How research environments changed • pip / conda → uv or pixi • Declarative, locked, cross-platform • pixi in practice: ROS, SLAM, faiss, Nerfstudio Introduction to Pixi P A R T II The Age of AI Agents • AI coding & the changing dev loop • pixi as a disposable agent environment • Sandboxes: the isolation spectrum • Portability via HF storage / cloud · ethics Hand the pueue jobs to an agent 4 

P A R T I Packaging & Portability From local hacks to declarative, cross-platform environments. Portable & Reproducible Research Environments 5 

A F A M I L I A R S T O R Y We've all been here You join a lab. “Reproduce prior work”. they say. First — set up the environment. Prior work says: just install this one package. bash $ pip install slam-toolkit Building wheel for slam-toolkit (setup.py) ... error: Failed building wheel for slam-toolkit Running setup.py clean for slam-toolkit Failed to build slam-toolkit How hard could it be? 

A F A M I L I A R S T O R Y “Just google the error” “Ask GPT” A senior nods knowingly: “Just google it.” You paste the error, open the top result, and try again. bash # googled → “try --no-build-isolation” $ pip install slam-toolkit --no-build-isolation fatal error: Eigen/Core: No such file or directory # googled → “install it with apt” $ sudo apt-get install libeigen3-dev E: Could not get lock /var/lib/dpkg/lock (no sudo) Different command. Different error. 

A F A M I L I A R S T O R Y “Just use conda” Another search. Another forum thread. “conda will fix it.” So you start over, again. bash $ conda install -c conda-forge slam-toolkit Solving environment: failed with initial frozen solve. Retrying with flexible solve ... $ pip install some-other-dep ERROR: pip's resolver does not account for all installed packages — inconsistent environment $ python -c “import slam_toolkit” Segmentation fault (core dumped) Now conda and pip are at war — and you're the battlefield. 

A F A M I L I A R S T O R Y “Just use Docker” “Containers fix everything,” someone promises. You build a Docker image # Dockerfile FROM base:latest not pinned RUN curl -LsSf astral.sh/uv | sh RUN uv pip install torch open3d no versions RUN apt-get install -y libgl1 ... bash $ docker build -t mywork . => ERROR: failed to solve ...fix, retry, fix, retry... 2 hours later: it builds — on a newer base image than last month's. A Dockerfile — and it still doesn't reproduce. (and builds take hours ) 

A F A M I L I A R S T O R Y · T H E E N D And a week passed ·················· John quit robotics research. … or, there's a version of this story where you don't quit. That's today. Portable & Reproducible Research Environments 

S O . . . W H Y D O E S T H I S K E E P H A P P E N I N G ? Why it sucks 1 conda + pip don't mix. Two package managers fighting over one environment. 2 Installs are imperative — a list of steps. The result depends on when and where you run them. 3 So every run yields a different environment. Nothing is pinned; nothing is recorded; nothing is reproducible. Reproducibility isn't just about the paper. it starts the moment you build the environment. 

W H Y R E P R O D U C I B I L I T Y & P O R T A B I L I T Y M A T T E R S N O W The research environment has changed GPUs are mandatory CUDA / driver / ABI matching turns setup into a minefield. Cloud-first Work moves between laptop, cluster, and rented GPUs. Distributed environment Many nodes must run the exact same stack. AI agents in the loop Agents now build and run environments themselves. 12 

T H E C O R E C L A I M A single local machine can no longer hold a research environment together. Research stack in 2015 Research stack in 2025 GPU cluster Local machines Cloud Agents CPU: Intel | AMD |ARM | Apple Silicon GPU: NVIDIA | AMD | Intel CODE / TOOLS: Python | C++ | CUDA | Rust, etc. 13 

T H E S E T U P T A X Now you pay for setup again and again ANC I ENT M EM O R I ES· O N E M A CHI NE , SE TUP O N L Y O N C E ▼ new machine launches setup exp (never setup again) 14 

T H E S E T U P T A X Now you pay for setup again and again ANC I ENT M EM O R I ES· O N E M A CHI NE , SE TUP O N L Y O N C E ▼ new machine launches NO W · EXP ER I M E N TS A N YW HE RE ▼ local machine setup exp ▼ scale up → cloud A setup exp ▼ scale up → cloud B setup exp PA RALL EL R U N S B Y A I A G E NTS ▼ new agent spawns in cloud setup exp ▼ new git worktree spawns setup exp exp Every machine, cloud, agent and worktree pays the setup cost — so make | setup | as fast as possible. setup exp (never setup again) 15 

A S H O R T H I S T O R Y Python packaging, briefly 01 pip + venv PyPI wheels. No system libs, no lockfile by default. 02 conda Solves binary / non- Python deps. Slower solves. 03 poetry Real resolution & lockfiles — but PyPI- only. 04 uv Rust-fast pip/venv. Brilliant for pure- Python. 05 pixi conda + PyPI, multi- platform lock, tasks, envs. Acquired by OpenAI 2026.03.19 Use “uv” as PyPI backend blazing fast blazing fast 16 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility Multi-language HW Acceleration (GPU) Setup simplicity Cross-platform Learning curve System deps ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 17 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility ✕ Multi-language ● HW Acceleration (GPU) ●●● Setup simplicity ● Cross-platform ●●● Learning curve ●●● System deps ✕ ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 18 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility ✕ ✕ Multi-language ●● ● HW Acceleration (GPU) ●●● ●●● Setup simplicity ● ● Cross-platform ●●● ●●● Learning curve ●● ●●● System deps ●●● ✕ ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 19 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility ●● ✕ ✕ Multi-language ● ●● ● HW Acceleration (GPU) ●●● ●●● ●●● Setup simplicity ●●● ● ● Cross-platform ●●● ●●● ●●● Learning curve ●●● ●● ●●● System deps ✕ ●●● ✕ ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 better pip + lockfile w/ caching & parallel DL & faster solver 20 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility ●● ●● ✕ ✕ Multi-language ●● ● ●● ● HW Acceleration (GPU) ●● ●●● ●●● ●●● Setup simplicity ✕ ●●● ● ● Cross-platform ● ●●● ●●● ●●● Learning curve ✕ ●●● ●● ●●● System deps ●● ✕ ●●● ✕ ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 uv + Docker required To manage non-python dependency 21 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility ●● ●● ✕ ✕ ●●● Multi-language ●● ● ●● ● ●●● HW Acceleration (GPU) ●● ●●● ●●● ●●● ●● Setup simplicity ✕ ●●● ● ● ● Cross-platform ● ●●● ●●● ●●● ● Learning curve ✕ ●●● ●● ●●● ✕ System deps ●● ✕ ●●● ✕ ●●● ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 Purely-functional Package manager 22 

P O S I T I O N I N G Package managers, side by side Capability pixi Docker uv conda / mamba pip Nix Reproducibility ●●● ●● ●● ✕ ✕ ●●● Multi-language ●●● ●● ● ●● ● ●●● HW Acceleration (GPU) ●●● ●● ●●● ●●● ●●● ●● Setup simplicity ●●● ✕ ●●● ● ● ● Cross-platform ●●● ● ●●● ●●● ●●● ● Learning curve ●●● ✕ ●●● ●● ●●● ✕ System deps ●●● ●● ✕ ●●● ✕ ●●● ●●● Excellent ●● Good ● Basic ✕ Limited / Poor Pixi: Unified Software Development and Distribution for Robotics and AI https://arxiv.org/abs/2511.04827 "Reasonable" choice for lab-use 23 

A S H O R T H I S T O R Y Why packaging split — and how pixi reunites it • ~2012: scientific Python needed C / Fortran / CUDA libraries pip couldn't manage. • The ecosystem split in two: • PyPI (wheel → poetry → uv) • conda (conda-forge → mamba → pixi). • Both sides reinvented the same ideas — binary distributions, lockfiles, fast solvers. • pixi sits on the conda side but speaks PyPI too — bridging both worlds. Pixi is, in principle, "conda package manager" 24 

P O S I T I O N I N G uv or pixi? Both — for different jobs uv the PyPI world • Pure-Python projects • PyPI packages & wheels • Blazing-fast venvs • Drop-in pip / pip-tools pixi the conda + PyPI world • Supports both PyPI & conda • Multi-lingual (non-python) packages • CUDA, ROS, GDAL, ffmpeg… • Multi-platform lockfile • Task runner • Named environments 25 

T H E P A I N Each ecosystem solves half the problem pip / PyPI • Wheels only — no system libraries • CUDA / MKL pulled in ad-hoc • ABI mismatches across OS & arch • “works on my machine” conda • Ships compiled system deps • Handles CUDA, ROS, GDAL, faiss… • Solves can be slow; channels sprawl • PyPI interop historically awkward pixi wants both halves — locked together. 26 

T H E C O R E C L A I M Pixi is ... project-wise env pixi global OS / linux kernel “a declarative Package manager” ! 28 

M E E T P I X I One file, every platform conda + PyPI Both ecosystems in a single resolve. Lockfile Six targets, one lockfile, identical bytes. Tasks Reproducible, dependency-aware commands. Environments Named, composable envs (cpu / gpu / test). 29 

G E T T I N G S T A R T E D Getting started with pixi bash # 1. install pixi $ curl -fsSL https://pixi.sh/install.sh | sh # 2. start a workspace $ cd /path/to/your/workspace $ pixi init That's the whole setup. Now let's see what it can do. 

P I X I W O R L D · W H Y D E C L A R A T I V E Imperative vs. Declarative Imperative $ apt-get install libgl1 … $ pip install numpy torch $ conda install -c … faiss State lives in the machine — nothing is recorded. Declarative pyproject.toml or pixi.toml [dependencies] python = ">=3.11" numpy = ">=1.26" The file is the spec — versioned, shared, reviewed. A L O NG RO AD T O DE CL ARA TI VE requirements.txt → Pipfile → pyproject / poetry → uv · Bundler ’10 · Cargo ’14 · Yarn ’16 · conda env.yml → pixi.toml · Nix (purely declarative) ─ You write how: the steps to get there. ─ You write the goal: the state you want. Why? So the environment is reproducible. 31 

P I X I W O R L D · W H Y A L O C K F I L E Pin it once, reproduce it anywhere # manifest (intent) numpy = ">=1.26" # a range — resolves # differently over time → # pixi.lock (exact truth) numpy ==1.26.4 sha256:9af… platforms: osx-arm64 · win-64 · linux-64 … # bit-for-bit identical, everywhere • No lockfile → “works on my machine”; some of workflows break within a year (version drift). • A lockfile pins exact versions + hashes for every platform — anyone, any time, the same env. • pixi.lock holds all targets (macOS / Windows / Linux × x86 / arm) in one file. Manifest = intent. Lockfile = the exact, reproducible truth. Manifest (pixi.toml | pyproject.toml) Lockfile (pixi.lock) 32 

W O R K F L O W Edit the manifest, then sync uv (PyPI world) pixi (conda + PyPI) AVOID Environment updates are NOT recorded $ uv pip install numpy $ pixi run pip install numpy ✗ ✗ ADD updates the manifest + lockfile $ uv add numpy $ pixi add numpy --pypi REPRODUCE materialise the exact locked env $ uv sync $ pixi install Never hand-mutate the env — change the file, then sync. $ uv run pip install numpy ✗ 33 

P I X I · T A S K S Declare your tasks, too manual — error-prone # run by hand, every time $ python -m libs.trainer.train ¥ --batch-size 256 ¥ --learning-rate 1e-5 ¥ --weight-decay 1e-4 ¥ --epochs 100 ¥ --optimizer adamw ¥ --num-workers 8 ¥ --seed 42 # someone else / an AI retypes it: $ python -m libs.trainer.train ¥ --use-flash-attn2 ✗ error: unrecognized argument Wrong flags, wrong module path, a missing env var — unreproducible runs. # pixi.toml [tasks] train = "python -m libs.trainer.train --batch-size 256 –-optimizer adamw_sf" bash $ pixi run train # one name — always the right command Tasks are part of the declarative environment — one name, one correct command, for humans and AI. 34 

P I X I · T A S K S Multi-language pipelines with depends-on [tasks] download = "gdown 17CU8H2kCXF5WL4qEdzE5lLO3T3iivLDn ..." train = { cmd = "python –m libs.trainer.train", depends-on = ["download"] } eval = { cmd = "python –m libs.evaluator.eval", depends-on = ["train"] } update-model = { cmd = "hf upload ...", depends-on = ["eval"] } configure = "cmake -G Ninja -S . -B .build" build = { cmd = "ninja -C .build", depends-on = ["configure"] } [dependencies] gdown = "*" bash $ pixi run update-model download → train → eval → upload-model # prerequisites run in order $ pixi run build configure → build • Commands can be any language — python, bash, cargo, npm. One task graph spans every language — prerequisites run in order, on every OS. 35 

U S E C A S E S Use cases pip alone can't reach M U L T I - L I N G U A L D E P S ROS RoboStack + pixi. Open Robotics standardized on pixi for Windows dev — no Docker, no Ubuntu lock-in. SLAM VSLAM-LAB runs many complex envs in one project. faiss GPU build & CUDA pain — solved by conda-forge + lock. Nerfstudio tiny-cuda-nn / CUDA toolchain hell, made reproducible. 36 

U S E C A S E S ROS: one workflow, every platform bash $ pixi init –c https://prefix.dev/robostack-humble -c conda-forge ~/lecture-ros via v0.70.2 on (ap-northeast-1) $ pixi add ros-humble-desktop Added ros-humble-desktop >=0.10.0,<0.11 $ pixi run rviz2 Everything is in your $PROJECT_ROOT/.pixi You can keep your host system clean. Get started with ROS in 5 seconds! ─ without docker 37 

U S E C A S E S pixi-ros: Converting package.xml into pixi envs RoboStack Community conda packages for ROS. pixi consumes them directly. pixi-ros Maps package.xml → pixi.toml — reproducible & cross- platform. No Docker, no lock-in Native hardware & GPU access with Docker-grade reproducibility. bash $ pixi global install pixi-ros $ cd ros_ws $ pixi ros init –distro humble – platform linux-64 –platform osx-arm64 ✓ robostack channel added ✓ deps mapped from package.xml ✓ pixi.toml written (2 platforms) 14 38 

U S E C A S E S 3D Computer Vision w/complex CUDA/C++ deps • VSLAM-LAB https://github.com/VSLAM-LAB/VSLAM-LAB • Nerfstudio https://github.com/nerfstudio-project/nerfstudio pixi cuda opengl clang/g++ pytorch colmap 39 

Foundation-model research - multiplies envs Portable & Reproducible Research Environments Agentic RAG model trainer (model family) × retriever (approximate NN search) Robot FMs (VLA) model server (model family) × robot simulator (benchmark) → dependency hell, squared • pixi supports named multiple virtual environments in a single pixi.toml | pyproject.toml. • Stack and manage isolated environments easily — one per model / retriever / simulator / ROS. Each piece keeps its own env; pixi resolves them all into one lockfile. U S E C A S E S faiss-gpu Gr00t π OpenVLA MolmoAct ... × real-robot 40 

T H E C O R E C L A I M Pixi can serve as ... project-wise env pixi global OS / linux kernel “a shell tool manager” ! Rootless 42 

A F A M I L I A R S T O R Y · A G A I N “This tool will make research so much easier!” You find the perfect research tool — the one that does exactly what you need. You just need to install it. How many tools could that possibly take? 

A F A M I L I A R S T O R Y · A G A I N Every tool speaks a different language You follow each README, exactly. One tool at a time. bash # the tool is written in Python $ pyenv install 3.11.9 # the next one is in Go $ asdf install golang 1.22 # and this one is in Rust $ curl https://sh.rustup.rs | sh # …and it's full of low-level dependencies $ sudo apt install libssl-dev libudev-dev ... Four tools, four toolchains — every one installed globally. 

A F A M I L I A R S T O R Y · A G A I N The next day … Your research stopped working. A global toolchain shifted, a system library upgraded — and your own project moved underneath you. Every global install is a bet against your future self. 

A F A M I L I A R S T O R Y · T H E E N D ( A G A I N ) John quit robotics research. What if every toolchain — Python · Go · Rust · Node · apt — lived in one place? Rootless. No clashes. → pixi global Portable & Reproducible Research Environments 

P I X I G L O B A L Pixi global resolves everything. Portable & Reproducible Research Environments What setup used to require installed via apt · nvm · cargo · rustup · … → pixi One manifest, one lockfile — every language's toolchain unified. pixi collapses apt + nvm + cargo + rustup + … into a single declarative file. python pixi global install python==3.14 clang OR with pixi-global.toml, just pixi global sync 47 

P I X I G L O B A L Isolated envs, one-shot updates, declarative manner Portable & Reproducible Research Environments $ pixi global install ¥ --environment neovim --expose nvim ¥ nvim neovim nodejs lua luarocks python [envs.neovim] channels = ["conda-forge"] dependencies = { nvim, neovim, nodejs, python, lua, luarocks } exposed = { nvim = "nvim" } [envs.fzf] channels = ["conda-forge"] dependencies = { fzf = "==0.73.1" } # can pin the version exposed = { fzf = "fzf" } • A dedicated virtual env with neovim's deps bound together. • Only the binaries you choose (nvim) are exposed. $ pixi global update # upgrade every unpinned Environment neovim was already up-to-date. Environment starship was already up-to-date. Updated executable starship of environment starship. Updated environment sheldon. Updated executable sheldon of environment sheldon. Updated environment git. Updated executables of environment git: - git - git-cvsserver - git-receive-pack - git-shell - git-upload- archive - git-upload-pack - gitk - scalar Next: tools worth putting in that toolbox. bash 48 

P I X I G L O B A L · T O O L gh — GitHub, from the terminal Portable & Reproducible Research Environments $ pixi global install gh • GitHub's official CLI: PRs, issues, releases, Actions • Scriptable access to the GitHub API; easy auth for CI and agents. • The natural companion to git for everyday research repos. No more "sudo" and complicated apt setup. github.com/cli/cli 50 

P I X I G L O B A L · T O O L pueue — A queue for your shell commands Portable & Reproducible Research Environments $ pixi global install pueue • Queue long-running jobs • run them sequentially or in parallel. • Pause, resume, reorder, and inspect logs. • Great for stacking jobs in your local machines. github.com/Nukesor/pueue 51 

P I X I G L O B A L · T O O L sshs— terminal user interface for ssh Portable & Reproducible Research Environments $ pixi global install sshs • SSHS uses ~/.ssh/config to list and connect to hosts. github.com/quantumsheep/sshs 52 

P I X I G L O B A L One toolbox — no version managers Portable & Reproducible Research Environments pyenv rbenv cargo nvm goenv … a bit too complex for research use • Each tool gets its own isolated environment — no dependency clashes. • Chosen binaries are exposed on your PATH (trampolines). • Rootless: no sudo, installs into your home — works on any shared machine. • The global manifest (pixi-global.toml) is shareable & version-controllable. pixi global install python=3.13 ruby jekyll gdown pueue diskonaut sshs ghq gwq pixi global manages tools for every language at once. → bash $ pixi global sync pixi-global.toml 53 

E N D O F A C T I pixi made local and global environments both handy. And that turns out to matter — because it's handy for AI agents too. → Part II: The Age of AI Agents Portable & Reproducible Research Environments 54 

P I X I G L O B A L – U S E C A S E nanokit: a whole dev env, rootless Portable & Reproducible Research Environments What it ships (almost nothing) • a shell-tools manifest.toml • minimal ghq / gwq / zoxide configs • a dotfile / symlink manager (dotter-rs) • zsh + sheldon + starship $ ./nanokit install → pixi global sync go · rust · python · nodejs · nvim · dotter zsh · sheldon · starship → dotter deploy # symlinks linked $ ./nanokit uninstall # env reverted $HOME/.pixi · user-local no root doesn't pollute the system · fully reversible All you need is pixi — one rootless, reversible, cross-platform dev env. denkiwakame.github.io/nanokit 55 

P I X I G L O B A L – U S E C A S E nanokit: a whole dev env, rootless Portable & Reproducible Research Environments What it ships (almost nothing) • a shell-tools manifest.toml • minimal ghq / gwq / zoxide configs • a dotfile / symlink manager (dotter-rs) • zsh + sheldon + starship $HOME/.pixi · user-local no root doesn't pollute the system · fully reversible All you need is pixi — one rootless, reversible, cross-platform dev env. denkiwakame.github.io/nanokit Setup any machines / clouds in a few seconds 56 

BREAK Part II resumes after a short pause denkiwakame.github.io/nanokit 57 

P A R T II The Age of AI Agents Disposable environments, sandboxes, and what could go wrong. Portable & Reproducible Research Environments 58 

P A R T I I · T H E S H I F T In Part I, reproducibility was for other people and other machines. In Part II, an AI agent touches the environment — so it must be truly disposable and reproducible. CLI · consistent environments · task-fixed workflows — their true value shows with AI. Portable & Reproducible Research Environments 59 

W H A T C H A N G E D AI coding reshaped the dev loop Portable & Reproducible Research Environments Agents write & run code Claude Code, Codex, Cursor drive the terminal. AI-native terminals Warp & peers blur shell and assistant. Environments are ephemeral Spun up, used, torn down many times a day. Agent-optimized CLIs Tools detect agents & cut token cost sharply. 60 

T H E S H I F T Environments: human era vs AI-agent era Portable & Reproducible Research Environments HUM A N ER A setup work in it — for months build once, live in it A I - AG E NT ER A worktree A s try ✗ s try ✓ worktree B s try ✗ s try ✗ s try ✓ worktree C s try ✓ git worktree → parallel trial-and-error · build, try, throw away, repeat Agents create and destroy environments constantly — disposability becomes the point. 61 

T H E S H I F T Portable & Reproducible Research Environments HUM A N ER A setup work in it — for months build once, live in it A I - AG E NT ER A worktree A s try ✗ s try ✓ worktree B s try ✗ s try ✗ s try ✓ worktree C s try ✓ git worktree → parallel trial-and-error · build, try, throw away, repeat Agents create and destroy environments constantly — disposability becomes the point. Environments: human era vs AI-agent era 62 

P O R T A B L E R U N T I M E Keep state in services, not in the node Portable & Reproducible Research Environments Hugging Face models + datasets Storage Buckets https://huggingface.co/blog/storage-buckets wandb logs + metrics trackio https://huggingface.co/blog/trackio ↓ pull models / data push logs / metrics ↑ local machine pixi env no durable state GPU cluster pixi env no durable state cloud agent pixi env no durable state Any node, any cloud — swap it out and nothing is lost. Nodes are disposable & location-independent; all state lives in services. 63 

S T R U C T U R E D R E P O S I T O R Y T R E E Where did I clone that repo ? Portable & Reproducible Research Environments On a new machine — or someone else's: “Wait… where did I clone that repo?” Your AI agent wonders the exact same thing . • git worktree adds more checked-out sources sharing one .git — repos multiply. • Clones and worktrees pile up until you can't find anything. • ~/code/nanokit • ~/dev/nanokit-2 • ~/tmp/nk • ~/projects/exp-A • ~/repos/old/nk … which one? ghq × gwq solves this Scattered repos are a tax on humans and agents alike. 64 

P I X I G L O B A L · T O O L ghq — one predictable tree, everywhere Portable & Reproducible Research Environments $GHQ_ROOT ├─ github.com │ ├─ your-org/ │ │ ├─ research-A/ │ │ └─ research-B/ │ └─ denkiwakame/ │ │ └─ nanokit/ └─ git.overleaf.com ├─ iros2026 └─ arr2026 bash $ ghq get # clones into the same path, wherever you are $ ghq list # list all ghq-managed repositories • Wherever you are, the repo lands at the same path. • host / owner / repo — derived from the URL, no decisions. • = agents can reference any repo through ghq, too. ghq get resolves any repo into one predictable tree — for you and your agents. $ pixi global install ghq 65 

T H E B R A N C H P R O B L E M Trying many ideas at once? You want to test several improvements. So you branch — a lot. And then you ping-pong between them. bash $ git stash && git checkout idea-A # rebuild, test $ git stash && git checkout idea-B # rebuild, test $ git stash && git checkout idea-C # …wait, which stash was which? # to run two at the SAME time: $ git clone ../repo-copy-2 $ git clone ../repo-copy-3 The result • 3 clones, 6 branches. • Rebuild from scratch on every switch. • No idea which copy holds which idea. Git worktree + gwq is an elegant solution to this wired problem. 

P I X I G L O B A L · T O O L gwq — parallel worktrees, one repo .git shared history & objects ↓ nanokit main · you ↓ nanokit.exp-impl-A agent A ↓ nanokit.exp-impl-B agent B bash $ gwq add exp-impl-A # new worktree, shared .git $ pixi global install gwq bash $ gwq list ┌──────────────────┬───────────────────────────────────────────┐ │ BRANCH │ PATH │ ├──────────────────┼───────────────────────────────────────────┤ │ ● tutorial │ ~/ghq/github.com/denkiwakame/nanokit │ │ exp-impl-A │ ~/ghq/github.com/denkiwakame/nanokit.feat │ │ exp-impl-B │ ~/ghq/github.com/denkiwakame/nanokit.test │ └──────────────────┴───────────────────────────────────────────┘ 67 

P I X I G L O B A L · W O R K F L O W ghq + gwq: a place for every repo & worktree ghq — clones ~/ghq/ └─ github.com/ └─ pytorch/ └─ pytorch/ └─ denkiwakame/ ├─ nanokit/ └─ pixi-lecture/ $ ghq get # predictable path, every repo gwq — worktrees ~/ghq └─ github.com/ └─ denkiwakame ├─ nanokit/ ← main ├─ nanokit.feat-agent-1/ ← agent A ├─ nanokit.feat-agent-2/ ← agent B └─ nanokit.feat-debug / ← parallel run $ gwq add # isolated worktree per task/agent One tidy tree for clones, one for parallel worktrees — agents never collide. $ pixi global install ghq gwq 68 

P I X I G L O B A L · T O O L ghq + gwq + zoxide = zsh # ~/.zshrc — that's the whole config eval "$(zoxide init zsh)" $ cd ~/ghq/.../denkiwakame/nanokit # visit once — zoxide remembers it $ zi nano > nanokit ▸ incremental search → jump • cd once — zoxide remembers the path. • Type zi + a fragment → interactive fuzzy jump. Type a fragment, jump anywhere — your repo tree becomes instant. $ pixi global install zoxide 69 

P A R T I I · R O O T L E S S , C R O S S - P L A T F O R M How far up the stack pixi reaches pixi (local) · project-specific dependencies torch cuda vllm includes python · gcc/clang · CUDA toolkit pixi global · CLI tools for human | AI agent git gh pueue jq OS / linux kernel + GPU driver PIXI COVERS • Everything user-space is pixi's: compilers, CUDA, Python, libraries, CLI tools. • Only the kernel & GPU driver come from the host. • Rootless — and the same on every OS. pixi reaches from CLI tools down to compilers & CUDA — stopping just above the kernel. 70 

P A R T I I · D I S P O S A B L E T E X Agents compile & review TeX, autonomously Portable & Reproducible Research Environments Tex source files pixi (project local) Tectonic (XeTeX) Tex pkg fonts Tex engine OS / linux kernel PIXI COVERS • No system TeX install — engine, packages, fonts all from Tectonic. • No docker required. • Same build on Linux (x86/aarch64), macOS, WSL via pixi + Tectonic (XeTeX). • The agent just runs pixi run build, then reviews the PDF. github.com/denkiwakame/pixi-tex github.com/tectonic-typesetting/tectonic pixi add tectonic T 71 

D E M O Automated TeX Building by Pixi + Tectonic 72 

D E M O Automated TeX Building by Pixi + Tectonic 73 

D I S P O S A B L E A N A L Y S I S PEP723: Declare dependencies in the header Portable & Reproducible Research Environments Debug_plot_A.py uv · disposable virtual env plotly pandas kaleido system Python gcc / clang OS / linux kernel UV COVERS PEP723 is very handy way to try & error for agentic disposable analysis. #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ # "plotly", "pandas", "kaleido", # ] # /// import pandas as pd import plotly.express as px • Dependencies are installed at runtime • No updates in the project's lockfile 74 

A I - A S S I S T E D C O D I N G The third era of software development Autonomous cloud agents — bigger tasks, longer timescales, less human direction. Source: Cursor, “The Third Era of Software Development” · cursor.com/blog/third-era 75 

A I - A S S I S T E D C O D I N G Three paradigms Portable & Reproducible Research Environments 1 Tab autocomplete AI completes your keystrokes. You write the code; AI just speeds up the typing. 2 Synchronous agents You direct an agent in prompt-and- response loops — in the loop at every step. Only a few at a time. 3 Cloud agents Autonomous: bigger tasks, longer timescales, less direction. Fleets of them, running in the cloud. F UT URE Each era moves further up the stack — and further from the keyboard. 76 

W H E R E T H I S L E A V E S U S The third-era workflow Portable & Reproducible Research Environments 1 Agents write almost 100% of the code. 2 Your time goes to decomposing problems, reviewing artifacts, and giving feedback. 3 Launch many agents in parallel — don't babysit a single one. And every parallel cloud agent needs a disposable, reproducible environment — that's pixi or uv? Source: Cursor, “The Third Era” · cursor.com/blog/third-era 77 

W H Y I T F I T S pixi can be a disposable agent environment Portable & Reproducible Research Environments No sudo, no root Everything lives in the project / user prefix. Throwaway by design Delete the folder — the environment is gone, cleanly. Reproducible per run The lockfile rebuilds the exact same stack. 78 

P A R T I I · A G E N T O R C H E S T R A T I O N Disposable envs become the default Portable & Reproducible Research Environments • In agent orchestration, agents run in the cloud — not on your laptop. • Cursor frames this as a “third era” of software engineering: the editor becomes an orchestrator. • You just watch the dashboard while fleets of agents work. • Cost forces tiering: one premium root agent + many small models (SLMs). Source: cursor.com/blog/third-era dashboard · you (watching) ↓ root agent premium model orchestrates ↓ SLM pixi env disposable · cloud· local SLM pixi env disposable · cloud· local SLM pixi env disposable · cloud· local Every ephemeral agent needs an instant, reproducible env — that's pixi's job. 79 

A W O R D O F C A U T I O N Handle AI agents with care 1 Least privilege & sandboxing An agent runs code with whatever access you give it. Grant the minimum — and run it in a disposable, rootless sandbox. 2 Don't trust the metric Agents optimize the score, not your intent — they can game the eval or fake results (reward hacking). Always verify the output. 3 Tokens are attack surface Credentials, tunnels, prompt injection, supply chain. Scope and rotate tokens; treat the network as hostile. Reproducibility is accountability — who ran what, where, with which exact environment. Portable & Reproducible Research Environments 

T A K E - H O M E M E S S A G E Summary 1 Build reproducible environments in a declarative style. Declare the goal; let the lockfile pin it everywhere. 2 disposable + reproducible = ideal for AI agents. An agent can throw it away and rebuild it identically. 3 Go cloud-native: one environment, laptop → cloud → agent. No rewrite as your work moves off your machine. Declarative · disposable · reproducible — portable enough for the cloud and for agents. 81 

L I N K S & R E F E R E N C E S Where to go next Pixi pixi.prefix.dev/latest Pixi whitepaper arxiv.org/abs/2511.04827 SciPy conference proceedings proceedings.scipy.org/articles/nwuf8465 ICRA tutorial petercorke.github.io/ICRA2026-modern-software-tools Pixi wiki share.google/lSoKj6SDL88kuihyr conda-forge knowledge base conda-forge.org/docs/maintainer/knowledge_base Portable & Reproducible Research Environments RoboStack / pixi-ros robostack.github.io nanokit github.com/denkiwakame/nanokit 82 

Thank you Questions or Comments 83