Skip to main content
← Back

wasmCloud Q4 Roadmap: Python SDK, Wasm vs. Containers, AI Policy

The October 7, 2026 wasmCloud community call was the Q4 planning session. Bailey Hayes named three big rocks for the quarter: a Python SDK, workload identity, and an expanded k6 suite that benchmarks WebAssembly on Kubernetes against the same app in containers and microVMs. The second half became a long discussion with Aditya Salunkhe, Yordis Prieto, and Frank Schaffa about AI-assisted contributions. It ended with a fourth rock: a permissive, written AI policy and agent stack for the project.

Key Takeaways​

  • Three big rocks for Q4. The wasmCloud Roadmap now carries a Python SDK spike (#5649), workload identity built on mTLS (#5653), and expanded k6 benchmarking (#5652). Bailey said Q4 leaves almost no slack because of KubeCon, other conferences, and the holidays
  • Python is the one new SDK maintainers will commit to. It will repeat the TypeScript and Go playbook on top of componentize-py, starting with one basic template and measuring it. A C or C++ SDK will be added only if a contributor wants to lead it. Rust templates move to WASI P3 with wstd and a new build target, and Rust 1.100 is expected to make that target stable
  • "Are we componentized yet?" becomes an SDK maturity page. Issue #5343 will track how languages differ, on a page like the existing Are We Fast Yet benchmark dashboard. Two guides are also committed: WIT interface design and composition (#5651) and choosing between WIT, HTTP, gRPC, direct SDKs, and host component plugins (#5650)
  • Workload identity goes to an RFC first. Bailey has built several prototypes and wants an architecture review before landing 5 to 10 PRs. She also wants a security-model doc that says what is and isn't a wasmCloud CVE and where the sandbox boundaries sit
  • k6 will compare Wasm with containers on Kubernetes. Jeremy Fleitz plans scenarios that run the same Go app as a container, as a Wasm workload, and on a microVM, including NATS-backed microservice hops. The plan covers cold and warm starts and resource use as well as throughput. There will be a dashboard, and the scripts will run on your own cluster
  • The main upstream risk is cooperative threads. They sit behind a flag in WASI SDK 34. Python and Go need a stable ABI before they can ship threads as stable, so wasmCloud will start with flags. Bailey is cutting WASI 0.3.2, and a new W3C subgroup on the component model in browsers has formed
  • AI-assisted contributions are welcome, with structure. Issue #5659 collects the plan: a small AGENTS.md, start from an issue that is ready for work, use drafts, add HTML artifacts to large PRs, no "slop grenades" in correspondence, optional disclosure of which model wrote a PR, and an adversarial review before filing. It will be linked from both CONTRIBUTING.md and the README

Chapters​

Meeting Notes​

The Q4 Themes​

Bailey Hayes opened the quarterly planning call with the roadmap that came out of two weeks of discussion in discussion #5619. It has four themes. The first is expanding the component ecosystem, now that upstream SDKs and WASI P3 support have matured. For Rust that is mostly a rebuild: wstd has landed WASI P3 support, so templates and examples need a different build target rather than code changes. Bailey said Rust 1.100, about five weeks out, is expected to make WASI P3 a stable target. She did not add a C++ or C SDK. Maintainers will commit to one new language, Python, and a C SDK can join the roadmap if a contributor wants to lead it.

The other three themes are performance and efficiency, integrations, and workload identity. Integrations are easy to build now that an LLM can add support for new backends, so Bailey wants them to land in awesome-wasmcloud. After several sprints of security work (hardened CI, sandboxing, and network and capability policy controls), she wants a document that says what is and isn't a CVE for wasmCloud and where its sandbox boundaries are. The goal is that a brand-new contributor can see where wasmCloud fits in the secure sandbox story.

Component Ecosystem: Python and SDK Maturity​

Bailey said the Are we componentized yet? initiative stalled last quarter because it was underspecified. It is now two pieces of work. One is a page, maybe on wasmcloud.com or its own GitHub page like the Are We Fast Yet benchmarks, that shows SDK maturity across languages so people can choose where to build. The other is the tactical Spike: Python SDK and template (#5649). It means doing what the team did for TypeScript and Go again for Python, on top of an existing Bytecode Alliance project (the issue specifies componentize-py). The issue says to create wasmCloud/python, start with one basic HTTP template and a messaging or NATS example, and measure build, startup, and memory cost. Bailey called it a spike because the deliverable is finding the gaps early. Eventually the Rust, TypeScript, Go, and Python templates should mirror each other, with each one written idiomatically for its language.

Bailey also asked Victor Adossi to lead the long-carried distributed cache for precompiled component artifacts (#5528): survey the state of the art and make sure wash-runtime has the right traits and API surface for people to plug in their own infrastructure. The awesome-wasmcloud expansion stays in draft because its work happens in that repo. Bailey said it isn't done until every category (components, host plugins, workload examples, templates, tools) has at least one entry, and she asked Aditya for ideas.

Workload Identity and the Big Rocks​

Workload identity (#5653) is a placeholder issue that Bailey will turn into an RFC. She has built several implementations to find the boundaries and the threat model. She wants an architecture review of the RFC next, after which she expects about 5 to 10 PRs. It is one of the most requested features in wasmCloud's history. The issue extends the host-wide outbound mTLS client certificate so that each workload presents its own identity.

Her rule for quarterly planning is to plan the big rocks first, the epics that must get done, and leave the roughly 50 smaller issues to come up as they will. The Python SDK, workload identity, and k6 benchmarking are this quarter's rocks. Two medium items requested on earlier calls also made the roadmap: WIT interface design and composition best practices (#5651), and a guide on when to use WIT at all versus HTTP, gRPC, direct SDKs, or host component plugins (#5650). Two items carried over. Publishing the wash-runtime crate (#5030) "should take five minutes," but once it ships Bailey will have to be very careful about breaking changes. A connection pool example for the wasi:sockets host plugin (#5053) already has a draft up.

k6: WebAssembly vs. Containers on Kubernetes​

Jeremy Fleitz recapped Q3. wasmCloud now has a base set of k6 load tests in CI, with scripts in the repo that run locally or against your own Kubernetes cluster, covering fan-out calls and chained requests between workloads. With KubeCon + CloudNativeCon North America about a month away, #5652 aims to show the Kubernetes ecosystem how a wasmCloud deployment compares with other ways to run the same app. For example, a simple Go service in a scratch or UBI-minimal container pod would be benchmarked against the same Go code compiled to a Wasm component on a host. With KEDA autoscaling in place there are many knobs to compare: host counts, autoscaling workloads on and across hosts, and microservice flows where every hop goes through NATS. Comparisons against microVMs are planned too.

Bailey said the question she gets most is "how does this compare to native?" There are many kinds of native, and "is Wasm fast" covers more than requests per second: cold starts, warm starts, and resource use. Today she points people at the Are We Fast Yet dashboard, which CI publishes to on every release and which compares WASI P2 and P3. She wants to see wasmCloud against containers next. Jeremy added that there will be a k6 dashboard, but the scripts matter more. You can run them yourself instead of taking the project's word for it, and tune pool size and max concurrency for your own components. Bailey described it as a framework for reproducing cluster-specific problems and adding regression tests, though the release benchmark suite has to stay short.

Upstream Dependencies: Cooperative Threads​

Jeremy asked whether anything upstream could block the quarter. Bailey said cooperative threads are the main risk. They are behind a flag in WASI SDK 34, and CPython's main branch now depends on that SDK, but the flag isn't turned on and the specs haven't been surfaced yet. A Python PEP for publishing WASI-built artifacts in wheels has been approved. It would let Python packages with native dependencies link into a single .wasm. Python and Go need a stable ABI before they can treat threads as stable, and that won't be official until the next WASI release. So wasmCloud will make everything work behind flags first, much as people already use componentize-py with flags to get the latest features. Bailey's demo of cooperative threads in big Go a few weeks ago needed no changes to the Go source and found bugs that have since been fixed. Python should work the same way, except that wasmCloud will be the one flipping the flags in its SDK.

Most other component model work is about what browsers need to implement the component model natively. The day before, the W3C WebAssembly group chartered a new subgroup on the component model, which affects JCO, maintained by Victor. Bailey is pressing the button on WASI 0.3.2 the following week and will then update wasmCloud's dependency, which she expects to be additive and transparent. The WASI APIs to watch this quarter are WASI TLS, WASI OTel, WASI Graphics, and possibly sockets.

AI-Assisted Contributions: Issues First, Drafts Welcome​

Aditya Salunkhe raised the topic that took up the rest of the call. Now that new contributors can point an LLM at anything, maintainers end up as an extra layer between a reviewer and a person relaying an LLM. He asked that unsolicited work start as a detailed issue, drafted and revised before any PR. Bailey agreed, and noted that many open source projects have started refusing pull requests. She isn't ready for that. She has learned that an issue has to say exactly what she means, because someone will point an LLM at it. Issues that aren't specified yet stay in triage.

Yordis Prieto called the Crossplane AI policy the most professional and AI-friendly he has seen, because it is about owning your work rather than about AI. He has adopted it for his own projects. Bailey, who sits on the Bytecode Alliance Technical Steering Committee and helped write its AI tool policy, described that policy as stricter than some. It bans attributing commits to an agent, which also works as a test of whether a contributor read the policy. Yordis said he had missed it because it wasn't linked from the repos he contributed to. Bailey committed to linking wasmCloud's policy from both CONTRIBUTING.md and the README.

Yordis warned that "open an issue first" has limits. His example was the word "biscuit," which means different things to Americans and Brits, and AI-written threads full of the same kind of mismatch. Sometimes reading the code is faster. He also suggested labels to filter noisy PRs. Bailey prefers drafts: anyone who wants to collaborate on code should open a draft, and she still looks at drafts and redirects ones that are off course. Yordis agreed and said he insists his team use drafts properly. Bailey proposed closing drafts after two months without activity. Yordis prefers a stale label, but Bailey said stale bots flood the notifications of people who watch hundreds of repos.

LLMs Read the Docs Now​

When Yordis joked that this was a "Bailey problem" that needed a Bailey MCP server, Liam Randall said Claude often quotes Bailey to him and links to wasmCloud community meeting pages. That was deliberate. In February, Bailey and Liam saw in a metrics review that LLMs were reading the docs more than people, so the team decided to write for LLMs. Eric Gregory spent months on the underlying engineering for the new wasmcloud.com/community pages. Liam said agentic citations are increasing, and that "when LLMs have questions, they call Bailey."

HTML Artifacts, Linters, and No Slop Grenades​

Aditya shared Andrej Karpathy's LLM usage rules and suggested ASD-STE100, the aerospace Simplified Technical English standard, as a way to cut AI fluff in PR text. He also suggested that a large PR include an HTML artifact that walks through how it works, plus diagrams. A 5,000-line PR is hard to review without one. Bailey added explainer videos as an option, though Aditya later said that was too much, except perhaps for UI changes, which the deploy preview already covers. Bailey pointed to noslopgrenade.com. If she asks a yes-or-no question, she wants a yes or no, with anything more below it. Half her chats come back as an unrequested essay. Yordis's advice was to turn every recurring review complaint into a linter. He leans on Dylint, and Bailey added "Should we add Dylint?" to the issue.

Where Design Context Belongs​

Yordis described a component model annotation proposal he wrote with AI help, deliberately loading the README with decision context and research from other languages. After Luke Wagner said it read like AI slop, he trimmed it down, and he asked what he should have done. Bailey suggested an HTML artifact for intent and design decisions, separate from what reviewers need to read and retain, or a dedicated proposal repo, which is how WebAssembly proposals worked before AI. Frank Schaffa suggested a separate folder of decision context in the repo, so users don't have to wade through it. Bailey said it depends on the project, and she is open to bringing back architecture decision records, which wasmCloud skipped for v2 because they were extra work and LLMs now make them cheaper. Her conclusion was that "if we don't have a permissive policy for AI use, we're going to be left behind."

The thread came back to communication between people. Yordis said his team talks to him through Claude and that it removes defensiveness. Bailey's line is that if she, as a human, asks a person something, she expects the person to have read it before replying. Whether they use a tool to write the reply doesn't matter to her. Her problem is replies regurgitated through an LLM by someone who never read the question.

Model Disclosure, AGENTS.md, and Skills​

Bailey said the Bytecode Alliance policy is stricter than she wants for wasmCloud. She doesn't want to ask people to git commit --amend away an agent trailer (getting people to sign the DCO is hard enough), and she won't require model disclosure the way LLVM does. Instead the policy will say that wasmCloud welcomes a note about which model or agent wrote a PR, so a reviewer can use a different model for a second opinion. Aditya liked the idea of a refuting agent from a different model. Yordis objected to giving AI companies free marketing.

On skills, Yordis said AGENTS.md has become close to a cross-agent standard, that Claude is the last major agent without native .agents/skills support (he symlinks .claude/skills until it has it), and that AGENTS.md should stay as small as possible. It loads on every prompt in some harnesses, so it should hold only the mistakes agents keep making, with everything else in docs. His team keeps skills in a separate repo so they can change quickly. Bailey wants wasmCloud to depend only on open source or foundation-owned tooling it is willing to maintain. She will publish her own agent stack separately, under her ricochet handle or Cosmonic Labs, for anyone who wants to copy it. Yordis showed a skills-eval workflow in his TrogonStack rusty-monorepo, which measures whether loading a skill improves an agent's results.

One rule did make the AGENTS.md list: run at least one adversarial review before filing a PR. Bailey said the AI is very good at finding the low-hanging bugs in a first draft, while her value as a reviewer is judging architecture fit, maintainability, and long-term cost. She described her own review routine. She reads the PR, writes a sentence to her agent about how she understands it and what worries her (regression history, test coverage, security, allocations), and then has the agent check her. She does this to keep her brain switched on, and she won't prescribe it to anyone.

Lints, Codegen, and a New Big Rock​

Yordis showed his trogon_dylint_lints crate and OpenTelemetry Weaver templates. He tries to generate as much code as possible from static data such as JSON Schema and YAML, so that errors, logs, and metrics are data rather than hand-written code. Bailey noted that wasmCloud has been adding the pedantic Clippy and rustc lints one at a time across the repo. She has refused to debate style in PR review since Titus Winters introduced clang-format at CppCon in 2014.

Bailey closed by naming a new big rock: defining wasmCloud's AI tool stack. It will never be done and will roll from quarter to quarter. She stressed that everyone on the call uses AI tools, that they are welcome, and that using them to communicate is fine too, especially for the many contributors who don't speak English as a first language.

WebAssembly News and Updates​

This week in webassembly news: cooperative threads are behind a flag in WASI SDK 34, and CPython's main branch now builds against it. An approved Python PEP clears the way for WASI-built wheels. Both feed the Bytecode Alliance work that will let Python and Go ship threads in the component model once WASI stabilizes the ABI. The W3C WebAssembly community group has a new subgroup on implementing the component model in browsers, WASI 0.3.2 is due the following week, and WASI TLS, OTel, and Graphics are the WASI APIs to watch. In Rust, wstd supports WASI P3 and Rust 1.100 is expected to stabilize the target. AI contribution policies are spreading through open source: Crossplane, the Bytecode Alliance, and soon wasmCloud.

What is wasmCloud?​

wasmCloud is a CNCF project for building applications out of WebAssembly components and running them across cloud, edge, and Kubernetes clusters. The Wasm component model lets you write business logic in Rust, Go, Python, TypeScript, C#, Java, and more. The platform supplies capabilities like HTTP, messaging, key-value storage, blob storage, and observability through standard interfaces and a pluggable host plugin architecture backed by Wasmtime. wash is the developer shell for building, running, deploying, and debugging. The runtime operator schedules Wasm workloads on Kubernetes the same way you schedule containers, with WASI Preview 3 support on by default. Together they give you a production platform for WebAssembly on Kubernetes and at the edge.

Topic Deep Dive: Benchmarking WebAssembly on Kubernetes Against Containers​

Most WebAssembly Kubernetes benchmarks answer a narrow question, usually requests per second on a warm path. The Q4 k6 work aims to answer the question platform teams actually ask: if I run this service as a Wasm workload instead of a container, what changes? The plan holds the application constant. The same Go service runs as a scratch or UBI-minimal container pod, as a component on a wasmCloud host scheduled by the runtime operator, and on a microVM. All three are driven by the same k6 scenarios. Those scenarios go beyond throughput to cold-start and warm-start latency, CPU and memory per instance, and behavior under scale-out with KEDA. They also include the microservice shape, where every hop crosses NATS, because that is where per-request overhead adds up.

The scripts may matter more than the published dashboard. They run in CI, on a laptop, or against your own cluster, and they expose the knobs that change the answer, such as instance pool size and max concurrency. That makes the suite a framework for reproducing a problem specific to your cluster and contributing it back as a regression test. For background, see how components work in wasmCloud, the Kubernetes operator, and lightweight deployments.

Who Should Watch This​

Python developers evaluating WebAssembly should start with the Python SDK spike at 6:32 and the cooperative-threads risk at 18:38. Platform engineers comparing Wasm and containers on Kubernetes will want Jeremy Fleitz's k6 plan at 12:11. Open source maintainers drafting an AI contribution policy should watch from 26:02 through the AGENTS.md and adversarial-review discussion at 1:10:06.

Up Next​

Expect the workload identity RFC and its architecture review, the first commit to a wasmCloud/python SDK repo, and new k6 Kubernetes scenarios ahead of KubeCon North America. Bailey Hayes will turn the CONTRIBUTING-for-LLMs issue (#5659) into a written AI policy with a small AGENTS.md, linked from CONTRIBUTING.md and the README. Bailey said topics that didn't fit can go on next week's agenda, and issues are welcome in the meantime.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →