Open Source Radar · 2026-10-21: Skills start getting governed like software packages

Open Source Radar · 2026-10-21 · By Renchao Wu

Each day I pick five projects rising on GitHub, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-21. Feature, security and benchmark descriptions below reflect the linked project documentation; I have not independently validated those claims.

One caveat about today's method: both GitHub Trending scrapes (weekly and daily) timed out, so all five entries came from topic search. That means the "rising this week" signal is missing today; I ranked by repository age, last push and average stars per day instead. I come back to this at the end.

1. NVIDIA/skills ⭐ 3,669 · Python

GitHub: https://github.com/NVIDIA/skills

In one line: NVIDIA turned its SDK documentation into 415 installable agent skills, each with a signature, a capability card and an evaluation dataset.

What it is: A catalog that only distributes. Skill bodies live in each product's own repository; an automated pipeline mirrors them here daily, grouped across 56 products (CUDA-X, cuOpt, BioNeMo, DeepStream, Holoscan, Omniverse, Nemotron and others), and a CLI installs them into Claude Code, Codex, Cursor, Kiro and similar coding agents. The repository has no GitHub releases; it iterates on main with a daily sync.

What stands out:

• The admission bar lives in the pipeline, not in a document. For a skill to appear under skills/, it must carry three artifacts at once: skill.oms.sig (a detached signature verifiable against nv-agent-root-cert.pem at the repo root), skill-card.md (identity and governance card), and a Tier-3 evaluation dataset. Anything missing is dropped at sync time. That is much harder than asking contributors to submit good skills.
• What you install can be verified independently. The model-signing tool verifies a skill directory and confirms the content has not changed since NVIDIA signed it, a provenance check that does not by itself establish correctness or safety.
• Benchmark reports ship with the skills. When an evaluation run produces BENCHMARK.md, it is published alongside the skill, so readers see measured uplift instead of a recommendation.
• Product teams register in a manifest. One YAML per product under components.d/; plugins.d/ packages bundles, and two marketplace metadata files target different clients.
• The format is public. A directory with SKILL.md plus YAML frontmatter (required name and description), loaded by progressive disclosure: metadata at startup, full instructions on activation — the Agent Skills specification.

Compared with: The mechanisms worth comparing are the admission gate and its artifacts: a signature, capability card and evaluation set, plus published benchmark reports where available. I only read this repository, not the admission rules of other collections, so I am not claiming the others lack this.

Recent updates: On 2026-10-21 the sync commit pulled in the CDF family (AnomalyGen, Augmentation, Auto-Labeling, Curation) and the Holoscan SDK, and regenerated metadata.json, skills.sh.json, benchmarks.json and versions.json. The same day pinned the Physical AI component to paidf-26.10. The commit density shows a pipeline running daily.

Who it's for: People using coding agents for CUDA, simulation, robotics or RAG work: a skill supplies instructions for using the corresponding SDK; credentials, tools and permissions still need to be configured separately. Two caveats: the licensing is split (Apache-2.0 for source, CC-BY-4.0 for docs and skills), and skills are mirrored, so upstream changes overwrite local copies — plan on periodic npx skills update, which also flags skills that were merged or removed upstream.

My take: ⭐⭐. Useful as a catalog, but the real value is the governance structure. If you maintain a skill library, the four gates (signature, capability card, evaluation set, drop-on-missing) are worth copying.

Checked: read the README, repository structure, the contents API (415 skill directories) and recent commits; did not install any skill and did not run the signature verification.

2. smol-machines/smolvm ⭐ 6,779 · Rust

GitHub: https://github.com/smol-machines/smolvm

In one line: A microVM packaged as a library you can embed, with the ability to checkpoint a running machine and branch it into copies that keep running.

What it is: A virtual machine runtime that ships as a library. The VMM is libkrun, the guest kernel comes from libkrunfw, and the host side uses Hypervisor.framework on macOS, KVM on Linux, or the Windows Hypervisor Platform. Images are OCI, so compatible images from Docker Hub or ghcr.io can be used without a Docker daemon, and the SDKs run in the caller's process with no separate service. The version is v1.30.1, with three releases in two days (v1.29.1 on 10-16, v1.30.0 and v1.30.1 on 10-17) and more than 100 release records on GitHub.

What stands out:

• Branching is the core abstraction, not a side effect of snapshots. A checkpoint captures memory, CPU state and disks. machine branch --from agent yields a copy-on-write child of a live machine that continues from the same instant, and --from <checkpoint> --at '~N' rewinds to an earlier generation. For "one starting point, three paths", that beats running three times.
• The defaults are priced to be cheap. Its own table claims "under 200 ms to agent ready"; defaults are 4 vCPUs and 8 GiB, memory is elastic through virtio balloon, and idle vCPUs sleep in the hypervisor. Those are project-reported figures; I did not measure them.
• Artifacts travel. A configured machine packs into a single .smolmachine file, can be pushed to any OCI registry, or run as a self-contained executable. The README states a checkpoint taken on an arm64 Mac resumes on arm64 Linux.
• Networking is off by default. Egress requires an explicit flag, then per-host, per-pattern or per-CIDR allow rules that can be added and removed on a running machine; a grant applies to the next connection, and revoking a host also clears the addresses it learned.
• Credentials can stay out of the guest. With --credential, the guest sees a placeholder and the runtime substitutes the real value on outbound requests, according to the documented credential-proxy design. I did not test whether a guest could recover credentials or use them outside the intended request path.

Compared with: The README carries a comparison table, and the mechanism-level differences are checkable: containers are namespaces over a shared kernel, while this gives each workload its own guest kernel; it is a library rather than a daemon, whereas Firecracker is a process plus jailer; and it supports native macOS and an in-process SDK, two columns where the table lists Firecracker as unsupported. One honest note: it does not win on boot time. The table lists under 200 ms for itself and under 125 ms for Firecracker, so its advantage is platform coverage and embeddability. The table is the project's own and I did not independently verify the Firecracker or Kata figures.

Recent updates: v1.30.1 (10-17) exposes the engine's CLI commands as a library module, avoids redundant disk staging when pause/resume inputs fit in a memory filesystem, and widens the image-pull window for machine creation past five minutes. v1.30.0 pulls large registry blobs in parallel ranged parts. Commits on 10-21, not yet released, handle branch children outgrowing host RAM with OOM victim ordering and a memory-pressure guard. The work is clearly on the hard edges of real multi-branch workloads.

Who it's for: Teams that need to run untrusted agent code. Requirements are KVM on Linux or Apple Silicon on macOS; macOS Intel has no published release build and is marked untested, and GPU acceleration is unavailable on Windows. Know what it is not: it provides a boundary, not a policy. Every mounted directory, allowed host and forwarded secret becomes something the workload can use.

My take: ⭐⭐⭐. "A sandbox you can branch" is more useful than any single feature, because experiments can start from the same VM state. Branching does not undo external side effects.

Checked: read the README, three releases and recent commits; did not install it or boot any machine.

3. pydantic/pydantic-ai ⭐ 20,758 · Python

GitHub: https://github.com/pydantic/pydantic-ai

In one line: The Pydantic team's Python agent SDK, where tools, dependencies and outputs are all typed, and one agent definition runs as a CLI, a web app, a live voice session or a background job.

What it is: A library for defining agents plus a set of sibling components: a harness of capabilities for long-running work, an evaluation package, a typed graph for control flow, a model-pricing package, and a sandboxed Python interpreter for model-written code. The core abstraction is an agent plus capabilities, where a capability bundles tools, instructions, hooks and model settings into one reusable unit; the bundled coding and research agents are compositions of capabilities. The version is v2.58.0, with more than 300 releases on GitHub and both the v1 and v2 lines maintained in parallel (v1.107.8 and v2.58.0 shipped the same day, 10-20).

What stands out:

• Types reach the tool boundary. Structured outputs, typed dependency injection, typed tool signatures: your editor and type checker know what an agent returns, which can expose annotated interface mismatches during development. Runtime validation and authorization still need separate checks.
• One definition, many interfaces. CLI, built-in web chat, realtime voice, UI event streams, editor-agent protocol and headless CI runs all come from the same agent object, although type checking covers only the paths and annotations actually checked.
• Tools can be called mid-sentence in a live voice session. You push microphone audio, play streamed audio back and receive transcripts while the model calls your functions during the conversation. Backends cover OpenAI Realtime, Gemini Live, Azure and xAI Grok Voice.
• Durable execution across eight engines. Temporal, DBOS, Prefect, Restate, AWS Lambda, Airflow, Absurd and pgtask, the first five co-maintained with the vendor teams; agents survive restarts, run for days, and support deferred tool calls that wait for human approval.
• Evaluations grade tool trajectories. Not just final outputs: evaluation covers the sequence of tool calls, over datasets in code or a sample of live traffic.
• A medium-severity security fix landed the same day. The advisory is specific: provider-native MCP configuration could write MCP server URLs, authorization tokens and custom headers into OpenTelemetry request traces even with include_content=False, and a URL-based MCP capability could leak a credential embedded in the URL-derived identifier. Fixed in v2.58.0 and v1.107.8.

Compared with: Its typed interfaces build on an existing validation ecosystem: Pydantic says its validation library is already the validation layer inside the OpenAI SDK, the Anthropic SDK, Google ADK and LangChain, so this path grows out of dependencies that already exist. The README points to a comparison page covering LangChain, Google ADK, the Claude Agent SDK and about ten others; I did not open that page and check it line by line, so what follows describes its mechanisms, not a ranking.

Recent updates: Beyond the security fix, the 10-21 commits tighten boundaries: the tool-call limit is checked before each nested CodeMode call instead of once per turn; the trajectory judge's steering note is bound to its own frame with a reference, so forged feedback tags no longer apply; and grok-4.7 was added to the xAI model table.

Who it's for: Python teams building voice or long-running agents that need evaluation. Two practical notes: 1,564 open issues signal a large surface area, and with v1 and v2 in parallel you should confirm which line your dependencies support before adopting.

My take: ⭐⭐⭐. If your voice pipeline is Python, the combination of in-call tool use, typed boundaries and trajectory evaluation is a skeleton you can build on directly.

Checked: read the README, two releases, the security advisory summary and recent commits; did not install it or run any example.

4. kuafuai/andee ⭐ 1,690 · Kotlin

GitHub: https://github.com/kuafuai/andee

In one line: Install one APK and it uses your phone with a thumb: it reads the accessibility tree and screenshots, and taps grid cells instead of computing coordinates.

What it is: An Android app with no conventional interface. The entry point is an accessibility service, results are drawn in a floating overlay, and its face is a floating ball. The agent loop runs on the phone by default against any OpenAI-compatible endpoint, or the brain can move to a remote host and connect back over a tool-schema contract, so either half can be replaced. It reached 1,690 stars in about a month, with 43k+ lines of Kotlin written first-party and a deliberate refusal to use Compose, a dependency-injection framework or coroutines: overlays cannot host Compose, there is only one service so injection is by hand, and concurrency uses handlers plus dedicated executors.

What stands out:

• Screen reading degrades in two steps. Normally it reads the screen as an indented element outline, one line per element with a tappable id; for self-drawn surfaces such as mini-programs, web views and games it falls back to a screenshot overlaid with an 8×12 labelled grid. It taps by "which cell, which third of the cell" rather than computing coordinates, on the argument that general models read grids well and do coordinate maths badly; when a target is tight it zooms in and draws a red crosshair before committing. A fourth tap on the same spot is refused, so a confused model has to stop and ask.
• Typing goes through the keyboard's own path. On Android 13 and later it writes into the focused field through the accessibility service's text-commit channel, so the user's own input method stays active.
• A password can be used but not read. The vault is encrypted with Keystore AES-GCM on the device; the model can list accounts and have a password typed into the focused field, but no tool returns it, not even masked.
• A stranger's notification cannot reach the vault. Turns started by a notification are marked untrusted, and the dispatcher refuses the vault prefix and scene create/enter/delete outright — refused in the dispatcher rather than argued about in the prompt.
• It closes its own loops. When a conversation goes quiet it sends itself a turn, reads back alone, closes out promises it made, and ends empty-handed rather than inventing a memory.
• The author documents what it cannot do. The security policy lists five known limitations. The heaviest: the on-device WebSocket server listens on 0.0.0.0:9008 and accepts any client without a credential check, so any host that can reach the device on the same network can drive it, read the screen and use saved credentials; the document tells you to assume full control of the device. It also states plainly that there is no sandbox, that checks on risky actions are instructions to the model rather than enforcement, and that mechanical refusal is a narrow exception.

Compared with: Android automation usually takes one of two routes, ADB scripting or accessibility plus coordinate tapping. The mechanism differences here are concrete and point at named files: grid tapping replaces coordinate maths, dispatcher-level refusal is unaffected by prompt text (though it covers only a few paths), and the brain can be separated from the body so a new device is a new port rather than a rewrite. I only read this project, not the code of comparable tools, so I am not asserting what they lack.

Recent updates: v0.5.2 (10-19) fixed aiming on apps that hide their element tree. Its release notes give the numbers: commenting on a WeChat Moments post went from 64 steps and 341 seconds to 20 steps and 58 seconds, sent on the first tap. The author notes both fixes were not new capabilities but stopped wasted turns, found by measuring rather than reading code. v0.5.1 fixed two silent failures: the nightly review dying with the process, and a Xiaomi-family device's power policy killing it in the background with no visible explanation. One candid detail: the attached APK is a debug build, because the release build type has no signing config and the repository has no keystore.

Who it's for: People building on-device Android agents who accept the permission model. Three boundaries to know: an accessibility service plus a floating overlay is one of the broadest grants on Android; it can send messages in your name and it can spend money (the project says there is no payment tool and none is needed, because it taps); and the license is Apache-2.0 with additional conditions — no multi-tenant SaaS, no white-labelling that removes the branding, no embedding in another product without written authorization — so the complete repository terms need review for the intended use.

My take: ⭐⭐. The idea, a resident self rather than a feature set, is more interesting than the feature list, but this version's security boundaries are not yet where daily use would need them.

Checked: read the README, the five known limitations in the security policy, the license terms and three releases; did not install the APK or run it on a phone.

5. EverMind-AI/Raven ⭐ 5,532 · Python

GitHub: https://github.com/EverMind-AI/Raven

In one line: A host agent arranges several specialist agents into an execution graph, while a curator rewrites each one's strategy and must pass verification before installing the change.

What it is: A multi-agent runtime. Given a goal, the host agent decomposes it, matches subtasks to specialists, coordinates dependencies and integrates results. Four agents are built in (research, coding, design, on-call), and third-party agents connect through an editor-agent protocol, a CLI or OpenAI-compatible APIs. Memory and context come from a sibling long-term memory runtime, and skill retrieval goes through its own layer. The technical report is on arXiv (2609.33439), and its abstract makes the argument: as harness complexity grows and harnesses bind too tightly to one domain, the question shifts from building a stronger harness for one domain to automatically constructing specialised harnesses, improving them through experience, and orchestrating them across domains, treating each model–harness pair as a composable unit of intelligence.

What stands out:

• The agent loop is split into four replaceable seats. Memory (what a turn gets to see), planning (how to approach the work), capability (which tools an iteration exposes) and action (what to do next and how to judge it before it runs). The curator rewrites those four: sometimes a setting, sometimes a small piece of judgement code written for that agent.
• Changes pass a gate, and belong to one agent only. Nothing is installed before it is verified, and a failed check sends it back. A round's signals normally arrive with the reference answer stripped out, which limits how directly the answer is exposed. The curator is marked experimental and ships with the repository rather than the installed package.
• The config tool keeps its manners. It reads any setting without asking, asks before every write, and never takes a key through the conversation.
• Orchestration is a dependency graph. v0.2.5 added conditional branches inside workflows and delegation to remote agents on registered machines, using that machine's agent capabilities and working environment for the subtask.
• A persona is the first thing it builds. Describe the assistant you want and the curator assembles one: a lead role that talks to you plus specialists drawn from agents you already have, with your requirements landing in that assistant's harness — its division of work, the tools it may reach for, the checks it must pass.

Compared with: The difference is who rewrites the harness. Here the rewrite right sits with a separate curator, limited to one agent's four strategy seats and gated by evaluation before install. Those are concrete mechanisms to compare with another runtime. I did not check whether other agent runtimes also allow runtime rewriting, so I am not claiming this is unique.

Recent updates: v0.2.5 (10-20) strengthened multi-agent coding, added remote agent execution on registered machines, conditional branches in workflow graphs, improved native Windows support, and opened the trajectory view to everyone. v0.2.4 (10-03) added the config tool and new approval keybindings. v0.2.3 (09-27) made the bare command open a browser page. The project labels itself pre-alpha at the top of its README, and says interfaces and configuration will change quickly.

Who it's for: People researching harness self-evolution, or experimenting with replaceable strategies in their own agent systems. Three realities to accept up front: pre-alpha; a 255 MB repository that is a large engineering effort; and effect numbers in the README (172 training runs cutting a validation metric by 5.8%, an out-of-bounds fraction in a dam-break simulation going from 1 to 1.36e-10, a finite-element bisection bracket narrowing from 1800–2000 kN to 3.125 kN) that all come from the project's own reports and charts. I reproduced none of them.

My take: ⭐⭐. Copy the structure — four seats, a verification gate, stripped reference answers — not the conclusions.

Checked: read the README, the arXiv abstract, three releases and recent commits; did not install it or reproduce any benchmark.

At a glance

Project	What it is	Most distinctive bit	Who it's for	Worth digging in
NVIDIA/skills	Agent skill catalog	Signature, capability card and evaluation set as an admission gate	People using coding agents for CUDA, simulation, robotics	⭐⭐
smolvm	microVM sandbox	A live machine branches into copy-on-write children	Teams running untrusted agent code	⭐⭐⭐
pydantic-ai	Python agent SDK	Types to the tool boundary, tools callable mid-conversation	Python teams building voice and long-running agents	⭐⭐⭐
andee	On-device phone agent	Taps grid cells, not coordinates; brain separable from body	Android agent builders who accept broad permissions	⭐⭐
Raven	Multi-agent orchestration	Self-rewrites must pass verification before install	People researching harness self-evolution	⭐⭐

This week's notes

• Skill governance is starting to look like package management. Signatures, capability cards, evaluation sets, drop-on-missing — that machinery belongs to package managers and supply-chain security, and it is now being applied to "how an agent should use this SDK". Skills are turning from prompt fragments into artifacts with versions, provenance and evaluations.
• Isolation is moving down to a single execution. On one side, each workload gets its own kernel and a running machine can branch from its current state. On the other, "untrusted sources cannot touch sensitive resources" becomes a refusal inside the dispatcher. Both put the boundary in a code path instead of trusting the model — but the maturity gap is wide: smolvm documents a VM boundary that I have not tested, while andee's own security policy says its mechanical refusal covers only a few paths.
• Voice pipelines need checks beyond conversation quality. Typed interfaces and trajectory evaluations provide ways to test action selection; neither is proof that the pipeline will reject every wrong action. The reported MCP tracing advisory is a concrete reason to check affected versions and redaction behaviour, including when content capture is disabled.
• "Let the agent rewrite itself" is acquiring an auditable shape, but it is early. Splitting strategy into four seats, requiring verification before install, stripping reference answers from signals: that is a process you can discuss and reproduce. The price is that the project labels itself pre-alpha and every effect number is self-reported. At this stage it is worth reading the design and keeping the reported results separate from independent reproduction.