New AI projects on Hugging Face or GitHub, May 20 2026. The one worth opening is an agent that learned to QA-test its own work.

Why a dated question has no dated answer

People search for new projects by date because that is how news works, but neither Hugging Face nor GitHub thinks in days. A model card carries a last-modified timestamp, not a release date. A trending repository climbed because of stars accrued over a week, not because it launched this morning. The closest thing to a true daily record is the one artifact both platforms agree on: the commit log. A commit has an author, a message, and a timestamp to the second, and you cannot retouch it after the fact without leaving a trace.

So the honest way to answer "what was new on May 20" is to pick a project whose log you can read and open the day itself. Fazm is a useful subject because it is fully open source, it wraps the real Claude Code and Codex agent loops rather than reimplementing them, and it ships often enough that a single day is a real slice of work rather than a quiet gap.

The capability that landed: an agent that tests what it ships

Fazm already drives your real browser. The May 20 work closed the obvious loop: if the agent can write a web app and open it in Chrome, it should also be able to test it there. Twelve commits did that by bundling @assrt-ai/assrt as a sibling MCP server and registering it inside the agent bridge. The headline commit, 9db5fc85, added 52 lines to acp-bridge/src/index.ts to spin up a server named assrt running on the bundled Node binary.

The tools it exposes are the spine of a QA loop: assrt_plan reads a running page and drafts test scenarios, assrt_test runs a scenario and returns structured pass or fail with screenshots, and assrt_diagnose does root-cause analysis on a failure. Three more tools, assrt_seed_cookies, assrt_seed_localstorage, and assrt_seed_indexeddb, prime a logged-in state before a run so the agent can test flows that live behind a sign-in.

One tool stays conditional. assrt_analyze_video only registers when a GEMINI_API_KEY is set, because reviewing a recorded run is the one step that needs an outside multimodal model. The bridge passes that key through if present and leaves the tool dark if not.

What one QA pass looks like in the agent loop

The flow stays inside the same window the agent already works in. There is no separate dashboard and no CI step. The agent calls a tool, the assrt server drives the managed Chrome, and the result comes back as something the model can act on.

The detail that makes it Fazm and not a CI runner

The registration in index.ts pins ASSRT_CDP_ENDPOINT to http://127.0.0.1:9655, the same managed Chrome port the existing browser-harness flow uses. That single line is the whole philosophy. Tests do not run in a fresh headless container that knows nothing about you. They run in the actual Chrome the agent drives, with your cookies and your session, on the port the rest of the product already speaks to. When browser-harness is not running, the assrt server auto-spawns its own Chrome with a persistent profile at ~/.assrt/managed-chrome, so the state survives between runs.

A second commit, c1a59b9c, added a FAZM_ASSRT_ENABLED gate in ACPBridge.swift. The bridge only sets that variable when an assrtEnabled flag is on, and that flag is a toggle in Settings under Browser Automation. The v2.9.32 changelog calls it an "optional Assrt QA testing MCP (beta)". A tool that can click around inside your logged-in browser should be off until you ask for it, and it is.

Verify it yourself in four commands

None of this needs to be taken on faith. The repository is public and every claim above is a dated artifact you can pull up in under a minute.

The work landed in the commit log on 2026-05-20 but shipped to users the following day, in v2.9.32 dated 2026-05-21. That gap is normal: code lands, a release rolls it up, and the changelog records the version, not the commit hour. If you want the hour, the commit timestamps have it. Commit 9db5fc85 is stamped 17:15 Pacific, and the FAZM_ASSRT_ENABLED gate two minutes before it.

Why this belongs inside the agent, not beside it

The reason a QA engine is interesting as a desktop-agent feature rather than a standalone product is context. The agent that wrote the code already holds the full conversation that produced it, already controls the browser the app is running in, and already has your session loaded. A separate testing tool starts from zero on all three. Wiring assrt in as a sibling MCP server means the model can write a change, open the running app in the Chrome it controls, walk the flow, read the console and the network tab, and fold the failures back into the next edit without ever leaving the window.

That is the same instinct behind every other reach Fazm makes past the terminal. The agent uses real accessibility APIs and a real browser rather than screenshots, which is why it can act on what it sees instead of guessing at pixels. QA testing is the natural extension: not a new kind of magic, just the agent using the browser it already has to check its own work before handing it to you.

How to read any project's real May 20

The method generalizes to any repository that catches your eye on Hugging Face or GitHub. Skip the README, which is marketing, and read three dated artifacts in order. The changelog, which the maintainer authors and ties to versions. The commit log for the day you care about, which shows what landed and when. Then one diff, where the inline comments and the registration calls tell you what the change actually wires together.

If the changelog is stale, the commits are a single launch push, and the diffs carry no real wiring, you are looking at a project running on momentum. Fazm's May 20 passes all three checks, which is the only reason a dated question is worth answering with one capability instead of a list of ten trending repositories you will forget by lunch.