Each day I pick five projects that are rising on GitHub this week, 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-18.

Feature, security and performance descriptions come from project documentation; I did not independently validate claims unless an entry says so.

None of today's five projects is a model. Each one handles a different part of running an agent: remembering, running long, managing skills, holding permissions, and staying visible.

1. akitaonrails/ai-memory ⭐ 9,999 · Rust

GitHub: https://github.com/akitaonrails/ai-memory

In one line: Long-term memory for coding agents, stored as a git-backed markdown wiki shared by more than twenty agent runtimes.

What it is: Close one agent mid-task, open another in the same directory, and the new one has no idea what you tried or which approach failed. This single Rust binary fills that gap: lifecycle hooks capture sessions silently, session end compiles them into wiki pages, the next session gets a bounded brief, and unfinished work is handed over as a typed record. The repo was created in May 2026 and reached 9,999 stars, 725 forks and 150 contributors in five months. The release count is truncated at GitHub's 100-per-page limit; the last three days alone shipped v3.0.1, v3.1.0 and v3.1.1.

What stands out:

Markdown is the source of truth; the index is disposable. Pages are plain .md: grep them, open them in Obsidian, edit by hand, rsync them. SQLite is a derived index that can always be rebuilt, and there is no vector store to maintain. The useful property is that the source pages remain inspectable even if an index must be rebuilt; plain text alone does not prevent corruption.
A handoff can be claimed exactly once. Handoffs are not free text but typed records with an owner, invalidated after one claim. That mechanism is intended to prevent two workers from claiming the same handoff; it does not guarantee that all downstream work is performed exactly once.
The default path makes zero LLM calls, including aging. Capture, search, injection and handoff need no API key. Per-tier decay curves, access-weighted retention (opening, searching or linking to a page counts as use), compression of cold notes into durable facts, near-duplicate merging and contradiction flagging are all deterministic. Rewrite-and-drop operations are off by default, nothing is hard-deleted, and restore-page brings old versions back.
The recall numbers are self-measured and labelled as not comparable. On LongMemEval-S (470 questions), hit@5 was 0.666 zero-LLM and 0.815 with local embeddings on the 2.6 line; with the 3.0 observation stream on, it rose to 0.951 zero-LLM and 0.945 with local embeddings. The project's comparison document lists these figures and explains that Mem0 and Zep publish end-to-end QA accuracy, a different measurement.
Team features are not a paid tier. Multi-user auth, per-person attribution and an audit log are built in. The project reports a measured write ceiling of roughly 700 operations per second; I did not reproduce it.

Compared with: Mem0 and LangMem extract atomic facts per turn and leave opaque fact rows behind; Zep and Graphiti offer typed edges over time but require a graph database and an LLM in the loop; basic-memory also treats markdown as truth but has no automatic capture, cross-agent handoff or multi-user sharing. The split is not the retrieval algorithm. It is who owns the artifact and whether a human can edit it.

Recent updates: v3.1.1 (2026-10-17) stopped lint findings from counting expired pages and aligned curator TTL behaviour with the docs; v3.1.0 (10-16) and v3.0.1 (10-15) were consecutive patches on the 3.x line. The latest commit merged PR #1390 at 19:50 UTC on 10-17.

Who it's for: People running two or three coding agents at once, or resuming the same work on another machine. Two caveats: support for some runtimes is MCP-only, with no hook capture, so they can read but not record automatically; native Windows remains experimental, and WSL2 is the safer path.

My take: ⭐⭐⭐. Unusually restrained for a memory tool: no API spend by default, rewrites gated behind an eval before they can become default, and deleted pages recoverable. The two mechanisms worth copying are claim-once handoffs and access-weighted retention.

Checked: read the README, release list, recent commits and its own benchmark documents; did not install it.

2. AMAP-ML/LongHorizon-Harness ⭐ 1,750 · Python

GitHub: https://github.com/AMAP-ML/LongHorizon-Harness

In one line: An execution loop wrapped around an existing coding agent that splits long work into bounded rounds, each run in a fresh context and independently verified before it counts.

What it is: A long-horizon shell for CLI agents such as Claude Code, Codex and OpenCode. Give it a goal once, and it repeats four steps: cut the next bounded step, perform it on a desktop app or in the terminal, check the real artifact (files, UI, logs, tests), and record only what passed as progress. After a context refresh, a failed action or a rejected deliverable, the next round restarts from the original goal plus the last verified checkpoint. The academic side is hot, with arXiv 2608.01964 and a number-one spot on the Hugging Face Daily Papers weekly ranking on 2026-08-06. The engineering side has cooled: all eight releases landed between 14 and 20 August, with no new commits through 18 October.

What stands out:

Three roles are boundaries, not three agents growing their own copies of the task. The Manager rebuilds state each round from the original goal, verified progress and failure evidence. The Executor gets a fresh context and does one step. The Auditor independently inspects real files and interfaces instead of trusting the Executor's claim. Anything that fails verification is demoted to evidence and not counted as progress. That rule makes an unsupported completion claim easier to catch.
Fresh context is a design choice, not a side effect. The Executor carries no conversation history from the previous round, only the rebuilt state. Long tasks usually die of context rot; this design reopens the context and lets state files carry memory.
Same backbone, same model, different harness, large gap. The paper reports a comparison using Qwen 3.7-Plus as the backbone and Claude Code as the execution backend: WeaveBench (114 tasks) pass rate went from 51.8 to 80.7; OSWorld 2.0 (108 tasks) binary completion went from 2.8 to 8.3, a threefold gain; Terminal-Bench 2.1 success went from 69.7 to 77.2 while using 24% fewer tokens.
Each role can use a different model and permission scope. Manager, Executor and Auditor can be assigned separate backends and models, with read and write ranges narrowed per role. Separate role models and permissions provide explicit cost and access controls.
A finished run is not a dead end. v0.1.7 turned completed runs into continuable conversations, with messages sent mid-round claimed by the next round. A stop request escalates to a force stop only when a worker ignores it.

Compared with: OpenHands and similar platforms take over the agent along with the loop; this one keeps the model and CLI you already use and only owns the loop, so a broken layer can be swapped alone. Compared with the sub-agents built into Claude Code, verification is a separate role instead of self-review, and state lives on disk, so it survives across processes and days. Compared with AutoGPT-style self-loops, it adds a read-only Auditor and the hard rule that unverified work is not progress.

Recent updates: v0.1.7 (2026-08-20) lets a finished run continue as a conversation from its existing round ledger, adds --reasoning-effort per role, fails a round rather than the whole run when only a guard fails (#28), and recovers from an isolated EBADF in control-bus reads (#33). v0.1.6 (08-17) added OpenCode and one more CLI backend adapter.

Who it's for: Anyone who needs an agent to work for hours and still be able to say exactly how far it got. Two caveats: the repo has had no commits for two months, so long-term maintenance is a risk, and the README states it has only been tested on macOS, with Windows support included but not thoroughly tested.

My take: ⭐⭐⭐. It turns "long tasks" from a prompt problem into a state-machine problem, and backs it with a same-backend comparison. Even without installing it, the division of responsibilities across the three roles is worth copying.

Checked: read the README, all eight release notes, recent commits and the paper link; did not install it.

3. MadsLorentzen/ai-job-search ⭐ 50,666 · Python

GitHub: https://github.com/MadsLorentzen/ai-job-search

In one line: A skill library that turns a coding agent into a job-application pipeline: scrape postings, score fit on five dimensions, tailor the CV and cover letter, then have a second agent criticise the drafts.

What it is: An end-to-end workflow you fork, fill with a profile and run. It ships 12 slash commands (/setup, /scrape, /rank, /apply, /interview, /outcome and others) plus six job-portal skill directories. The author is a geophysicist by training who lost his position in late 2025 and used this workflow for his own search: 69 tailored applications, 20 first interviews, one signed contract, and a start as an AI engineer in June 2026. The repo is only 4,679 KB, with 10 releases and 78 contributors. The weight is in the process and text contracts, not in code volume.

What stands out:

Each skill is a self-contained directory with a hard contract. SKILL.md carries an enabled: flag, a search / detail CLI and --format json|table|plain output, plus its own tests. /scrape auto-discovers any skill that follows the contract, with no registry; /add-portal generates new ones.
CI lints the skills themselves. A lint_skills.py script checks consistency across skills, commands and settings.json. Skills are artifacts managed like code, not scattered prompts.
The drafter and the reviewer have separate contexts. After the drafting agent finishes, a reviewer with a fresh context researches the company and critiques the drafts. Drafts arrive inline rather than being re-read from files, and every claim must map back to the profile, so skills and experience cannot be invented.
Job postings are treated as untrusted input. The workflow does not follow instructions embedded in a posting and does not fetch links from its body, and it says plainly that this is instruction-level defence rather than a sandbox. A security statement written this way is more useful than one claiming hardening.
The fork privacy trap is placed where it cannot be missed. A fork of a public repo is always public, while setup writes your name, contact details and salary expectations into tracked files. For personal use, the advice is a private repo with the original as upstream.

Compared with: Resume SaaS products such as Rezi and Teal handle layout and keywords, not search, fit scoring or feedback after applying. Prompt collections offer phrasing with no executable entry point and no tests. This sits in between: capabilities with CLI boundaries, enabled flags and CI, producing local LaTeX files. The cost is a hard dependency on a toolchain with no free tier.

Recent updates: v1.7.2 (2026-09-29) was about making documented checks actually run: compiled PDFs are measured rather than eyeballed, portal CLIs stop trusting digits in a URL, and Python tools handle non-ASCII input. An earlier v1.7.0 fixed a real privacy leak, where gh repo fork --clone set the upstream repo as default and automation then filed issues upstream.

Who it's for: People job hunting who will maintain their own profile, and anyone writing skill libraries for an agent, since the directory structure and review protocol transfer directly. Note the paid Claude Code subscription and the LaTeX toolchain, and that the portal skills target the Danish market.

My take: ⭐⭐. As a job tool it is niche; as a sample of how to organise a skill library it is valuable. Contract, switch, tests and lint, all four present.

Checked: read the README, release notes and recent commits, and counted the command and skill directories; did not install it.

4. NVIDIA/NemoClaw ⭐ 22,764 · TypeScript

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

In one line: A vendor reference stack for running off-the-shelf agent runtimes inside sandboxes, covering inference routing, network egress, credentials and state lifecycle.

What it is: NVIDIA's answer to "how do I run someone else's agent safely". It does not implement an agent. It supports three runtimes (OpenClaw by default), installs them with configuration, tools and credentials into OpenShell sandboxes, and wraps the result in a versioned blueprint. A host CLI handles install, readiness checks, onboarding and daily operations; the gateway handles sandbox lifecycle, credentials, network policy, inference routing and approved egress. The repo is about 476 MB with 185 contributors, 797 open issues and pull-request numbers already past #13377. But it has been an early preview since 2026-03-16, the documentation is only at v0.0.135, and the single GitHub release is a CI toolchain snapshot from 1 October, not a product version.

What stands out:

Four protection layers, with an explicit split between hot-reloadable and locked. Network blocks unauthorised egress and reloads at runtime; inference reroutes model calls to controlled backends and also reloads; filesystem makes system paths read-only, opens only /sandbox and /tmp, and is locked at sandbox creation; process blocks privilege escalation and dangerous syscalls, also locked. Which layer can change and which requires a rebuild matters more than the protection itself.
An unauthorised request becomes a human approval. When an agent reaches an unapproved host, the gateway blocks it and surfaces the request in the terminal interface for an operator to approve. Approved endpoints persist only within the current sandbox instance and are not written back to the baseline policy file, so a temporary exception does not become a permanent backdoor.
Credentials are scoped handles, not raw keys. Configuration stores references. Switching an inference provider stores a handle, and a rebuild refreshes it only when the endpoint and credential key match the current binding; user-managed credentials are left alone.
Failures must be explained by the agent. The runtime context tells agents to try allowed network and filesystem actions first, then report whether policy denial, DNS, timeout, TLS or file access caused the failure. That distinction is what makes debugging and auditing possible.
An install path written for an agent to read. A starter prompt lets a local coding agent walk a human through setup: one question at a time, commands only with approval, secrets kept out of the chat.

Compared with: Code-execution sandboxes such as E2B and Daytona sandbox "running a piece of code"; this sandboxes a whole agent runtime, with inference, MCP credentials, egress and state inside the boundary. Compared with wrapping an agent in Docker yourself, the difference is not the container but the policy lifecycle: a baseline policy, in-instance temporary approvals, and the line between hot reload and locked configuration. Most DIY setups have none of that. The cost is binding to NVIDIA's OpenShell and to DGX or WSL hosts.

Recent updates: v0.0.135 (2026-10-15) strengthened credential handling, sandbox recovery and failure diagnostics; managed tool gateways moved to a dedicated provider profile with an opaque broker token, verified before creation or reuse (#13102); inference rejects non-canonical URLs that resolve to NVIDIA's own endpoint (#12925); new sandboxes default to progressive tool disclosure (#13173).

Who it's for: Teams that deploy third-party agents at scale and must explain the boundary to security or compliance. It is still alpha, and the README says maintainers respond on a best-effort basis with no promised timelines. The hardware requirements are also high.

My take: ⭐⭐. It is not something most people should install, but the four-layer split and the rule that temporary approvals stay out of the baseline make a good self-check list for any agent system.

Checked: read the README, NVIDIA's architecture and release-notes pages and recent commits; did not install it.

5. penso/herdr-gpui ⭐ 1,476 · Rust

GitHub: https://github.com/penso/herdr-gpui

In one line: A third-party native desktop client for an agent runtime, putting workspaces, worktrees, per-agent status and terminals on one screen.

What it is: Herdr is a runtime that keeps coding agents alive (herdrdev/herdr, 44,531 stars, Apache-2.0), with agents running in a daemon that survives closing a window. This repo is a third-party GUI for it, and the author states plainly that it is unaffiliated with the official project. The client does not install or start the daemon; it only views and operates. It was created on 2026-09-20, shipped 41 releases in a month (10-13, 10-14 and 10-16 back to back) and has 53 contributors.

What stands out:

It does not emulate a terminal; it paints cells. It connects to the daemon's client socket, receives the terminal grid and draws it, split panes included. Solid box-drawing characters, block elements and four powerline separators are drawn on the cell grid with edges aligned to device pixels, so a full-cell border is not clipped by line spacing. Painting instead of embedding means the same session can be rendered by several front ends at once.
One task, one worktree, as the default posture. The sidebar lists worktrees per repository, with right-click actions to create, rename, fan out or close, and a one-click removal after the pull request merges.
Teleport moves a worktree to another machine. The project describes moving commits, uncommitted changes, tabs, splits, running programs and agent sessions together. I did not test whether a running process continues or is reconstructed on the destination. tmux alone does not provide that worktree-transfer workflow.
Review notes go straight back into the session. Open a diff, leave line comments, send them to the agent; in a browser tab you can select an element, annotate it and send it back. The human-looks-at-result loop is built into the interface.
Status is a first-class object. Each agent carries a status dot: idle, working, waiting for you. Needing a human triggers system notifications, sounds and a Dock badge, and the status bar shows remaining plan quota for the AI services in use.
Performance has a reproducible contract. A synthetic fixture with 160x50 cells, 40 workspaces and 40 agents drives real mouse events through the framework's event dispatch, with a configurable p95 budget (250 ms by default in release builds, calibrated to 30 ms on the author's machine).

Compared with: tmux and zellij manage terminal sessions and do not know which pane holds which agent or who it is waiting for; terminals embedded in editors run commands but leave worktrees and status for you to track. The sibling herdr-web-ui (1,153 stars) wins on remote reach through browser and phone, while this client wins on native rendering and desktop interaction. The real distance comes from the combination: native rendering, worktrees as first-class objects, and cross-machine teleport.

Recent updates: v20261016.1 (2026-10-16) added network latency and loss to the status bar and made sidebar devices draggable; v20261014.1 (10-15) let a tab torn out of a window become a new window, moved panes to another device, and rendered markdown in browser tabs; v20261013.1 (10-13) removed worktrees after merge, teleported worktrees between cloud devices and added a CLI to control the running app.

Who it's for: People running a dozen agent sessions, mostly on macOS. It requires an existing Herdr daemon; the Linux packages and Windows build are marked experimental, and macOS needs 14.2 or newer.

My take: ⭐⭐. Without the daemon it is not installable for most people, but one-task-one-worktree, status dots and review-to-session are the three ideas worth taking, more than the rendering tricks.

Checked: read the README, the in-repo performance report, all 41 release notes and recent commits; did not install it.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deep look
ai-memory	Long-term memory for coding agents	Markdown as truth, claim-once handoffs	People running several agents or switching machines	⭐⭐⭐
LongHorizon-Harness	Long-horizon execution loop	An independent Auditor, unverified work is not progress	People whose agents must work for hours	⭐⭐⭐
ai-job-search	Job-search skill library	Skills with CLI contracts, tests and CI lint	Skill-library authors, job seekers	⭐⭐
NemoClaw	Agent sandbox reference stack	Four layers, hot-reload vs locked	Teams that must document an agent boundary	⭐⭐
herdr-gpui	Agent session desktop client	Worktrees as objects, cross-machine teleport	Multi-session users on macOS	⭐⭐

This week's notes

Today's five selections focus on the agent operations layer. Not one of the five is a model: memory, loop, skills, sandbox, session interface. Together they cover an agent from remembering to staying visible. These are useful comparison points even when two products use the same model.
The memory argument has shifted to who owns the file. Whether a human can grep it, edit it, and recover it after deletion matters more for long-term use than a retrieval score. The project retrieval score applies to its own evaluation setup; it does not establish that every memory workflow can dispense with model calls.
The ceiling on long tasks is who verifies. Same backend, same model, only the loop changed, and the pass rate moved from 51.8 to 80.7. That reported comparison gives a reason to test independent verification while keeping the model fixed.
Skill libraries are acquiring engineering constraints. A switch, a CLI contract, tests and CI: once those four are present, a skill becomes a module. Without them, any number of skills is still a pile of prompts.

Heartiger · 十方空烬