A workflow that treats CUDA kernel performance as evidence to record

A documented process, not a code generator

Kernel Design Agents is a research repository from NVIDIA's own labs, and the README states its scope with unusual precision for a project this new: it is an agent-centric workflow for using coding agents to research, implement, verify and iterate on performance-sensitive CUDA kernel tasks. It is not a code generator you point at a specification and walk away from, and it is not a benchmark suite. It is a documented process, plus a small set of supporting skills, for how an engineer should structure an agent's work on the specific, unforgiving problem of writing CUDA kernels that actually need to be fast.

The README is upfront that this is an early research prototype under active development rather than a finished product, and it points elsewhere for the actual performance results the underlying approach has produced, naming a separate repository documenting solutions that ranked first through third on tracks at a machine-learning-systems kernel contest. That separation, the workflow published here and the competition results published there, is a sensible one: a process is worth evaluating on its own terms, and pointing to independently verifiable contest rankings rather than folding an unverifiable performance claim into this README is the more honest way to substantiate it.

Why kernel work resists being handed to an agent naively

Writing a correct CUDA kernel is hard. Writing one that is also fast is a different and harder problem, because correctness and performance are validated in completely different ways: correctness is a pass or fail test, while performance is a number that depends on the specific GPU, the specific problem size, and a dozen low-level details of memory access patterns and occupancy that do not show up in a bug report, only in a profiler trace.

That is precisely the mismatch that makes naively pointing a coding agent at a kernel task risky. An agent that only checks correctness can converge on code that runs and produces the right answer while being dramatically slower than it needs to be, with no signal in its own feedback loop telling it so. The workflow's insistence on separating implementation from verification, and its explicit place in the loop for profiling evidence rather than only a pass or fail check, is the structural response to that mismatch: performance has to be measured and recorded as its own first-class artefact, or an agent has no way to know whether its own work actually succeeded at the thing that mattered.

Eight steps, each producing something the next step needs

The README's minimal flow is eight explicit steps, and reading them in order shows a workflow built around leaving a paper trail rather than only reaching a working answer. A separate implementation workspace is created for the target task. The task contract, its objective, constraints, validation command and promotion criteria, is defined before any agent session starts. The agent is given a starter prompt template filled in with task-specific details, asked to write a short plan draft, and that draft is converted into an executable plan either by hand or with a separate planning tool. Implementation proceeds in small iterations, verified after each meaningful change, and candidates, benchmark results, profiling evidence and the final promotion decision are all recorded rather than only the winning candidate.

That last step, recording candidates that did not win alongside the one that did, is the detail that turns this from a workflow for producing one kernel into a workflow for producing a body of evidence about why that kernel was chosen. A future engineer, or a future agent session, revisiting the same task later has a record of what was tried and rejected, not just a final file with no memory of the road not taken.

A workspace layout that treats evidence as a deliverable

The recommended workspace layout backs that philosophy structurally rather than leaving it to individual discipline. Alongside the expected draft and plan documents, it names dedicated locations for run logs, generated outputs, profiling data, a benchmark results file, and a candidates file, and the README states the exact files can vary by domain but the important rule holds regardless: the agent must record enough context for another engineer to understand what was tried, what passed validation, and why the final candidate was selected.

Stating that as the rule, rather than prescribing an exact rigid format, is the right level of abstraction for a workflow meant to generalise across different kernel tasks, different hardware targets and different benchmark harnesses. The README is explicit that the workflow is intentionally independent of any single benchmark harness or hardware target, and that a downstream task supplies its own evaluator, datasets, profiling tools and domain-specific references on top of the process described here, which is what makes this a template for structuring the work rather than a tool tied to one specific pipeline.

Two skills, pinned by commit rather than trusted to move

Two supporting Claude Code skills are installed by symlinking them from pinned Git submodules rather than cloning the latest version of each directly:

git clone --recurse-submodules https://github.com/mit-han-lab/kernel-design-agents.git
cd kernel-design-agents

mkdir -p ~/.claude/skills
ln -s "$(pwd)/skills/ncu-report-skill" ~/.claude/skills/ncu-report-skill
ln -s "$(pwd)/skills/KernelWiki" ~/.claude/skills/KernelWiki

One skill interprets NVIDIA Nsight Compute profiling reports, the tool that actually produces the low-level performance evidence a kernel task depends on; the other is described as a wiki of kernel-design knowledge. Both are pinned to a specific recorded commit rather than tracking whatever the upstream repository currently contains, and the README states this deliberately for the wiki skill specifically: a direct upstream checkout may contain artifact snapshots under additional terms that are intentionally omitted from this distribution. Pinning to a known-good commit and explicitly stripping out anything with terms this repository cannot redistribute is the correct way to depend on external, separately licensed research material without quietly inheriting obligations the repository's own license does not disclose.

What to weigh before adopting it

Licensing is split cleanly by content type rather than applied as one blanket statement: first-party documentation, prompts and skills-style content are released under a Creative Commons attribution licence, first-party source code is released under Apache 2.0, and the third-party submodules are explicitly carved out as not covered by either, governed instead by their own upstream terms detailed in a dedicated third-party notices file. Splitting documentation licensing from code licensing this precisely is unusual outside a large, legally careful organisation, and it is the kind of clarity that matters specifically because the repository knowingly bundles other projects' material inside it. This is not legal advice.

The project reports 1,035 stars, 93 forks and a single open issue, with the last push on 2026-09-14, and it runs an open community wishlist where anyone can submit a kernel that needs optimising, currently scoped to two specific NVIDIA GPU generations, as a pull request carrying a reproducible definition, representative workloads and a best-known baseline, which the README states requires no separate issue to be filed first.

Before adopting this workflow, three steps in order. Read the linked contest-results repository if the performance claim behind this project is what drew you here, since the substantiation lives there rather than in this README. Set up the task contract, objective, constraints, validation command and promotion criteria, before starting any agent session, since the whole workflow depends on that contract existing first. And treat the recommended workspace layout as a floor rather than a rigid template, adapting the recorded artefacts to your own domain while keeping the underlying rule intact: another engineer should be able to reconstruct what was tried and why the final candidate won.

Editorial conclusion

Kernel Design Agents fits an engineer using a coding agent on genuinely performance-sensitive CUDA work, where correctness alone is not the goal and speed has to be measured and defended with profiling evidence rather than assumed, and its eight-step process is built specifically around the gap between an agent that merely produces working code and one that produces code proven fast against a recorded baseline. Its insistence on logging rejected candidates alongside the winning one, and its explicit independence from any single benchmark harness or hardware target, make it a template for structuring the work rather than a tool tied to one pipeline. Read the linked contest-results repository for the actual performance substantiation behind the approach, define your task contract, objective, constraints, validation command and promotion criteria, before starting any agent session, and treat the recommended workspace layout as a floor to adapt rather than a rigid format to follow exactly.

Frequently asked questions

Official sources

1. Issues
2. NVlabs/kda on GitHub
3. Project website
4. README