Open Source Radar · 2026-11-04: Agent frameworks separate kernels and capabilities

By Renchao Wu. Originally published on widechaos.cn.

This issue covers five projects drawn from one candidate pull on 2026-11-04: a pool of 95 entries, a de-duplication ledger of 313, and 12 candidates as the script's default output limit. The daily GitHub Trending fetch timed out during that pull (the script records it under errors); the weekly Trending entry point and topic searches did return results, and those two paths supplied the candidates. I picked five on three grounds: whether the approach can be borrowed by another system, whether it offers a distinctive mechanism, and only then heat. For each project I read the README, the release notes where a release exists, and recent commits. Nothing was installed or run, so nothing below is my own measured claim about performance, deployment or stability; where a deployment shape or speed change comes from the project's own docs, the text says so.

1. miuuyy/Octopus-SI-OS ⭐ 679 · Rust

GitHub: https://github.com/miuuyy/Octopus-SI-OS

In one line: An agent runtime rebuilt on operating-system lines: eight primitives in the kernel, models and tools outside it, and an agent that can rewrite its own interfaces and tools when policy allows.

What it is: A research-preview agent desktop system for macOS 14 and later. The repository was created on 2026-10-09 and had 679 stars and 73 forks by 11-04. The README and docs/architecture.md tell the same story: a kernel of roughly 45,000 lines of Rust, with Codex CLI moved in and running as one interface among many. The documentation describes a small set of primitives plus JSON descriptors for mounting capabilities. That design claim does not establish that every new capability requires no implementation work.

What stands out:

• Eight primitives and no orchestrator. Interface (a typed port), Artifact (the only thing that crosses a boundary), Run (a durable execution record that parks and wakes on artifacts; it is data, not a process), Execution environment (a goal with a policy; environments nest and inner ones are narrower), Worker (a role plus a ceiling, not a program), Worker environment (the room where tools act), Policy (never stored, formed on each arrival), and Mark (recorded only after a verifier passes).
• The kernel decodes nothing and pushes nothing. Resident interfaces such as providers, channels and tool rooms are each their own process reading their own movements; a worker is only a descriptor plus a policy ceiling, with no code. The provider interface builds what the model sees, and the room's door checks a tool against the grant before running it. One turn is a set of rows in a ledger.
• A refusal is also a row. Blocked calls are recorded with a type instead of being dropped silently. This can make refusals available for audit, subject to what the implementation actually records.
• Authority is formed per call. Policy is computed at each arrival, and because environments nest with narrower inner ones, tightening permissions means moving a task into a smaller environment rather than writing a second set of checks.
• The system can build itself a sense. The README's example: a run needs to "see" and has no capability for it, so the system dispatches a coder run that writes a small camera driver, registers it as a new interface folder, and once a verifier passes, the descriptor is picked up live. The example describes reusing the registered interface on a later run; I did not test it or its verifier.
• The limits are stated plainly. The README note says that for an ordinary coding task, Octopus today gives you nothing that Codex CLI does not already give you. The research question is whether an architecture that lets agents reshape their execution environment helps them take initiative.

Compared with: The usual approach is a loop with tools, memory, sub-agents and schedules bolted on, where capabilities arrive as hooks inside the loop. Octopus puts capabilities outside the kernel and mounts them through descriptors, so descriptors can expose capability definitions for inspection. That alone does not prove deterministic replay or safe live changes. Its own admission that it adds almost nothing for coding tasks is what separates it from yet another agent desktop shell. I did not read primary material on other self-evolving agent frameworks, so no mechanism-level comparison here.

Recent updates: The releases endpoint returns an empty list (snapshot taken 11-04), so it iterates on main. The five most recent commits all fall on 11-04; here are three that bear on the architecture: a memory capture refused by its verifier now settles as an ordinary diagnostic (02b9ac04); a model turn bridged through a signed-in Grok CLI (dd9d3e88); dropped "received requests" from the sentence on what does not constitute authority, on the owner's instruction (8935bc6c). Commit messages are full sentences explaining why, not what.

Who it's for: People studying how an agent runtime should draw its boundaries, on a Mac. Note the limits: macOS-only packaging instructions, Node 24 and stable Rust required, the documented Codex integration uses a ChatGPT account, and an ad-hoc signed, non-notarized bundle. MIT license.

My take: ⭐⭐⭐ Read the architecture doc; do not install it yet. Its value is that it rethinks permissions, audit and capability mounting from scratch.

Checked: read the README, docs/architecture.md, the releases snapshot and the five most recent commits; nothing installed.

2. agentscope-ai/agentscope-java ⭐ 6,237 · Java

GitHub: https://github.com/agentscope-ai/agentscope-java

In one line: A Java agent framework that documents event streams, permission gates, sandbox options and external session state.

What it is: The Java implementation of AgentScope, positioned in the README as production-ready, distributed and enterprise-grade. Version 2.0 reached GA in 2026-07; the repository dates from 2025-09-23 and had 6,237 stars and 1,562 forks. JDK 17 or newer is a hard requirement. Session state can sit in memory or a JSON file, and a multi-replica deployment needs it externalized to Redis, MySQL, PostgreSQL or object storage; the sandbox can run as a local subprocess or be switched to Docker, Kubernetes or the E2B cloud. Since 2026-08 there is also an AgentScope Service, a control plane and dashboard that declares compatibility with LangChain, ADK, Claude/Qoder and other external agents. v2.1.0-BETA1 ships Docker images, Compose and Helm packages, a CLI and a Runtime Host.

What stands out:

• 32 typed events. The event stream is a protocol for live rendering and human-in-the-loop, not a log: tool results arrive as ToolResultTextDeltaEvent, ToolResultDataDeltaEvent and ToolResultEndEvent with metadata carried through, and a pluggable AgentProtocolEventBus, introduced in v2.0.3, handles SSE.
• The permission gate is part of the framework. Tool calls are allow, require user approval, or deny; the documentation places this decision in the framework. I did not exercise approval or bypass paths.
• Middleware is an AOP hook. The reasoning-acting loop can be intercepted and extended without forking the framework, and a returnDirect tool result can short-circuit the loop.
• Control reaches the single run. v2.0.4 introduced AgentRun and RunControl with explicit runtime-context propagation, for run-scoped control; I did not test cancellation or isolation under concurrency.
• Sandbox and distribution are first-class. Workspaces run locally, in Docker, in Kubernetes or in the AgentRun cloud sandbox; sessions and memory persist to Redis, MySQL, PostgreSQL, OSS or COS with cross-replica recovery; v2.0.4 specifically hardened isolation across concurrent runs, tools and skills.
• Model choice per call. A commit on 11-03 lets RuntimeContext.modelId pick the model for each call; v2.0.4 added token accounting, model-fallback listeners and an OpenAI Responses API module.

Compared with: I only read this one Java framework and made no cross-framework comparison. It builds three things in: an event stream as the contract with the front end, a three-state permission model, and session state externalized with cross-replica recovery. Those designs are relevant to persistent applications, including tests before deployment. I did not read primary material on Python-side equivalents, so no mechanism-level comparison; the difference I can confirm is language and deployment shape: it targets an existing JDK backend.

Recent updates: v2.0.4 (2026-10-08) added the OpenAI Responses API (#3078), AgentRun/RunControl (#3279), returnDirect short-circuiting (#2891), token metrics and model-fallback listeners (#3215, #3145), and reworked AgentScope Service; v2.1.0-BETA1 was pre-released the same day. Since 11-03 it supports per-call model selection and PDF documents with citations on the Anthropic side; on 11-04 it fixed identity fallback for unnamed sessions.

Who it's for: Teams with an existing Java backend that need agents inside a multi-replica service. Note that open_issues reads 969, but that field includes pull requests, so it is neither a defect count nor a quality signal; I did not examine the issue and PR mix this round. Apache-2.0.

My take: ⭐⭐ The concepts are right, but they only apply to a Java stack; outside one, reading the permission and event design is enough.

3. 1Panel-dev/MaxKB ⭐ 23,110 · Python

GitHub: https://github.com/1Panel-dev/MaxKB

In one line: A self-hosted enterprise agent platform that puts document ingestion, chunking and vectorization, and question answering alongside workflow orchestration and MCP tools in one web interface.

What it is: Created 2023-09-14, with 23,110 stars and 3,211 forks. The stack is Django and Vue, retrieval on PostgreSQL with pgvector, and LangChain underneath; the README provides a single-container docker run installation path, which I did not run. The README lists intelligent customer service, internal knowledge bases, research and education as the intended scenarios, and USE-CASES.md lists a long set of case entries whose titles are mostly universities, hospitals, government bodies and state-owned enterprises; the entries themselves are article links, demo videos and one live instance link, with no deployment method or acceptance record. GPL-3.0.

What stands out:

• RAG as a product flow. Upload documents or have it crawl online ones, then chunk, vectorize and answer through the interface without writing code.
• A workflow engine, a function library and MCP tools together. Complex business logic is expressed as a visual workflow, the function library covers custom logic, and MCP brings external tools in. The documented interface covers workflow composition as well as document retrieval.
• An LTS version line that carried 22 security items across three releases. Ten in 2.10.6 (09-03), eleven in 2.10.7 (10-15) including a derivable Celery task signing key that allowed remote code execution, an unauthenticated SSRF and an account takeover, and one in 2.10.8 (10-22); each release also carries a batch of knowledge-base and agent fixes.
• The security fixes show the deployment surface. v2.10.6 fixed a batch at once: uploaded files could spoof APPLICATION attribution and be read anonymously; document migration validated only the source knowledge base, allowing cross-tenant content injection; XLSX embedded images uploaded by an authenticated user were decompressed without a pixel limit, allowing memory-exhaustion denial of service; a batch-association endpoint lacked ownership validation, allowing unauthorized reads; an anonymous profile endpoint over-serialized and leaked sensitive configuration; password-reset codes had no attempt limit. The holes fall in three places: tenant boundaries, file handling and anonymous endpoints.
• Models are not locked in. Private models such as DeepSeek, Llama and Qwen and public ones such as OpenAI, Claude, Gemini and MiniMax are all supported, with text, image, audio and video capabilities listed. The supported combinations depend on the selected model and integration.

Compared with: My reading is that what decides adoption in this category is whether it can run on private infrastructure and whether upgrades are predictable. The README lists the workflow engine and MCP tooling as core features, while the release notes also carry X-Pack-tagged agent entries; which features belong to the community edition and which to the enterprise one was not established this round. I did not read primary material on comparable open-source RAG platforms, so no mechanism-level comparison.

Recent updates: v2.10.8-lts (2026-10-22) fixed, in an entry tagged X-Pack, a login-authentication configuration endpoint that did not redact sensitive fields and echoed third-party login app_key, corp_id and app_secret in plaintext; the release notes do not say whether the community edition carries the fix, and I did not verify it. It also fixed a set of knowledge-base issues around disallowed characters when creating a blank document, Markdown headings with identical text but different levels being misread during segmentation, a false permission error when a custom role deletes a document, and over-long parameters when retrieving tags across knowledge bases. v2.10.7 on 10-15 added a confirmation for deleting conversation history and fixed long-term memory saving in scheduled-trigger mode without an interval. Recent commits are mostly fixes.

Who it's for: Teams that want private knowledge-base question answering and can accept GPL-3.0; the release notes contain X-Pack-tagged items, and the version and licensing boundary that tag points to needs separate confirmation. Two cautions: the default administrator credentials are printed in the README, so they must be changed on first deployment, and nothing was installed this round, so deployment effort, upgrade path and concurrency behaviour remain unverified.

My take: ⭐⭐⭐ Worth evaluating for an internal knowledge base if its edition, licensing and upgrade requirements fit. Setup effort remains unmeasured here.

4. EthanYoQ/AI-Novel-Writer ⭐ 2,323 · TypeScript

GitHub: https://github.com/EthanYoQ/AI-Novel-Writer

In one line: A desktop writing application for long-form fiction that runs setup, architecture, chapter blueprints, drafting, review, revision and finalization as one pipeline, with confirmation stages documented for the single-chapter path.

What it is: Originally "AI Novel Writer", renamed Pagekin at 1.3.1. Created 2026-06-20, with 2,323 stars and 283 forks, built with Electron and TypeScript. Manuscripts live in a local SQLite database plus a project folder; the application ships no model, so you supply a key or run Ollama. GPL-3.0. On 2026-11-04 it landed several commits that follow an issue number, writing the failing test first.

What stands out:

• Each chapter gets only the context it needs. Generation receives that chapter's blueprint, the relevant characters, the world setting, a summary of prior text and the previous chapter in full, instead of the whole book's chat history. Batch writing is capped at 10 chapters at a time and can be resumed.
• Four architecture sections are confirmed before any blueprint. The architecture page has premise, cast, world and plot outline; each can be generated or written, and only after all four are confirmed do chapter blueprints (conflict, turn and hook per chapter) get generated.
• Per-stage models. Since 1.4.0, planning, drafting, review, revision and post-finalization processing can each use a different model; unassigned stages follow the default, and deleting a model sends its stages back to the default. Post-finalization processing covers only the first pass after a single chapter is finalized; auto-finalizing in batch writing, post-processing during import and retries of completed steps keep the original model.
• Imported SKILL.md files are prompt-only. You can import from a local folder, a single SKILL.md, or a GitHub address; referenced text files come along, and the content is displayed for inspection before installation. Per the project's documentation, scripts, hooks, sub-agents and tool calls are never installed, and a skill cannot execute code on the machine; I recorded that from the docs without checking the implementation.
• Revision arrives as a paragraph-level diff. You accept or reject each paragraph instead of having the draft overwritten, and a draft that was rolled back and re-finalized is kept read-only in version history.
• Reverse-engineering setup fills only blanks. Since 1.4.0, importing your own manuscript can infer setup, architecture, cast and blueprint; existing content is not overwritten, and differing results appear as suggestions to accept one by one.

Compared with: Long fiction can exceed a chosen model's usable context or make consistent retrieval difficult. This one breaks the book into structured assets and assembles each chapter on demand, turns review notes into a checklist and revision into a paragraph diff. The trade-off is that imported skills cannot install tool calls and automatic publishing was not established in this review; the documented revision flow offers author confirmation. I did not read primary material on comparable writing tools, so no mechanism-level comparison.

Recent updates: v1.4.0 (2026-10-29) added revision by instruction (up to 2,000 characters, with the result shown before you accept), per-stage models, and setup inference; large projects open faster and the run panel is quicker. Model settings were consolidated into a name plus a candidate list, and switching providers clears both the key and the model name. v1.3.2 (10-22) made errors follow the interface language and fixed a YAML-parsing denial of service in the updater's js-yaml dependency.

Who it's for: People writing long serialized fiction who are willing to configure their own models. Note GPL-3.0; the Windows installer is unsigned and the macOS build is ad-hoc signed without notarization, which can trigger platform security warnings. This review does not establish those packages as safe to run.

My take: ⭐⭐ The ideas are worth borrowing: structured assets, per-paragraph confirmation, models routed by stage. Whether it suits your writing habits needs a trial.

5. hyprwm/Hyprland ⭐ 40,239 · C++

GitHub: https://github.com/hyprwm/Hyprland

In one line: A fully independent tiling Wayland compositor that, in 0.57.0, opened a batch of Lua configuration interfaces and removed legacy config support.

What it is: Created 2022-03-16, with 40,239 stars and 2,164 forks, written in C++ (the repository topics say cpp26), BSD-3-Clause. The README states it uses no wlroots, libweston, kwin or mutter. Features include four layouts (dwindle, scrolling, master, monocle, with custom layouts in Lua), window rules, special workspaces, window groups, socket IPC, native input-method and input-panel support, and a plugin system with a built-in plugin manager.

What stands out:

• Configuration as script. 0.57.0 opened a batch of config/lua interfaces: reload_config(), hl.get_devices(), window.update_state and a minimize event, and split created into created_early and a post-setup created. The old configuration syntax is on its way out: 0.57.0 added deprecation notices (#15669) and removed legacy config support (#15539), and which old forms still load was not established this round.
• Rendering is being split into swappable parts. 0.57.0 added scene composition, window wobble, swappable blur variants and decoration:blur:proportional, and promoted layers to its own configuration category.
• Plugins and IPC are first-class. A plugin system with a built-in manager, plus socket IPC that lets outside programs query state and dispatch actions.
• The observed release interval. Nearly three months separate 0.56.2 (08-05) from 0.57.0 (10-28), and 0.57.1 followed six days later; patch releases only backport fixes from main.

Compared with: Hyprland exposes events, devices and window state to a configuration script, and outside programs can drive it over IPC. That difference matters to anyone writing desktop automation: being able to ask what the desktop currently looks like is more fundamental than being able to simulate a click. I did not read primary material on how scriptable comparable compositors are, so no cross-project claim.

Recent updates: v0.57.0 (2026-10-28) carries the bulk of these changes; v0.57.1 (11-03) backported fixes for chord resolution, a session-lock protocol error after an output is removed, NVIDIA black screens and dmabuf feedback refreshes; commits on 11-03 were still fixing keybind modifier remapping and urgent-only activation tokens.

Who it's for: People who enjoy configuring a Linux desktop. Note that a compositor carries protocol compatibility itself, and NVIDIA users should read the 0.57.1 fix list first. Nothing was installed this round.

My take: ⭐⭐ Relevant to Linux desktop configuration and automation; the exposed state and events are worth studying.

At a glance

Project	What it is	The one distinctive thing	Who it's for	Worth a look
Octopus-SI-OS	Self-evolving agent OS	A kernel plus eight primitives; capabilities mounted as descriptors	People studying runtime boundaries	⭐⭐⭐
agentscope-java	Enterprise distributed agent framework	Event stream as contract; documents cross-replica session recovery	Java backend teams	⭐⭐
MaxKB	Enterprise agent platform	Knowledge base and workflows in one self-hostable instance	Teams building an internal knowledge base	⭐⭐⭐
AI-Novel-Writer	Long-form fiction writing app	The book becomes structured assets; each chapter assembles its own context	Novelists writing at length	⭐⭐
Hyprland	Wayland compositor	Configuration as script; IPC exposes state	Linux desktop tinkerers	⭐⭐

Notes from this issue

• Agent frameworks are separating the kernel from the capabilities. Octopus moves both the model and the loop out of the centre, leaving primitives and descriptors; agentscope-java takes the other road, building events, permissions and session state into the framework. These projects describe different ways to organize capabilities and persistent execution.
• What makes long-running sessions hard is recovery and permission. Externalized session state, documented recovery paths, tool authorization and refusal records are useful areas to test. Their presence does not demonstrate correct crash recovery, external side-effect reconciliation or safe handoff.
• The moat for RAG platforms is the permission boundary. MaxKB's batch of fixes included cross-tenant content injection, unauthorized reads and configuration leaking from an anonymous endpoint, alongside decompression and verification-code problems that a single instance is exposed to as well. Permission and ownership checks need evaluation alongside retrieval quality; these release entries do not independently establish the security of the current build.
• The right abstraction for writing tools is structured assets. A whole manuscript can exceed a selected model's context, and fitting it does not guarantee consistent use of every detail. Splitting setup, cast, blueprint and foreshadowing into assemblable assets and fetching only what a chapter needs provides a context-management strategy. It does not guarantee that generated chapters remain consistent with those assets.