Open Source Radar · 2026-11-01: Memory shrinks, publishing leaves a paper trail

By Renchao Wu. Originally published on widechaos.cn.

For this issue I picked five projects from GitHub Trending and topic-search candidates, 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-11-01.

1. Orkas-AI/Orkas ⭐ 6,562 · JavaScript

GitHub: https://github.com/Orkas-AI/Orkas

In one line: A multi-agent team on your desktop; a Commander turns a goal into to-dos, directs 16 built-in specialists plus the coding agents you already have, and hands back finished files.

What it is: An Electron desktop app with installers for macOS 12+ and Windows 10+; Linux runs from source and needs glibc 2.34+. The organizing unit is a project: goal, rules, memory and files travel together, so a new conversation can draw on stored project context. That does not establish transparent recovery of in-flight tools or external state. A to-do board splits work between people and agents, Auto-advance lets the team pick up the next item by itself, and scheduled automations repeat hourly, daily, weekly or monthly. The 16 built-in specialists cover research, content, video and audio, office files and e-commerce; external CLI agents (Claude Code, Codex, OpenCode and others) join the same board as peers. MIT.

What stands out:

• Three delegation verbs with different consequences. dispatch_to runs a named agent and returns its result so the Commander can keep working; hand_off_to transfers the rest of the work, ends the current turn, and the other agent answers on its own; run_worker runs an anonymous isolated subtask that receives neither conversation history nor a named agent's skills.
• Admission is described by explicit rules. The message bus scans its queue in order and starts an item only when three rules pass at once: same-actor serial execution for stateful sessions, a per-session agent cap, and a per-conversation named-task gate. Commander runs occupy neither quota. Dispatch fan-out and bounded review happen inside one turn, constrained by worker slots, invisible to the scheduler.
• A per-turn tool budget fixed in a unit-tested constant. Commander and named agents each get 500 tool rounds; ephemeral workers inherit the schema default. The constants live in their own file with tests intended to catch drift. Tests do not make later configuration changes impossible.
• Queued is not the same as done. The source comment is explicit: an admitted or queued task is not treated as a completed result. Named tasks can be tracked and cancelled individually.
• Self-improvement runs as idle reflection, not data accumulation. When the app is idle, a background review looks at new activity under cooldowns and execution limits and may revise three things: a self-assessment (COMPETENCE.md), reusable methods (LEARNING_STRATEGIES.md), or a learned skill. It is allowed to conclude that nothing is worth saving.
• Scheduled work catches up. Since v1.9, each automation catches up its most recent missed run within 12 hours after the computer wakes or the app starts.

Compared with: The README carries its own comparison table and describes the difference from LangChain and CrewAI as "a desktop app you direct through chat, not by writing orchestration code"; that part is the project's own framing. What can be checked is the mechanism above. For a fair comparison I would test three things: whether admission rules are deterministic, whether tool budgets and timeouts are configurable, and whether a failed task can be reported as a completed result.

Recent updates: v2026.10.27 (10-27) lets you configure a full set of image and video model providers with your own keys; custom models can connect through OpenAI Responses, Chat Completions or Anthropic protocols with clearer capacity validation and credential recovery; local apps can be created, edited and previewed, with publishing and project invitations kept separate from local work.

Who it's for: People who want a desktop-hosted agent team. Local storage does not mean prompts, files or other tool inputs stay on the machine when cloud models or services are used. It is not for someone who wants a single all-purpose chat window, or a library to embed in their own code. Two costs first: the open-source build lacks shared projects, cloud sync and web-app publishing, which exist only in the packaged app; the packaged app has a separate credit and paid-plan model; check its current terms rather than treating the source licence as a hosted-service entitlement.

My take: ⭐⭐⭐ A project that treats "how do you keep a multi-agent run under control" as the first problem. The mechanism is worth more than the feature list. The price is that Linux only runs from source, and core features are split between the open-source and packaged builds.

Checked: read the README, the v2026.10.27 release notes, recent commits, and src/main/features/group_chat/bus.ts plus actor-budgets.ts; not installed.

2. rowboatlabs/rowboat ⭐ 18,107 · TypeScript

GitHub: https://github.com/rowboatlabs/rowboat

In one line: It indexes email, meetings and chat into a Markdown knowledge graph on your own machine, then lets an agent work on that graph; the team edition lets every person bring their own agent into one room.

What it is: The repo holds two halves; a desktop app (Electron) with a headless server, and Harbor, a self-hosted team Space server. The desktop core is Brain: email, meetings, Slack and assistant conversations become a backlinked Markdown knowledge graph that a person can read, edit and back up, all on local disk. Work surfaces built on top include an email client that sorts into important and everything else and drafts replies from work context, notes, an isolated built-in browser, local meeting notes (mic and speaker transcribed and written back into the graph), a Code Mode that spins up parallel coding agents, and shareable apps. Apache-2.0.

What stands out:

• Memory is a living knowledge graph, not a retrieval layer. The README draws the line plainly: most tools reconstruct context on demand by searching transcripts or documents, while this one maintains long-lived knowledge; context accumulates, relationships are explicit and inspectable, notes stay editable by the person rather than hidden in a model, and everything is plain Markdown on your machine.
• The Space contract states four privacy rules. Read only what the task needs ("message Harsh" needs a member id, not the HR directory); answer only what was asked; private material crosses to the shared side only on request and only as a summary, never by pasting emails or DMs; a receipt says what it did, not what it read.
• The project's own agent gets no privileged path. Harbor is one core with three doors: HTTP, a live WebSocket, and an MCP server. Rowboat's agent reaches a Space through the same MCP door any external agent uses. On that face, reason is required (optional over REST), because only agents call it.
• Conflicts are outcomes, not errors. A change-set is full content against a declared base: {assetId, baseVersion, newContent, reason}. The server runs a line-level three-way merge, and all three outcomes are HTTP 200; applied when the base was current, merged when the base was stale but the merge was clean (the returned mergedContent is what now exists and the proposer must adopt it), and conflict when nothing is written and the response carries current content, colliding regions and recent history so one round trip is enough to retry. Binary assets never merge; a stale binary is a conflict.
• Agents are real members with their own keys. Member.kind is human or agent, fixed at creation. An agent has an owner and an rbk_-prefixed key (the org stores only a SHA-256); the key works across REST, the live face and MCP, and its acts are attributed to the agent itself. The contract says the database rejects an agent admin. I have not tested every membership or migration path.
• One schema binds both ends. @rowboat/spaces-protocol is imported by client and server, and every contract change must land as a PR touching schemas and fixtures together, never as a verbal agreement or a divergent copy. Sharing schemas reduces one kind of drift. Deployed versions, migrations, optional fields and semantic behaviour can still diverge; I have not tested compatibility across versions.

Compared with: The difference is how people and agents are treated on the same collaboration surface: the contract specifies write attribution and separates reading from acting, a stale base returns something you can continue from instead of an error, and an agent's namespace operations must carry a reason. I have not read a first-hand contract from a competing product, so I won't claim others cannot do this. The four dimensions worth comparing are: whether agents have their own identity and revocable keys, whether writes carry attribution and a reason, whether a stale base errors or returns a resumable result, and whether humans and agents share one conflict semantics.

Recent updates: v1.0.5 (09-30) shipped with an empty description; v1.0.3 (09-17) made team Spaces the main line. Between 10-26 and 10-30 the contract gained managed agents plus VM management and a VM console (Harbor mints a delegated terminal token with an expiry from the platform). A commit on 11-01 moved one class of agents' model lists to the harness, no longer served by Harbor.

Who it's for: Teams that want local, inspectable memory and multi-person collaboration. Self-hosting Harbor needs Postgres and an OIDC issuer. The authors state the protocol is v0 and will change, so don't build against it as a stable interface.

My take: ⭐⭐⭐ Its value is not the feature list but that "memory must be auditable, agents must be accountable" are expressed as protocol-level requirements. Their enforcement needs implementation and integration checks.

Checked: read the README, apps/harbor/CONTRACT.md (the v0 contract), the v1.0.5 release record and recent commits; not installed.

3. osaurus-ai/osaurus ⭐ 8,096 · Swift

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

In one line: An agent harness for macOS; local MLX models or supported cloud providers, with memory, tools and identity kept on your machine.

What it is: A native Swift macOS app requiring macOS 15.5+ and Apple Silicon, MIT. It positions itself as the layer between you and the model: swap models freely, keep context, memory, tools and identity. It exposes OpenAI-, Anthropic- and Ollama-compatible endpoints (default 127.0.0.1:1337), and on the other side supports a local MLX model library, Apple Foundation Models and several cloud providers. The surface is wide: custom agents, an agent loop with a sandbox, an Orchestrator that plans without touching files, subagents across local or remote models, browser use, offline image generation, MCP in both directions, plugins and skills (whole Claude plugin bundles can be imported), schedules and folder watchers, and on-device speech transcription.

What stands out:

• Memory stores little and injects less. v2 has three layers plus a fallback: identity (explicit overrides plus an auto-derived narrative), pinned facts (with documented salience decay and inactivity-based eviction rules; the decay formula alone does not determine when a fact is removed), and episodes (one per session: summary, topics, entities, decisions, action items). Raw transcripts are fallback retrieval only and never injected by default. The default per-turn budget is 800 tokens, and many turns inject nothing at all.
• Writes stay off the chat hot path. Each turn performs a single SQL insert into a pending queue; 60 seconds of inactivity (or a session change, or navigating away) triggers one whole-session distillation, so a distillation call can cover several turns; actual batching and cost depend on session behaviour. On read, a relevance gate routes pronouns and "that thing discussed earlier" to episodes, "do you remember my preference" to pinned facts, and "exact words" to the transcript; if nothing fires, memory is skipped.
• The configuration surface went from 18 knobs to 8. v1's mmrLambda, mmrFetchMultiplier, verification thresholds, per-section budgets and recall topK are gone. v2 keeps a switch, embedding backend, extraction timing, gate mode, budget, debounce seconds, consolidation interval and retention.
• Text redaction has documented fail-closed conditions. For enabled cloud-bound text paths, the privacy pipeline uses configured regex categories and an optional on-device classifier to detect sensitive spans. Detection can miss content; it is not a guarantee that every name or secret is found. The current privacy document explicitly says image URLs, image bytes and audio attachments pass through unscanned; multimodal scanning is still a design proposal. For interactive paths the document describes a review sheet; other origins and per-call options have separate behaviour. approved entities become stable [PERSON_1] and [EMAIL_2] placeholders and are unscrubbed on the streamed reply. If the enabled post-scrub checks detect a covered leak, the document says the send is blocked, and an Insights panel records the post-scrub HTTP payload written locally. That is outbound evidence, not an independent receipt of remote processing.
• Identity is a cryptographic address. Every participant; person, agent, device; gets a secp256k1 address; authority flows from a master key down a verifiable chain, and portable access keys can be scoped per agent and revoked. I have not tested revocation propagation, key compromise or every authorization path. Two agents talking across networks use a forward-secret handshake with authenticated encryption, so the relay forwards ciphertext it cannot open.
• The isolation mechanism depends on the macOS version. On macOS 26+ it runs an Alpine Linux VM through Apple's Containerization framework, one Linux user and home per agent, bridged back to host inference, memory and secrets over vsock. Older systems fall back to sandbox-exec, with writes limited to the sandbox workspace and network either fully on or fully off; no per-domain allowlist.

Compared with: The difference is that memory and redaction are engineering artifacts with a budget, an eviction policy and a stated failure mode, rather than two words on a feature list. I have not read a competing implementation first-hand this round, so I won't call it unique; the three checkable dimensions are whether memory has a per-turn budget and eviction, whether sensitive fields are verifiably replaced before leaving the machine, and whether isolation is VM-level or process-level.

Recent updates: 0.25.29 (10-30) saves model-aware adaptive speculation defaults per agent, redesigns agent generation overrides with inheritance, and serves context usage for phone chats; 0.25.28 (10-28) added LFM3 media capabilities and let bundled agents stay out of the Orchestrator's delegation list.

Who it's for: Mac users comparing local-model operation with cloud-provider paths. Offline operation depends on the chosen models and tools; redaction is configurable and is not a promise that all personal data stays on the machine. It cannot run on Windows or Linux. Two details to read carefully: telemetry is off by default in source builds, while crash reporting is on by default in the packaged app and can be turned off in settings.

My take: ⭐⭐⭐ It offers a set of acceptance criteria; memory can shrink, redaction can refuse to send, isolation has a boundary. That matters more than how many models it supports.

Checked: read the README, docs/MEMORY.md, docs/PRIVACY_FILTER.md, the 0.25.29 release notes and recent commits; not installed (requires Apple Silicon).

4. yaojingang/GEOFlow ⭐ 3,982 · PHP

GitHub: https://github.com/yaojingang/GEOFlow

In one line: A corporate-site content platform whose documentation connects knowledge, writing, quality checks, human approval, distribution and audit records.

What it is: A Laravel application with PostgreSQL (pgvector recommended) and Redis, deployed with Docker Compose: front end on 18080, admin under /geo_admin/login. A knowledge base (structured chunking, optional semantic planning, vector recall with a stable fallback) plus title, keyword, image, author, prompt and model libraries feed task-based content production, a four-dimension AI quality check and human review; output goes out three ways; the site front end, hosted channel sites, and a manual publication workbench with a Chrome assistant. Analytics covers traffic and AI visibility. AGPL-3.0.

What stands out:

• The documentation specifies a publication gate. Articles pending review, blocked, errored or expired stay in draft, and the documentation says the same gate blocks local publish, site assignment, manual publication and channel distribution. I have not independently tested bypasses or all four exits.
• The check has a hard deadline and a degradation path. The documented end-to-end budget is 180 seconds, with dedicated online and backfill queues, sampled degradation on timeout, typed provider failures, worker health checks. The design keeps a failed check unscored rather than defaulting to pass, and returns an actionable retry suggestion. Long articles are dispatched as separate queue jobs per section, and a single misconfigured article is isolated and resumed by cursor so it cannot block the rest.
• Three recall modes that combine. Atomic, chunk and knowledge-base checks share availability and priority rules; each record stores the requested mode, the actual mode, the policy version, source hashes and audit data, and a change to knowledge, model, prompt, body or rollout selectively invalidates old results and triggers reconciliation.
• Manual publication is a work order with a lease and a receipt. The Chrome assistant pairs through a short-lived device code approved by an admin and receives only browser-operation read and execute rights; claiming, heartbeat, recovery, account verification, execution receipts and token revocation are all recorded, and the workbench stores identity, account, operator, planned time, risk notes and audit data, with results landing in a "pending verification" state first.
• Updates and rollback have their own boundary. A separate updater handles signed updates, full backups, environment acceptance and restore-point rollback, and high-risk actions require the admin password plus a 6-digit authenticator code; 3.1 added signed upgrade-plan preflight, migration backfill and blue-green conversion.
• The AI-crawler surface is an explicit artifact. The main site and hosted sites serve robots.txt, sitemap.xml, sitemap.txt and llms.txt, generated live from site, publication state, index switches and canonical links, refreshed on publish, delete and settings sync. The docs note that this only manages crawler intent; sensitive data still needs authentication and authorization.

Compared with: The divergence is treating content operations as a state machine with an audit trail instead of chaining prompts together. I have not read a competing implementation first-hand, so here are four dimensions to compare: whether the check result really blocks every publish exit, whether a timeout is recorded as unscored rather than passed, whether browser collaboration uses short-lived least privilege instead of storing the other platform's password, and whether update and rollback have an independent signing boundary.

Recent updates: The stable release is still v3.1.0 (09-09); the repository source is at 3.2.0-beta.2 and the latest preview, v3.2.0-beta.1 (09-16), added a standalone remote CLI (connect to named instances, inspect identity, revoke tokens, recover operations through durable receipts) and remote theme draft editing. The same batch added durable admission records, recovery epochs, credential invalidation and reconciliation after uncertain responses.

Who it's for: Content or brand teams with real business material, a named review owner and a continuing operation plan. The cost sits in the same place: a PHP stack plus operations (Postgres, Redis, queues, Nginx) is not small, and the beta should not go to production; the docs themselves say to pin a stable release or a reviewed commit.

My take: ⭐⭐ Its documented mechanisms are worth examining, but it solves a heavy corporate-site problem that a personal site is unlikely to need.

Checked: read the README, docs/CHANGELOG.md, the v3.2.0-beta.1 and v3.1.0 release notes; not deployed.

5. kgoedecke/doop ⭐ 1,264 · TypeScript

GitHub: https://github.com/kgoedecke/doop

In one line: A multiplayer design canvas where frames render real HTML and people plus any MCP client edit the same canvas live.

What it is: Three concepts; a Canvas (shareable at /c/<id>), Frames (artboards that render real HTML inside sandboxed iframes) and Pages within a canvas. People edit in the browser; agents edit through the built-in MCP server; both see one state: cursors, presence, per-frame editing indicators, agent status and an activity feed. Agents connect over standard MCP OAuth, with add-flows for Claude Code, Codex, ChatGPT and Cursor, and any MCP client can use an agent key. Self-hosting takes either docker compose up -d (app plus Postgres) or a zero-config bun run dev with embedded PGlite. AGPL-3.0.

What stands out:

• The README lists forty annotated MCP tools. Thirty-eight built in plus two from a Linear extension, grouped into Canvas, Frame, Prototype, collaboration, design memory, assets and web. The tools carry annotations such as read-only, destructive or idempotent. Annotations are metadata, not an independently enforced permission boundary; and the server registers no MCP prompts; guidance travels through tools and initialization instead.
• It attacks "the agent cannot see what it drew". Three layers: a compact contract at initialization (load the guide, get context first, stream the design, review with screenshots); a get_guide tool with the deep playbook (review checkpoints, frame sizing, design-quality doctrine, multiplayer etiquette) loaded once per session and reloadable after context compaction; and results that talk back; after a frame write, the tool result tells the agent it has not seen its own design yet and to call get_frame_screenshot before continuing.
• Drawing is streamed. append_frame_html wraps chunks with start=true and done=true, smoothed server-side, so viewers watch a design build up rather than jump into place.
• Design memory is versioned guidelines plus distillation. set_guidelines keeps canvas-level style guides with version history, save_decision records a decision so later agents do not re-litigate it, and a human-pinned frame can be read as a "more like this" reference. Those feed a distiller that proposes durable style rules; nothing changes until a person accepts. The distiller is pinned to an Anthropic key and quietly turns off without one.
• Agent identity comes from authorization. Whoever approves the OAuth connection is the agent's owner in tasks and presence; mutating tools accept agent_name, so the agent shows up in the presence stack with a pulsing avatar, gets an editing ring on the frame it touched, and lands in the activity feed. Inactivity expires it from presence after about 20 seconds.

Compared with: The reference point, Paper.design, is a closed product whose implementation cannot be read, so this is not a comparison of internals. Four things can be compared: whether an agent has its own identity and revocable authorization, whether the host verifies that an agent actually captured and inspected its work, whether style rules are versioned and readable by agents, and whether agents and people share one conflict semantics under concurrency. Each of the four has a corresponding implementation or document in this project.

Recent updates: v0.12.0 (10-31) signs the Windows app and installer with Azure Artifact Signing and fixes the token fetch right after Azure login; two more desktop releases landed the same day with empty notes, so the desktop line is moving fast.

Who it's for: Teams that want design collaboration on their own machine with agents editing HTML directly. Three caveats: the version is early (0.12), the exact AGPL-3.0 terms and any network-source obligations need to be checked for the intended deployment, and the built-in agent's free quota depends on a server key and is zero by default.

My take: ⭐⭐ The project is still small, but "correct model behaviour through tool results" is a technique worth remembering on its own.

Checked: read the README's MCP tool table and agent-workflow section, the v0.12.0 release record and recent commits; not deployed.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a deeper look
Orkas	Multi-agent desktop copilot	Explicit admission rules and fixed per-turn tool budgets	People who want an agent team on their own machine	⭐⭐⭐
rowboat	Local knowledge graph plus team collaboration	Its own agent uses the same MCP door as any other	Teams that need auditable memory	⭐⭐⭐
osaurus	macOS agent harness	Memory with budget and eviction, text redaction with documented refusal conditions	Privacy-sensitive Mac users	⭐⭐⭐
GEOFlow	Corporate-site content operations	The docs require one gate across four publish exits	Content teams with review duty	⭐⭐
doop	Multiplayer design canvas	Tool results instruct the agent to inspect screenshots	Teams letting agents edit designs	⭐⭐

Notes from this issue

• The multi-agent projects in this issue put their effort into keeping a long run under control. Admission rules, explicit tool budgets, and a distinction between queued and completed work. These are documented design choices, not a reliability result from my own run. I would check those three before counting how many agents a project ships.
• Both memory projects in this issue are subtracting. One cut its configuration from 18 knobs to 8 and injects at most 800 tokens per turn, sometimes none; the other writes memory as a Markdown graph a person can read and edit. Different routes, the same point: memory has to be inspectable and reducible.
• Both publishing-related projects in this issue write evidence into the flow. A quality verdict must be able to block every exit, manual publication needs a lease and an execution receipt, and a stale base should return a resumable result rather than an error.
• Getting an agent up to speed looks more like engineering than prompting. A contract at initialization, a playbook loaded on demand, corrections delivered through tool results, and a screenshot so the agent can see its own output: doop uses tool results to reinforce the workflow. I have not measured compliance or compared reliability against a system-prompt baseline.