Nikhef Colloquium · Amsterdam · 2026‑07‑01

The Facility Is
the Context

Agentic computing infrastructure for analysis at scale

Giordon Stark (UC Santa Cruz / SCIPP) · on ATLAS, in conversation with CMS, DUNE & Belle II

Agentic intelligence for research computing
Slides AI-assisted by Claude (Anthropic) · title illustration AI-generated.

The argument in one slide

The model is the easy part

What everyone watches

Which model is best this month. The harness. The demo that goes viral. This layer moves fast and is not ours to own.

What a facility actually owns

Context, identity, trust, packaging, and equitable access. Stable, hard, and exactly the Physics Data Processing remit.

The claim

An LLM becomes useful on your cluster the moment it knows your storage, your scheduler, your data, and your identity model — and stays safe only when those are real. That layer is a computing-infrastructure problem, and it ports across experiments. The rest is interchangeable.

Why context is the hinge

“Where do my job outputs go?”

A batch job emits big outputs and small summaries. Where should each land?

A generic LLM

“Write them next to your job” → $HOME. The big files blow the home quota in minutes.

An LLM that knows the facility

Big outputs → fast local scratch (SSD/NVMe, wiped after the job); small summaries → the small backed-up home that persists.

The axes it reasons over: ephemeral vs persistent · local SSD/NVMe vs network-mounted (dCache, XCache) · user vs project space · small+quota'd vs bulk.

The point

The model didn’t get smarter — we gave it facility context. Hold this example; every later idea is a way to deliver context like this safely and portably.

Grounding · fast vocabulary

Four words for the next 40 minutes

Agent

A loop that uses an LLM to decide a step, call a tool, read the result, repeat.

MCP server

Model Context Protocol: a standard adapter exposing a service (Rucio, a notebook, a DB) as tools + live context any agent can call.

Skill

Static context loaded on demand: a reusable recipe (“how we do a fit here”).

Harness

The app that gives the agent hands — runs commands, wires MCPs, enforces permissions (Claude Code, Codex, …).

Bundle skills + MCPs + agents → a plugin; a discoverable collection of plugins → a marketplace.

Related work · the framing (backup)

The ecosystem framing (Watts)

“It’s not about a smarter LLM — it’s about smarter infrastructure around it.” G. Watts, “Beyond Code Generation,” CHEP 2026
  • His framing: data & tools → MCP → skills → agents; grounded in primary sources; “we need a pip-install.”
  • This talk: the facility-context layer is the decisive one, it ports, and the open problems are identity, trust, packaging, and equity.
Gordon Watts' Analysis Ecosystem boat diagram

G. Watts’ CHEP 2026 slides · © Gordon Watts + AI

Watts, CHEP 2026: indico.cern.ch/event/1471803/contributions/6969164

01

Existence proof

It already works

Existence proof · what I operate

This runs in production, not a demo

A Kubernetes-based analysis facility for USATLAS Operations — I run it, hands-on.

~800

physics users

2,800

HTCondor cores

9 PB

Ceph storage

Triton

inference-as-a-service

Compute: 1520-core long queue (7 days) + 1280-core short queue (4 h, spills over), hyperconverged; 4 SSH + 4 Jupyter nodes; Dask Gateway. Storage: /home NFS 19 TB (100 GB/user) · /data + /cold Ceph 4.5 PB each (/data 5 TB/user, not backed up).

Ganglia graph: login02.af.uchicago.edu CPU usage over the past year

Real-time monitoring: ganglia.mwt2.org

Triton IaaS + a REANA workflow cluster already make this an AI/ML platform. This is exactly the Physics Data Processing problem — the agentic layer sits on infrastructure I operate, systems engineering I do hands-on, not a slide-deck vision.

Triton→Athena inference: V. Tsulaia, CHEP 2026.

Running today at the UChicago AF

A facility that teaches agents about itself

Managed context

System-wide CLAUDE.md + an allow-list of safe commands, shipped by config management. The facility sets the guardrails, not the user.

Marketplace

One-line install of facility + experiment skills (HTCondor, Rucio, ServiceX, pyhf…). Context as a versioned, shareable artifact.

Data MCPs

rucio-mcp / ami-mcp: find datasets, replicas, cross-sections by asking. Already serving ATLAS, CMS, DUNE, ESCAPE.

Jupyter MCP

Drive a live AF notebook from any client — laptop, even a phone — via an in-pod MCP server.

Web chat

OpenWebUI at a URL, backed by an AF knowledge base. Zero install for non-terminal users.

Ops agents

A scheduled agent scans HTCondor, posts a morning health report, drafts fixes — human-approved, never autonomous.

Every one of these is the same move: write the facility down once, let any agent inherit it. Multi-experiment from day one — the Rucio MCP serves four VOs behind one endpoint.

Web chat: af.uchicago.edu/chat · usage observability: Grafana (Prometheus metrics per site/tool).

Running today · let me show you one

A live AF notebook, driven from your phone

An in-pod MCP server exposes a running JupyterLab. Any MCP client — my laptop, or the phone in my hand — drives it through a brokered gateway I’ll show you shortly.

  • Same identity, same audit as every other tool call.
  • No notebook UI on the device — just intent in, results out.
  • The agent never sees a credential.

The interesting thing isn’t the phone. It’s that my identity, authorization, audit, and facility context followed me to it — that’s a new architecture, not a trick.

Built on the Jupyter MCP streamable-HTTP extension · full-length recording: Google Drive.

Not an ATLAS story

The same tools already cross experiments

  • ATLAS — where I work; the deepest playbook, in production at the UChicago AF.
  • CMS & DUNE — the hosted data-access layer already serves their VOs; informal collaboration with colleagues on these agentic ideas.
  • Belle II — early discussions on the same ideas.
  • ESCAPE — a live escape site behind the hosted Rucio MCP: the bridge to the multi-science world (more shortly).

The reason it crosses experiments isn’t generosity — it’s the architecture: the agent speaks intent, the facility wires the backend. Swap the playbook, keep the engine.

rucio-mcp configured OIDC sites: atlas, cms, dune, escape, each at rucio-mcp.af.uchicago.edu/site/<vo>

rucio-mcp.af.uchicago.edu — four real, live OIDC sites.

claude mcp add --transport http rucio-atlas \
  https://rucio-mcp.af.uchicago.edu/site/atlas/

02

Why it ports

Architecture, briefly

Core insight

Swap the model freely; context makes it useful here

Modelfrontier API · or self-hosted open weights → cost control
HarnessClaude Code · Codex · Copilot
Facility context & toolsstorage, scheduler, data, identity, fit tools

An assistant that’s actually useful here

First two blocks are interchangeable. Every win you just saw came from the third. Pragmatically: the model/harness layer churns monthly — a facility can’t both run a cluster and chase that. Context is the tractable, durable scope.

Core insight · flip side

No context? It should stay quiet

What actually happened

Our cluster agents confidently recommended Lustre tuning for a filesystem that is actually Ceph. Zero Ceph context. Plausible, fluent, and wrong.

The rule we adopted: ungrounded → silent. Context isn’t only what makes an agent useful; it’s what makes it safe to trust. This is why "who keeps the context true" is a real infrastructure question, not bookkeeping.

Architecture · abstraction

The agent speaks intent, the facility wires the backend

data_tool“get this dataset + metadata”

transform_tool“turn inputs into histograms”

batch_tool“run across the cluster”

inference_tool“fit and get a limit”

Rucio · dCache · Open Data

coffea · uproot · ServiceX

HTCondor · Slurm · Dask · REANA

pyhf · cabinetry · RooFit · SBI

inference_tool privileges no single fitter: HS3 (HEP Statistics Serialization Standard) + pyhs3 are the bridge between pyhf and RooFit.

The agent never names “coffea” or “condor.” That indirection is exactly what lets the same agent move between facilities and experiments.

Architecture · portability concretely

Same engine, different playbook

Reasoning engine

Orchestration, routing, guardrails. Written once. Model- and experiment-agnostic. shared

Playbook

Which MCPs/backends, the system prompt/CLAUDE.md, the knowledge corpus. swappable

A new facility/experiment writes a thin playbook, not a whole stack. The goal: stop re-developing the same agentic tooling in parallel — across AFs, across experiments, across sciences.

Sports-team analogy: coach=reasoning engine, playbook=playbook, athletes=agents, equipment=services, stadium=gateway

Coach = engine · playbook = playbook · athletes = agents · equipment = services · stadium = gateway

03

The agenda

What I’d build
(and what’s hard)

Three things a facility owns: identity & trust · operations & portability · equity & the commons.

Theme 3.1 of 3

Identity, access & trust

Before an agent does anything useful, the facility has to answer who it is, what it may touch, and how it earns more rope.

Gateway · identity (CIMD/DCR) · ssh-oidc · sandboxing · the trust ladder.

Agenda · the platform boundary

A credential-brokered MCP gateway

One endpoint in front of the facility’s services. The LLM client never holds raw credentials; the broker authenticates the user, mints per-service credentials, and audits every tool call.

Claude, Gemini or any MCP client to the mcp.af.uchicago.edu front door (oauth2-proxy, AF Keycloak OIDC), through a FastMCP aggregator and AF credential broker (FastAPI /v1) doing identity, authZ, credential brokering and audit, fanning out to rucio-mcp, ami-mcp, openmagic, panda-mcp, condor-mcp, gitlab-mcp, jupyter-control and an Nth backend with no code change

This is the strategic boundary: identity, authZ, credential brokering, and audit in one place. It’s the natural way to put an agentic layer in front of a Tier-1 / PDP service estate without handing tokens to a chatbot — the same boundary a Tier-1 needs regardless of AI.

rucio-mcp · ami-mcp · atlasopenmagic · panda-mcp · condor-mcp (Bockelman, CHEP 2026).

Deep-dive · gateway topology

One MCP, many, or a gateway?

one process boundary atlas cms dune

One server, many sites

one deploy   per-VO auth in one process

atlas server cms server dune server

One server per site

clean isolation   N servers to run

gateway sub-MCP sub-MCP sub-MCP

Single gateway

one identity   token sprawl / choke point

FastMCP composition = one auth provider per server; that constraint drives a lot of the design.

Agenda · identity is the bottleneck

Who is this client, and may it act as you?

Every MCP client — Claude, an internal tool, something a student wrote — wants to connect. Once agents are the ones connecting, this stops being a one-time setup step and becomes a continuous, scalable decision:

Who is it?a durable identity, not just a name
Do we trust it?policy, not vibes
How much authority?scoped, auditable

Identity is becoming the bottleneck, not an afterthought — exactly the identity half of the Physics Data Processing problem, and WLCG’s x509→OIDC transition is the backdrop. Today, most clients register the way DCR prescribes — the adopted, stateful mechanism. A newer draft spec, CIMD, proposes something stateless instead (a client’s identity as a URL the server fetches) — worth watching, not yet the default. This sits on top of the community’s federated-identity work — WLCG token profiles, the AARC blueprint, IAM — not instead of it.

Deep-dive · CIMD vs DCR

Client ID = a URL the server fetches

GET /authorize?client_id=https://app.example/oauth.json&…
        │  authn server fetches the JSON, validates, applies policy
        ▼
{ "client_id":"https://app.example/oauth.json",
  "client_name":"…","redirect_uris":[…] }   ← hosted by the client
  • Wins: no /register abuse surface; stable identity per app; domain-based allow/deny.
  • Costs: server makes outbound fetches → SSRF risk (block private IPs, HTTPS-only, size/timeout caps); localhost ambiguity; domain ≠ trust.

Concretely in FastMCP: CIMDTrustPolicy(trusted_domains=["claude.ai","cursor.com"], auto_approve_trusted=True) — the facility decides which domains skip consent.

Auth today reuses grid creds (x509) or Keycloak OIDC — OAuth bridge docs.

Deep-dive · it’s this new

CIMD, live, in Claude Code today

1. Add the server

claude mcp add --transport http \
  cimd-test https://<tunnel>/mcp

2. Claude Code's own request trace

POST /mcp                    ua=claude-code/2.1.142
GET  /.well-known/oauth-protected-resource
GET  /.well-known/oauth-authorization-server
GET  /oauth/authorize?response_type=code
       &client_id=https%3A%2F%2Fclaude.ai%2F...
       &redirect_uri=http%3A%2F%2Flocalhost...

The client_id is a URL, not a UUID — one per Claude surface:

This is weeks old, not years — the community is still asking “does CIMD even work in the Claude Desktop/Web client yet?” on r/ClaudeAI.

RFC 7591/7592 (DCR + management) · RFC 8252 §7.3 (loopback redirect) · RFC 8707 (resource indicators) · MCP authorization spec · Parecki, CIMD draft · Anthropic connector auth docs.

Agenda · access without keys

ssh-less, key-less: log in with your federated identity

SSH keys are trusted permanently, live on disk or in an agent socket, and spread across devices and teams — and now there’s a new reader in the room: an AI agent with shell access. ssh-oidc (KIT/EOSC-synergy, AARC-native) is one toolkit that replaces the permanent key with a short-lived, revocable, federated credential.

Private keyon disk / in ssh-agent, forever
Anything with agent accessincl. an LLM agent
Can sign in as youno expiry, no federation, hard to revoke

Federated OIDC tokenminutes, from your IdP
motley-cueidentity → account, JIT
PAM token or SSH certpam-ssh-oidc / oinit — short-lived, revocable

The push: OIDC tokens + SSH certificates across the toolchain, so the same identity that authorises a dataset read also authorises a shell — and an agent inherits a short-lived credential, never a permanent private key.

ssh-oidc: Gudu, Hardt et al. (KIT / EOSC-synergy). “SSH with federated identities,” CHEP 2026; EPJ Res. Infra. 2025, doi:10.1007/s41781-025-00136-5.

Deep-dive · ssh-oidc internals

PAM token vs. SSH certificate

Both are last-mile options within the same ssh-oidc toolkit — oidc-agent holds the token client-side, motley-cue maps identity→account server-side and provisions it just-in-time, then one of these two gets you a shell.

PAM (pam-ssh-oidc)

Paste/forward an access token; motley-cue verifies it; OTP fallback when token > 1023 B (OpenSSH limit). Unmodified sshd.

Certificate (oinit)

Online CA issues a short-lived SSH cert in exchange for a token; stored in ssh-agent; transparent for rsync/git; no per-host key trust; enables “non-username” login.

mccli wraps the whole toolkit into one command for the end user:

mccli ssh login.af.uchicago.edu
  → oidc-agent supplies the token, motley-cue maps you to an account, you get a shell.
oidc-agent · motley-cue · mccli.

Agenda · what may an agent do?

Sandboxing on (and off) Kubernetes

Podsk8s default: caps, no host access
Sandboxoff k8s: bubblewrap, sydbox
PolicyeBPF-class, fine-grained
Privilegeearned, human-gated

The honest gap

Today a harness can advise (managed CLAUDE.md, allow-lists) but can’t reliably hard-deny a command at the user level. Real blocking needs a privileged policy engine on the node, or a sandbox — as a fellow facility sysadmin put it, an agent just lets users 100× the bad behaviour we’ve had for decades.

Meme captioned I've got to keep control

Deep-dive · how do you actually enforce it?

Pods, cgroups, and eBPF

Coarse: containers / cgroups

Resource isolation (CPU/mem/io), bind-mounts to hide paths, seccomp to drop syscalls. Blunt but simple.

Fine: eBPF

Sandboxed kernel programs attached to a hook point — a syscall, a kernel tracepoint, a kprobe/uprobe almost anywhere. Tetragon, Falco, bpflock.

User-space process agent, shell, tool call syscall / tracepoint Hook point (kernel) eBPF program verified, sandboxed, JIT-compiled inspect → log / alert / (BPF-LSM) act

cgroups/pods and eBPF are orthogonal: resource isolation vs fine-grained syscall/file policy. An agent may need both — a pod for blast-radius, a policy engine for “don’t find / the shared filesystem.”

eBPF: ebpf.io/what-is-ebpf · agent-focused eBPF observability: agentsight.

Agenda · earned autonomy

A trust ladder, with promotion gates

Observe

read-only diagnostics (the HTCondor monitor)

Suggest

drafts a fix; a human approves

Submit job

acts, scoped and reversible

Restart service

bounces a stuck transformer / worker

Operate production

remediates Ceph, deploys services

How does an agent earn the next rung? An evaluation harness: curated fault scenarios in a staging facility, scored, regression-tested when the model changes. The eval is the promotion gate — autonomy is measured, not assumed. This is my most distinctive research contribution — and a concrete research agenda for Nikhef, not just an engineering task.

Theme 3.2 of 3

Operations & portability

Two things a facility has to get right operationally: who’s allowed to do what at every layer, and whether the tools and environments they use actually travel.

Levels of autonomy · the operational-AI fabric · pixi · cluster-as-code.

Agenda · from analyst to sysadmin

AI at every layer of the facility

Analyst-facing

Find data, generate code, submit, recover, fit. Low autonomy, high convenience.

Operations

Cluster health reports, hold-reason triage, drafted user emails — human-approved.

Sysadmin-facing

Config/runbook copilots in the privileged lane; trust earned, actions gated.

Daily HTCondor cluster report posted to Slack by the AI monitor agent

Morning report — 448 held of 14,671 (3.1%)

Drafted held-job email posted to Slack, approved by a human, then sent by the agent

Drafted fix → human types “approve” → sent

Same context layer, different autonomy and blast radius at each level. The facility decides where the human gate sits.

Agenda · the fabric beneath analysis

Operational AI for shared infrastructure

Telemetry → foresight

Anomaly detection over existing monitoring + accounting: reactive firefighting → proactive, root-cause alerting. Accounting-record integrity as a contained first win.

Query-aware caching

The analysis describes the columns it will read; drive XCache/XRootD prefetch from that, not workflow-blind heuristics.

AI above the scheduler

Forecast runtimes, right-size over-requests, pick MIG profiles, route across heterogeneous/federated resources. The scheduler still places; AI shapes the inputs.

Upstream leverage

These sit upstream of every experiment (a Tier-1 concern), so even modest gains compound across the whole community.

The same intent-tool abstraction sits over a KM3NeT reconstruction job or a Virgo data-quality pipeline as readily as a Coffea columnar read — the backend changes, the agent’s interface doesn’t.

Agenda · portability of environments

pixi-native facility operations

The classic failure: “works on the login node, breaks on the worker.” Batch nodes are small and often have no public internet. pixi locks the environment; pixi-pack ships that exact env into the job as a self-contained artifact.

A pixi project with a digest-pinned pixi.lock on the login node is packed by pixi-pack into a self-contained environment.tar, shipped without CVMFS, and recreated by pixi-unpack on a network-free worker node with an identical environment

Backed by conda-forge + the HEP Packaging Coordination: ARM/HPC builds, supply-chain hardening (dependency cooldowns).

Why it matters for agents: an agent that builds an analysis must ship the same environment it tested to the cluster. pixi makes “the env the agent used” a portable, verifiable object.

M. Feickert, “HEP Packaging Coordination: distributing the HEP software ecosystem on conda-forge,” CHEP 2026 · SciPy proceedings.

Agenda · deploying the cluster itself

The cluster as declarative code

A Kubernetes-based facility, deployed by GitOps (Flux/Helm, infra-as-config): the cluster’s desired state lives in git, reconciled continuously. The AF, the MCP gateway, and the ESCAPE VRE all already run this way — same primitives, different playbook.

Before: manual ops kubectl / scripts config drift incident debugging high MTTR reactive fixes After: GitOps git (source of truth) Flux / Helm reconcile Kubernetes cluster self-healing workloads auto-reconcile AI agent proposes a PR

“Deploy a facility” becomes “apply a manifest.” And once the cluster is code, an agent can participate the same way a person does — propose a PR, let Flux reconcile it, watch it self-heal. That’s how the same agentic platform lands at a second site without a rebuild.

Theme 3.3 of 3

Equity & the commons

Who gets to use the models, what agents may reach, and where shared context lives — facility and community decisions, not personal ones.

Equity of inference · agents and the open web · the skills commons.

Agenda · equitable access to inference

Who gets to use the models — and who pays?

  • If agentic analysis becomes normal, access to inference becomes a fairness issue: a credit-card-per-student model entrenches inequality between groups and countries.
  • A facility can host open-weight models on its own GPUs (NRP-style) for equitable, cost-controlled baseline access…
  • …and host the foundational models experiments depend on, so reconstruction/inference services aren’t hostage to a single vendor or budget line.
  • Bridge identity, don’t fork it: exchange a scientist’s WLCG/SciTokens credential for a scoped token an inference backend accepts (OAuth 2.0 Token Exchange, RFC 8693) — MCP-aware, so it scopes which models and which tools.

This is squarely a computing-infrastructure responsibility: GPUs, model hosting, and a fair-share policy are facility decisions, not personal ones. The cost is already real — a full agentic analysis runs to ~1M+ tokens (illustrative), tens to hundreds of dollars per run at frontier rates (numbers below).

Agents already perform full HEP analyses end-to-end — Moreno et al., arXiv:2603.20179 — and that run kept stalling on usage rate-limits: access is already the binding constraint.

Deep-dive · what a run costs

Per analysis: tens to hundreds of dollars

My illustrative floor, not from the paper: one agentic analysis ≈ ~1M input + 1M output tokens (code-gen ≈ 1:1) at list prices. A real analysis can run much higher. Moreno et al. report only a subscription tier + wall-clock, not a per-run token cost.

Frontier (hosted)

$100–200+

Mid-tier (hosted)

$15–35

Open-weight (self-hosted)

GPU time only

Self-hosting open weights on facility GPUs collapses the per-run cost to ~GPU time — the equity lever. A credit-card-per-student model does the opposite, between groups and between countries.

Tiers from per-Mtok list prices (input + output) via the AI token pricing calculator, ballpark; the 1M + 1M budget is illustrative. Agents already run analyses end-to-end: Moreno et al., arXiv:2603.20179.

Agenda · a security reality

Agents don’t get the open web

  • Facilities (NERSC, UChicago, SLAC, BNL, AmSC, NRP…) are blocking web access for agents to defend against prompt injection from untrusted pages.
  • So a skill can’t just say “go read the docs.” It must encode just enough guidance — and delegate “what’s the latest?” to a curated MCP, not the open internet.

Stale-prone

use /path/2024-egamma-recs.config

a hardcoded path, wrong within a season.

Durable

“ask the chATLAS MCP for the latest recommendation path, then configure.”

the MCP owns “what’s current.”

The design rule: minimal durable guidance + a trusted live source. What an agent may reach is a facility decision, not a user convenience.

Agenda · where context lives

One commons, not a dozen forks

  • Skills are the durable context layer — but who hosts them, who maintains them, and how do we stop every experiment forking the same skill?
  • A live debate in ATLAS right now: a single-source marketplace (reference skills by URL, fix upstream) vs duplicated copies; docs kept next to the source code; official, e-group-governed repos over personal ones. Still open: how to link, not copy (usatlas/marketplace#60).
  • As the library grows, semantic confusability bites (overlapping descriptions degrade routing) → skill-design guides + an eval/lint harness to keep skills orthogonal.
  • A third option worth watching: package skills like software. prefix.dev’s skill-forge distributes agent skills as versioned conda/pixi packages — the same lockfile discipline as pixi-native environments, applied to context instead of code.

I already operate a marketplace others are converging toward (following agentskills.io practice). The open question for Nikhef & ESCAPE: what is the European/Tier-1 contribution to that commons? ESCAPE is the model for how such a collaboration forms and persists. On the US side, an AI proto-collaboration (umbrella over IRIS-HEP and other funded projects + research groups, open to international collaborators) updates at DPF, July 2026.

US AI proto-collaboration update: DPF 2026.

04

Beyond one facility

Nikhef, ESCAPE,
and the multi-science turn

A bridge that already exists

The agentic layer, meet ESCAPE

Nikhef + ESCAPE: multi-messenger astronomy by design and AI integration — Virgo gravitational waves, KM3NeT neutrinos, XENON dark matter, Auger cosmic rays, feeding an AI and data analysis center
  • ESCAPE’s Data Lake (Rucio), VRE (k8s + Jupyter + REANA + CVMFS), and OSSR software registry — a multi-science analysis platform Nikhef helps build.
  • My hosted Rucio MCP already serves an escape site. The bridge is built; the agentic layer can sit on top of the VRE.
  • Multi-messenger by design: GW (Virgo), neutrinos (KM3NeT), dark matter (XENON), cosmic rays (Auger) — Nikhef’s astroparticle breadth is ESCAPE’s target community.
# escape.cfg — a real, shipped site config
[client]
rucio_host = https://vre-rucio.cern.ch
auth_host = https://vre-rucio-auth.cern.ch
oidc_issuer = escape
oidc_audience = rucio

Bring the credential-brokered gateway + portable playbooks to the ESCAPE VRE, so the same tooling serves LHC and astroparticle science — built once.

rucio-mcp/data/escape.cfg · hero image AI-generated (Gemini).

…and upstream of every experiment

The same patterns at the service layer

Analysis facilities are the visible end. The bigger leverage is the shared services upstream of every experiment — data origins/caches, accounting, identity — i.e. the Tier-1 / OSG-LHC layer. One organizing principle: move AI from passive observation toward trustworthy, measured autonomy.

Operate

anomaly detection on telemetry + accounting integrity

Authorize

token-exchange from WLCG/SciTokens to AI backends

Standardize

a conformant facility-MCP interface, WLCG-style

A shared commons across US and European facilities — Nikhef, together with SURF on the Dutch national e-infrastructure and Tier-1, contributing the European perspective, not re-inventing it.

AARC · EOSC · SURF · ESCAPE.

Not engineering tickets — research questions

What we don’t know yet

How should facilities expose context?

One MCP per service or a gateway delegating identity? DCR or CIMD? Where does Nikhef’s audit live?

How do we share context between facilities?

Shipped with the facility, or a shared commons? Single-source vs forks; eval/lint for orthogonality; who keeps it true?

How do we evaluate — and secure — an autonomous operator?

Human gates, k8s vs bubblewrap/eBPF isolation, credential brokering so agents never hold raw secrets, a trust ladder with an eval-harness promotion gate.

What makes an environment truly portable?

pixi-native batch as the default? Supply-chain policy for conda-forge?

Who pays for inference, and is that fair?

Hosted frontier vs self-hosted open weights on facility GPUs; equity as policy.

What becomes standardized, across sciences?

A commons spanning AFs, LHC experiments, and astroparticle (KM3NeT, Virgo, XENON) via ESCAPE — where’s the facility/experiment line?

My bet: the model and harness are the easy part. Context, identity, trust, and equity are the facility’s homework.

If I joined

What I’d build first

  • A credential-brokered MCP gateway in front of a Nikhef PDP / Tier-1 service — Nikhef’s own identity and audit at the boundary.
  • An evaluation & safety harness for autonomous operations — the trust-ladder promotion gate, so autonomy is measured, not assumed.
  • The agentic layer on the ESCAPE VRE as a multi-science pilot — built once, ported to astroparticle.

Infrastructure, standardization, and research — aligned with PDP’s remit and the new AI/ML group, built to port, not to silo.

Backup · track record & strategy

Funding, projects, and people

Funded today

Split 50/50: IRIS-HEP (NSF) and USATLAS Operations (DOE base grant). I’ve also helped shape a HEP-SPIn (HEP Software Packaging Initiative) proposal. A BMBF/BMFTR “hop-on” fellowship with TUM is funding a public probability-model portal for DEMOS.

Mentoring pipeline, right now

Four students, four funding contexts: three on pyhs3 — an IRIS-HEP fellow (benchmarking), a UCSC summer student (validation), a DEMOS summer student (porting distributions to pytensor) — plus one on USATLAS Facility Benchmarking: typical user analysis workflows, compared across facilities. Diversified, not concentrated in one grant.

I’ve coordinated multi-institution efforts — the ATLAS SUSY combination across ~14 analyses and a dozen teams, and the skills/marketplace commons — the program-leadership muscle, not just the code. I don’t have a Nikhef-specific funding plan or named calls yet; ESCAPE, EOSC, WLCG, and Horizon Europe are the natural collaborations I’d explore first.

Thank you

Generic LLM → facility-aware collaborator

Swap the model and harness freely. The facility context, identity, and trust are what make it useful and safe here — and they port to the next facility, the next experiment, the next science.

A team effort at the UChicago AF; informal collaboration with CMS, DUNE, and Belle II colleagues; and, I hope, with Nikhef and ESCAPE next.

Now — let’s discuss.

Pointers

I don’t think every laboratory should build its own AI platform.
I think European research infrastructure should build this layer together.

In flight & next: server-side CIMD trust policies · more brokered MCP backends · the trust-ladder eval harness · pixi-native batch as a default

Giordon Stark · kratsg · Nikhef colloquium · 2026‑07‑01.
d65db1d · 2026-07-01