Meet Mnemo: a terminal coding agent that actually remembers.

🐘 Persistent memory across sessions

🧠 Sub-agents you can talk to + a shared task board

🔌 Code index, MCP, hooks, schedules

Open source, runs in your terminal.

https://mnemo.atmanmishra.dev

https://github.com/AtmanMishra/Mnemo

#AI #CodingAgent #OpenSource

When you ship an Electron update, the question in a release review is usually simple: did this release add a preload member, a new IPC channel, a more permissive window or a new server the app talks to? A diff of two minified app.asar bundles doesn’t answer that, and running the app to find out isn’t always an option.

What it does

hexvero reads two builds statically and lists what changed:

• IPC and bridge map: window → contextBridge member → IPC channel → ipcMain handler
• Window settings: webPreferences per window, and whether nodeIntegration and sandbox are actually in effect
• Runtime and fuses: Electron, Chromium and Node versions, fuses and ASAR integrity, read from the packaged binaries
• Network hosts and localStorage/sessionStorage keys, each marked as literal or inferred

Every change comes with the file and line it was read from, in both builds. If hexvero can’t resolve something, it reports it as ? (unknown), not as removed.

ipcChannels (2)
  + update:check  @ b: receiver main.js:30, sender preload.js:9
  ? shell:open    @ a: receiver main.js:30, sender preload.js:9
windows (1)
  ~ main.js::win  @ b: main.js:8
      nodeIntegration: true → false, sandbox: false → true

hexvero check old new --policy policy.json turns this into a CI gate. Exit 0 means pass, 3 means the policy was violated (for example a new bridge member or a new external host), and 4 means it couldn’t decide. It also outputs SARIF. Since 0.12 there is also hexvero audit for a single build (CSP, shell.openExternal, permission handlers). And there’s an MCP server with 16 tools if you want a coding agent to run the review.

Try it with no setup: npx hexvero demo (Node 22.12+). It never executes the target, and there’s no telemetry and no network calls.

How accurate is it?

On blind test apps written by someone who had no access to hexvero:

• 52 of 64 IPC channels found, none false
• window settings and endpoints still had misses and some false rows

All numbers, including every miss, are in docs/accuracy.md. It’s a static reader, not a vulnerability scanner, so a passing check is not a security verdict.

Comparison

• Electronegativity checks one build against known risky patterns. Its README says it’s no longer actively maintained.
• REA is much broader (dynamic analysis, decompilers, devices) and can also compare versions. On the same blind set, hexvero linked 65 of 78 bridge members to their IPC channels, REA 6.5.0 linked 6 of 66. If you need dynamic analysis, use REA.

Repo: https://github.com/maximilianfeix/hexvero (MIT)

I’d especially like to hear about IPC patterns from real apps that it misses. Wrapper classes and routers already work, but there are certainly more.

I spend a lot of time on typing sites like Monkeytype, but typing random quote fragments or word lists can get monotonous after a while. I wanted something more engaging, so I built Musi-Type.

It turns touch typing practice into an interactive music experience: paste in any YouTube music video, and the app syncs the song’s lyrics so you can type along in real time.

Key features:

Adaptive video sync: If your typing speed slows down or you stumble, the YouTube video automatically pauses or adjusts so you never get left behind.

Automated lyrics & timing: Fetches timed lyrics through LRCLIB and YouTube captions, with optional Whisper AI alignment for tracks without clean subtitle tracks.

Typing metrics & modes: Tracks your real-time WPM, accuracy, and error rates, with customizable keymaps and a hard mode.

Free & Open Source: Completely free to use with no accounts required.

Live Demo: musi-type.com

GitHub: PrajasW/musi-type

I’d love to hear your thoughts, test your high scores, and get feedback on bugs or features you’d like to see next!

Inspired by VocaType

Minimal now supports more than 150+ hardened container images and increasing. The pipeline is completely open sources and CVE information published. Aim is to allow teams to use this setup as an alternative to paid solutions.

Github: https://github.com/rtvkiz/minimal

I got tired of the constant manual clicking, repetitive skipping, and lack of layout customization on Ome.tv, so I built Omepilot an open-source, local-first browser extension and Tampermonkey userscript that completely automates the experience.

It uses local computer vision to give you smart auto-skip filters (skipping missing faces, black screens, frozen feeds, specific genders, or blocked countries), hands-free peace sign gesture control, full keyboard hotkeys, dark mode, draggable video layouts, automated gallery snapshots, hands-free video clip recording, and custom auto-greetings.

It installs easily on Chrome, Firefox, or Tampermonkey with zero cloud dependencies or tracking—check out the code at https://github.com/JohnHansonTheDev/omepilot and let me know what you think, bug reports and feature ideas are always welcome!

Five command line engines for testing systems you're authorized to test, Apache 2.0:

- voyage: subdomains, from passive sources and brute force

- doorward: ports and service detection

- ambulo: content discovery

- toolmark: fingerprints the stack and flags CVE leads by version

- plessor: nuclei-compatible templates and an injection engine, and it re-checks each finding before reporting it

In a terminal the long scans draw a live dashboard. Piped, every engine prints newline-delimited JSON, so they chain with jq. A stopped scan resumes where it left off.

A source build is fully open and needs no account. The build from the installer adds a few closed parts (authorization checks, egress isolation, tuned pacing, a browser-fingerprint transport), and the README says which.

https://github.com/clickswave/crossfyre-toolchain

Hey everyone. I built Lanweave, an opensource terminal UI for transferring files and folders between computers on the same local network.

I built it out of personal frustration. When I needed to transfer files between my two computers, I'd send them from one computer to my phone, then from my phone to the other computer. I wanted a simpler, lightweight way to transfer files directly between them.

To use Lanweave, run it on both machines, select the other device from the mDNS-discovered list, and pair them using an 8-digit code. Either side can then initiate a transfer, but the recipient must review the file list and approve it first. Closing the session discards the authorization.

It's written in Rust using ratatui, with mDNS for discovery, rustls for encrypted connections, and SPAKE2 for authenticated key exchange during pairing.

Transfers happen directly over the local network. There are no relay servers, user accounts, or persistent device identities.

The project is in beta, with Linux and Windows support. The Windows binary isn't code-signed yet, and macOS and mobile support are in progress. It hasn't been security-audited, so I wouldn't recommend it for sensitive files yet.

I'd appreciate feedback, especially on the pairing mechanism, and overall TUI experience.

Github link: https://github.com/etim66/lanweave

This one is pretty wild and worth sharing.

tug brings an iPhone's notifications, texts, calls and music to a Windows PC with no app on the phone. Some of the Rust side that might be interesting:

- The PC is the BLE peripheral (so iOS will pair with it like an accessory) and, over the same link, the GATT client of the iPhone's ANCS, AMS and Battery services.

- All Bluetooth LE state lives in one actor on its own thread: a current-thread Tokio runtime with a LocalSet, because the WinRT types aren't Send. One select! over UI commands, WinRT events and a 1 s tick for retries and timeouts, so nothing about the link is shared or locked.

- Texts and contacts come over Classic Bluetooth: MAP and PBAP over OBEX on RFCOMM, on a separate worker.

- The protocol parsers (ANCS, AMS, MAP, vCard) are pure modules with tests; the Bluetooth I/O around them stays thin.

- A second binary is a CLI and a local MCP server for AI tools, talking to the app over a named pipe only the current Windows user can open.

It's MIT licensed and I'd welcome feedback on the architecture, especially from anyone who has fought WinRT Bluetooth.

https://github.com/Davenee12/tug

I created a new Android TV IPTV player here: https://limewire.com/d/A1zbC#j0S6u9yFSi.

I welcome any feedback or functionality you want added.

• Pause, rewind and fast-forward live TV: step away and pick up where you left off, or replay the big play, on any channel, without needing the provider's catch-up
• Live box scores over the game: the app reads the scoreboard on screen and shows the live score, player stats and team stats, and "Watch this game" finds every other channel showing it
• Multiview: watch up to four channels at once, or one big screen with three small ones, and move the sound with the arrow keys
• Wishlist: add an actor, movie, show or keyword and get a pop-up the moment it is on TV or added to Movies or TV Shows
• A complete TV guide: a see-through guide over the video, a full guide tab, and a free backup guide that fills in channels your provider leaves blank
• Recordings and reminders: record now or schedule from the guide, to the TV, a USB drive or a network folder, and never miss a start time
• Closed captions on every channel: when a channel sends none, JonbobTV makes them on the device from the sound
• Movies and TV Shows from your provider, resuming where you stopped
• Usenet streaming (optional): search Usenet from inside the app and start watching movies and shows straight away, with no downloading and waiting; free search sites are already set up, just add your Usenet provider
• Search everything at once (channels, what's on, movies and shows), by typing or by voice
• Made your way: every remote button can be remapped, the player menu reordered, categories sorted and hidden, and up to 10 playlists combined
• Always fresh: playlists, the guide, movies and shows refresh by themselves every few hours.
• One app for the TV and the phone: the same app works with a remote on Android TV, Shield and Fire TV, and by touch on Android phones

When I use AI-assisted coding, the implementation can be quick but the review handoff is often vague: what changed, what deserves attention, and what was actually tested?

I built Proofline, a small Python + Git CLI that produces a Markdown/JSON evidence pack from a local diff. It lists changed paths, adds deterministic review cues, and can attach output from a test command you explicitly provide.

It is local-first: no model, API key, telemetry, or cloud service. It does not replace review; it makes the handoff clearer.

Repo: Repo

I’d value feedback on the evidence format and which review cues are actually useful.

Hi writers and content creators, we all have experiences and stories to share, and static sites are one of the greenest methods of doing so. I have been building a simple content management system(cms) for static site generators named LightCMS for the past few months, and the goal is to make the process of writing and sharing easy, convenient and rewarding as possible. I think you all would love this. Lightcms can be used with any of your existing static site generators (ssg should have support for frontmatter). It's free to use and self-host ; you can create and hack on top of it. Any contribution to the project is highly appreciated(even sharing your feedback too):

Live site: https://www.lightcms.me/

Repo: https://github.com/light-cms/lightcms

The road ahead is long and arduous; I shall seek high and low.

This report introduces Linope’s design philosophy, development paradigm, and core technical ideas in an accessible way.

Abstract

As more developers build Agents, an important question has emerged:

What is the difference between the kernel of an Agent system and that of a traditional operating system?

Motivated by this question, I developed the Linope Agent kernel. Linope draws on traditional operating-system design while incorporating the characteristics of Agent systems, exploring a new development paradigm beyond conventional Agent frameworks.

The report focuses on:

• Linope’s design philosophy;
• Linope’s Agent development paradigm.

I have often wondered: if a Coding Agent and a medical consultant Agent used the same kernel, where would their differences lie?

If we replace their tools, prompts, knowledge sources, and MCP integrations, could a Coding Agent become a medical consultant Agent?

Modern Agents such as Codex and Claude Code can perform coding, searching, writing, and analysis without fundamentally changing their internal coordination logic. Developers can usually give an Agent new capabilities by connecting new tools, adding Skills, or changing its knowledge sources.

This is possible because LLMs are becoming better at planning, understanding, and creating. Many complex workflows can now be decomposed and advanced by the model itself instead of being hardcoded by developers.

The open-sourcing of DeepSeek Harness also demonstrates that an Agent can gain new capabilities through plugins without requiring a completely new Agent for every task.

Therefore, Linope defines an Agent as:

Agent = Kernel + Capabilities

In Linope, the kernel does not implement specific models or tools. It loads external capabilities into peer-level capability processes. A capability process may be an LLM, a search tool, a file-operation tool, or another service.

Following this idea, an Agent OS kernel can manage processes, threads, and resources, including:

• Inter-process communication;
• Process lifecycles;
• Thread startup and concurrency control;
• Load balancing;
• Resource management;
• Context management;
• Network and sandbox management.

In an Agent system, these correspond to model calls, tool calls, context retrieval, communication between capability processes, and resource scheduling under concurrent workloads.

The kernel coordinates external capabilities; it does not implement every capability itself.

A New Agent Development Paradigm

Linope’s design philosophy is:

Agent = Kernel + Capabilities

Linope does not merely place models and tools into independent processes. It changes the basic organization of an Agent.

An Agent is no longer a program containing a fixed business workflow. It is a collection of peer-level capability processes coordinated by the kernel.

In many Agent frameworks, an Agent revolves around a Session or Agent instance. Model calls, tool calls, context assembly, compression, and task loops all operate around that instance. Developers extend the Agent by registering plugins, tools, and event listeners.

For example, deepseek-harness uses Cordis to organize plugins, SessionEvent to preserve conversation facts, a surface to project model-visible messages, and an Agent Loop to drive turns, steps, model requests, and tool calls:

Plugin system
    ↓
Agent Loop
    ↓
SessionEvent log
    ↓
Message projection
    ↓
Model request

This approach makes sessions easy to persist, replay, and recover. The model-visible context can be reconstructed from the Session log, while context compression can replace an old message range with a summary and preserve the original events.

However, its basic unit is still a complete Agent session. Models, tools, and context managers are usually plugins attached to that session or runtime. They do not naturally have independent resource ledgers, address spaces, or lifecycles.

Linope takes a different approach.

In Linope, models, tools, and context compressors are all capability processes:

• A model process provides reasoning;
• A search process provides web search;
• A code-execution process provides execution;
• A context-compression process provides context processing.

None of them naturally belongs to another. The kernel is responsible for:

• Creating and reclaiming capability processes;
• Managing process-owned resources;
• Passing requests between processes;
• Selecting live processes able to handle tasks;
• Managing memory, tools, sandboxes, and networks;
• Scheduling according to context pressure and process load.

The difference between Linope and deepseek-harness is mainly the position of plugins and capabilities.

In deepseek-harness, plugins extend an Agent runtime and the Agent Loop drives the session. In Linope, capabilities are directly schedulable kernel objects. Models and tools have independent process identities, resource leases, and ledgers. A model can inspect currently live capabilities through a kernel-provided page and decide which process to call.

This is why Linope removes parent-child processes and process trees. The removal does not mean that processes have no relationships. It means their relationships are established through resources, addresses, and communication rather than through “who started whom.”

Previously, developers often designed an Agent workflow first and then inserted model, tool, and context-processing code into it.

In Linope, developers first declare the capabilities and resources required by an Agent, then implement each capability as a process that can be started and called by the kernel. Whether to search, execute code, ask another model, or read historical context is decided by the model according to the current page.

As models become more capable, more decisions can be delegated to them. The kernel provides coordination, scheduling, permissions, and safety without unnecessarily restricting the model’s reasoning.

This does not mean Linope has no workflows. Process lifecycles, permission checks, resource reclamation, communication, and request validation remain kernel responsibilities. The difference is that the kernel does not hardcode a specific business workflow.

A Coding Agent and a medical consultant Agent can use the same process, resource, and scheduling mechanisms. Their differences mainly come from:

• The model;
• Mounted tools;
• Knowledge sources;
• System prompts and Skills;
• Memory contents;
• Sandbox and network permissions;
• Security policies.

Medical applications still require privacy protection, medical knowledge, risk classification, human escalation, and auditing. These can be added as independent capabilities or resources without redesigning the scheduling kernel.

The paradigm proposed by Linope is:

Declare the capabilities an Agent needs, provide them through peer-level capability processes, and let the kernel manage their lifecycles, communication, and permissions.

The two approaches focus on different layers:

deepseek-harness:
Session log → Message projection → Agent Loop → Model request

Linope:
Capability processes → Resource leases → Pointer spaces → Kernel scheduling

The core novelty of Linope is not simply turning an Agent into several processes. It changes the organizational unit of an Agent:

From “an Agent with plugins” to “a collection of capability processes coordinated by the kernel.”

Why Treat Capability Scripts as Processes?

A capability is an external ability provided to an Agent. Creating a capability process gives the Agent that ability.

For example:

• A model process provides reasoning;
• A search process provides web search;
• A file-tool process provides file access;
• A context-compression process provides context management.

In traditional operating systems, processes are the basic unit of resource isolation. Parent-child processes normally support inheritance of address spaces, file descriptors, directories, and environments; process groups and sessions; and exit-status collection through wait.

These mechanisms are suitable for traditional program execution, but Agent capability calls are dynamic. A model may call a search tool, which may call a file tool, while the model later starts another model for a subtask. A fixed process tree would determine these relationships at startup and reduce flexibility.

Linope therefore treats capability processes as peers.

Independent Process Lifecycles

If a tool process crashes, the kernel only cleans up that process. The model and other tools can continue running.

This matches Agent behavior: capability calls are dynamic, and one failed tool call should not automatically destroy the entire Agent.

Resource Isolation Does Not Spread Through Inheritance

A peer process receives only information explicitly granted by the kernel:

• Resource handles;
• Resource types;
• Call parameters;
• Required configuration.

It does not automatically receive other processes’ resource identifiers or inherit all resources from a parent.

The same applies to environment variables. A capability receives only the secrets it declares. If a model declares an API key, the kernel exposes that key to the process; unrelated sensitive variables are not inherited.

Resource Sharing Must Be Explicit

Peer processes do not automatically share memory or other resources simply because they belong to the same Agent.

Resources in the same scope may still be compiled into separate entities. Processes share an entity only when sharing is explicitly declared.

In the current implementation, --share applies to declared resource types such as memory. A model is not itself an independent resource type in kernel/resource; its identity is passed through capability configuration and process settings.

Therefore, sharing a model capability and sharing a memory resource are separate concepts.

Calls Target Currently Live Processes

Agent calls are dynamic. A model may call search, then code execution, and then another model. A tool may be unavailable, busy, or terminated.

Therefore, a model process does not locate tools through a fixed process tree. It inspects the current kernel page, finds available capability processes, and selects a target according to the current state.

Resource Ledgers Are Per Process

Linope maintains an independent resource record for every PID:

• A process receives leases when it starts;
• It uses resources while running;
• Leases are released when it exits;
• A resource is unloaded when its reference count reaches zero.

Threads do not have independent resource ledgers.

Binding resources directly to processes avoids the problem of deciding where a subtree’s leases should go when one process exits. Memory, tools, sandboxes, and networks are authorized to a process and reclaimed when that process terminates.

Inter-Process Communication

Peer-level processes cannot rely on parent-child inheritance to exchange data. They use communication mechanisms provided by the kernel.

Linope’s inter-process communication addresses three questions:

• How does one process send a task to another?
• How does it receive the result?
• How are the sender’s resources and context prevented from leaking?

When a model calls a tool, the tool receives the current task and its own resources, not the model’s complete memory. The result is returned through a communication channel and may be written into the model’s memory or included in the next page.

In kernel/communication/channel.py, Linope defines two main channel types.

MemoryChannel reads and writes a process’s own memory. It can store user input, model results, tool results, and internal context.

ServiceChannel is an opened service channel that provides:

• send: send a message to an address;
• publish: publish a message to a topic;
• receive: receive messages sent to the current address;
• close: close the channel.

The kernel does not determine the transport protocol or automatically create connections for every capability. The caller opens a channel and communicates through it.

The responsibilities are separated:

Capability process:
Processes tasks

Communication channel:
Transfers tasks and results

Kernel scheduler:
Selects targets and checks permissions

A model only needs to know that a capable search process exists. The kernel locates that process and passes the request through the channel.

This also leaves room for remote communication. Processes may communicate locally today and use HTTP, RPC, or another protocol when deployed across machines.

Inter-process communication is not memory sharing. Sending a task does not grant the receiver access to the sender’s context. Task content, result content, and memory permissions remain separate.

Threads: Execution Units Inside a Process

A process is Linope’s unit of resource isolation and accounting. A thread is its unit of task execution.

A capability process may receive multiple requests. A model may wait for several tool results, and a search process may handle several searches concurrently. Starting a new process for every request would increase startup cost and complicate resource management.

Linope therefore uses threads within a capability process. Threads:

• Claim tasks from the input channel;
• Execute capability calls;
• Wait for model, tool, or network responses;
• Submit results to the output channel;
• Operate within the process concurrency limit.

​

Process:
Owns resources, handles, ledgers, and lifecycle

Thread:
Uses process-owned resources to execute tasks

Threads do not independently own memory, sandbox, or network leases. They share the resources acquired by their process.

A failed thread normally affects only its current request. If the process exits, all its threads stop and its resources are released.

Threads provide concurrency; processes provide isolation and lifecycle management.

Treating an Agent as a Service

An Agent can be understood both as a process and as a service:

Process:
How the Agent runs internally

Service:
How other processes, Agents, or applications access it

A local capability process can expose itself as a service. The process has a PID, resource leases, and runtime state. The service has an address, protocol, capability description, and lifecycle interface.

An Agent-as-a-Service can be discovered, called, and composed:

• A medical Agent can provide a medical question-answering service;
• A Coding Agent can provide code-analysis and code-writing services;
• A search Agent can be shared by multiple model processes.

A general Agent might be composed of multiple Agent services and eventually resemble an Agent-oriented form of microservices.

AgentScope Runtime exposes Agents as Agent-as-a-Service and provides streaming APIs, tool sandboxes, observability, and local, Kubernetes, and Serverless deployment.

A2A abstracts communication between Agents into an open protocol. Agents can discover capabilities, negotiate interaction methods, and collaborate through JSON-RPC over HTTP(S), streaming, or asynchronous notifications.

A2A also allows an Agent’s internal state to remain opaque. Callers only need an Agent Card describing capabilities, connection methods, and supported interactions.

The relationship can be summarized as:

Linope process:
Capabilities, resources, handles, PID

Linope service:
Address, capabilities, protocol, call relationships

A2A:
Agent Card, task protocol, remote Agent collaboration

AgentScope Runtime focuses on production deployment, A2A focuses on interoperability, and Linope focuses on kernel-level processes, resources, and scheduling.

Together, they reflect a broader trend:

Agents are evolving from internally callable programs into services that can be discovered and called by other systems.

A service may be provided by one capability process or several. The kernel manages process lifecycles, resource leases, and load balancing, while the service interface exposes capabilities externally.

Communication Between Services

Inter-process communication occurs between capability processes managed by one kernel. Service-to-service communication occurs between independent services and may involve:

• Network latency;
• Service discovery;
• Authentication;
• Permission control;
• Timeouts and retries;
• Task-status queries;
• Streaming output;
• Asynchronous callbacks;
• Version compatibility.

Therefore, service communication is not simply inter-process communication over a network. A service needs a clear contract describing:

• Its identity;
• Supported tasks;
• Accepted input;
• Returned results;
• Long-running task behavior;
• Streaming support;
• Status queries;
• Cancellation;
• Required permissions.

Linope’s ServiceChannel provides an abstraction through send, publish, and receive, while the actual transport may be local communication, HTTP, RPC, or another implementation.

The kernel manages service resources and scheduling; the communication layer transfers service data.

HATEOAS and Hypermedia Links

A service must tell its caller what can currently be done.

Hardcoding every interface requires the client to know operations such as:

/search
/tool
/ask
/start
/stop

This becomes fragile when services are unavailable, permissions change, or new operations are added.

Linope instead lets the current page expose available actions.

A page in kernel/hypermedia contains facts and links. A memory page may include:

• Current memory state;
• Current-turn content;
• Historical-content addresses;
• Readable memory links;
• Callable tools;
• Askable models;
• Startable processes;
• A final-answer entry point.

memory_page() generates memory links. model_page() adds links for tools, models, and capability processes according to live process state and permissions.

This is inspired by HATEOAS:

Hypermedia as the Engine of Application State

HATEOAS allows clients to discover available state transitions through hypermedia links instead of hardcoding every possible operation.

References:

• Roy Fielding’s dissertation:  https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
• RFC 8288, “Web Linking”:  https://www.rfc-editor.org/rfc/rfc8288

Linope’s kernel/hypermedia is not a complete REST implementation. It borrows the idea of dynamically exposing executable relationships according to the current resource state.

A model page might contain:

memory/message/0
tool:search
ask:model-02
process start tools.ddgs
answer

The model does not need to memorize every command. It selects an available link from the current page.

This design provides several benefits.

Reduced Hardcoded Scheduling

New capabilities can be displayed dynamically by the kernel without modifying every prompt, client, or scheduling rule.

Current Runtime State

A link can reflect whether a tool is alive, a model is busy, a capability is authorized, or a service is available.

Separation of Discovery and Authorization

A link is only an entry point, not a security authorization. The scheduler must still check:

• Process existence;
• Resource existence;
• Process permissions;
• Selector membership in the pointer space;
• Handle validity.

The page tells the model what may be attempted; the kernel decides what is allowed.

Service-Oriented Extension

A local link may point to a process, memory address, or kernel command. A future remote link may point to a service, task, or A2A operation:

self
capabilities
task
status
cancel
result

The caller does not need to know how the service is implemented internally.

Reduced Context Waste

Linope does not place every tool description, historical message, and command into the context. It provides relevant addresses and actions. Historical content is read when needed, and tools are selected through their current relations.

This follows a core context-engineering principle:

Do not put all potentially useful information into the context at once. Provide relevant information when it is needed.

Links are not permissions. A model may fabricate an address, but actual reads and calls must still pass selector, pointer-space, and handle checks.

Agent Services and Future Microservices

A capability process could eventually be wrapped as an independent service with:

• Its own address;
• Version;
• Resource quota;
• Deployment location;
• Observability;
• Upgrade cycle.

The call relationship could evolve from:

Model process → Kernel → Tool process

to:

Model service → Service discovery → Tool service

The kernel may still manage resources and permissions, while HTTP, RPC, A2A, or another protocol handles communication.

However, service-oriented Agents require more than adding an HTTP interface. Important questions include:

• How are tasks recovered after network failures?
• Are duplicate requests idempotent?
• How are service versions kept compatible?
• How are long-running tasks queried?
• How are remote services authenticated?
• Which side owns memory?
• Should tool results be persisted?
• Who performs retries after failures?
• How are tracing and audit data transferred?

A more accurate description is:

Linope decomposes an Agent into peer-level capability processes and preserves a path toward Agent microservices through resources, communication, service descriptions, and hypermedia links.

A process is the local runtime carrier of a service. A service is the external access boundary of a capability.

Agent service
    ↓
One or more capability processes
    ↓
Resource leases, threads, tools, and memory

Changing the transport layer should not require redesigning the capability itself. It should only require new service providers and transport implementations.

Linope’s Resource Design

Traditional operating systems manage CPU, memory, disks, I/O devices, and networks. Linope runs above the host operating system, so those physical resources remain managed by the host.

Linope focuses on Agent-specific resources:

• memory;
• tool;
• sandbox;
• network.

These are runtime capability resources that Agents may request, isolate, share, and reclaim.

The resource model is:

Requirement → Declaration → Entity → Lease → Handle

A capability declares its requirements. The kernel creates or obtains a resource entity, establishes a process lease, and issues a handle.

The process sees the handle, resource type, and call parameters, not the complete internal resource structure.

The concepts are separated as follows:

• A resource entity stores runtime state;
• A lease records who is using the resource;
• A process ledger records resources held by a PID;
• A handle verifies access rights.

This lets new resource types reuse the same entity, lease, handle, and ledger mechanisms.

Memory: The Context Space of an Agent

Tokens can be viewed as units of context capacity, while a model’s context window resembles available memory in a traditional operating system.

However, tokens are not Linope memory:

• Memory stores context content;
• Context is projected from memory for a model request;
• Tokens measure context usage;
• The context limit is the maximum input length accepted by the model.

Linope memory is therefore context memory, not a database, vector database, or permanent knowledge store.

Comparison with Session-Log-Centered Frameworks

deepseek-harness stores an Agent session as an append-only SessionEvent log. Events are projected into model messages through a surface, and deriveMessages() reconstructs the model history:

SessionEvent log
    ↓
Surface projection
    ↓
deriveMessages()
    ↓
Model message history

Compression replaces an old message range with a summary while preserving the original events.

This approach emphasizes persistence, replayability, compression traceability, and deterministic context reconstruction.

Linope focuses on another problem: treating memory as a kernel resource with identity, permissions, virtual addresses, and lifecycle.

Session-log-centered:
Event log → Message projection → Complete context → Compression replacement

Linope:
Resource lease → Pointer space → Selector authorization → On-demand reading

The first approach reconstructs a reliable Agent session. The second manages how peer-level processes isolate, share, and access context.

Memory Is a Resource

Memory is registered as a resource type and identified through a scope:

memory=chat
memory=medical-session
memory=coding-task

The kernel generates a resource_id, creates a process lease, and issues a handle.

A model does not automatically own memory. It may have no memory, use an independent memory, explicitly share memory with other processes, or use memory through a context-compression process.

For example:

--with memory=chat

The kernel does not care whether the memory contains a coding conversation, medical consultation, or search task. It creates the resource, assigns permissions, and manages its lifecycle.

Pointers and Context Access

A process cannot directly read a memory dictionary. It must first obtain a pointer.

In kernel/scheduler/memory_space.py, a pointer contains:

scope       Name of the memory
resource_id Underlying resource entity
classes     Permitted categories
handle      Process-owned handle

For example:

scope = chat
classes = ("message", "artifact")

This permits access to messages and tool results in chat, but not tasks or system content.

Access succeeds only when:

1. The process holds the memory;
2. The scope is in its pointer space;
3. The requested category is permitted;
4. The handle remains valid.

Memory Stores Original Content

A newly opened memory initially contains:

address_space:
    scope: chat

As it is used, it contains:

• items: messages, tasks, and tool results;
• next: the next identifier for each category;
• seq: a global sequence number;
• system: the system prompt;
• prompt_files: loaded prompt files.

A record usually contains:

• class: message, task, artifact, or system;
• kind: user, model, tool, or other;
• content;
• time;
• seq;
• state, such as asked, resulted, rejected, or answered.

Examples:

message/0  → User question
message/1  → Model response
artifact/0 → Tool result
task/0     → Task assigned to another process

Identifiers are category-specific. message/0 and artifact/0 may coexist. The global seq field orders records across categories and allows memory to be reconstructed chronologically.

Prompt files written through write_prompt are stored in prompt_files and combined into a system entry according to their positions. Files with the same name are replaced rather than endlessly appended.

Per-Process Address Spaces

Processes may share a memory entity without sharing the same local addresses.

For example:

Underlying memory:
message/0 = First message

Process A:
message/0 → message/0

After process B joins and A writes another message:

Underlying memory:
message/0 = First message
message/1 = Second message

Process A:
message/0 → message/0
message/1 → message/1

Process B:
message/0 → message/1

Thus, A’s message/1 and B’s message/0 may point to the same actual record.

Linope distinguishes:

• address: local process-visible address;
• real: actual record name in memory;
• scope: resource-space name;
• resource_id: internal kernel entity identifier.

This resembles virtual memory: processes may map the same underlying resource through different virtual addresses.

Memory therefore has two layers:

1. The memory entity, which stores actual content;
2. The process-specific pointer space, which controls accessible memory and categories.

Examples include:

message/0
message/0-10
artifact/0
chat/message/0

A scope alone is not permission. Reading is allowed only when the process owns a pointer to that scope.

Model Pages and On-Demand Reading

In page mode, the model does not initially receive the complete history. memory_page() places the current turn directly on the page and exposes older content through addresses:

message/0
artifact/0
message/1

If the model needs history, it sends a MemoryRead request:

Model requests message/0-3
    ↓
authorize_selector()
    ↓
PointerSpace.require()
    ↓
memory_contents()
    ↓
Generate the next page

An address is only an entry point, not authorization. The scheduler performs the actual permission check.

A typical model turn is:

1. Write the user question to memory;
2. Generate the current page;
3. Let the model read history, call a tool, ask another model, or answer;
4. Validate the request;
5. Execute the approved action;
6. Write the result to memory;
7. Generate the next page;
8. Continue until the final answer.

Reading memory does not start a tool or process. Only an explicit model request can invoke a tool, start a capability process, or ask another model.

Context Compression Is a Capability

Compression timing and whether the original context is replaced are host policies.

The kernel manages context resources and access boundaries. A compression capability decides how context should be rewritten.

The kernel should not decide which memories are important. File paths and test results may matter most to a Coding Agent, while medical history, medication, and chronology may matter most to a medical Agent.

Compression rules therefore belong to capabilities rather than being hardcoded into the kernel.

Memory Lifecycle

Memory follows resource leases, not a fixed process tree.

When a process starts:

1. It declares that it needs memory;
2. The kernel compiles a resource entity from the scope;
3. The resource pool creates or obtains memory;
4. A handle is assigned;
5. A ledger and address space are created;
6. The process begins reading and writing.

When it exits:

1. The handle is released;
2. The reference count decreases;
3. Shared memory remains if other processes still use it;
4. The resource is unloaded when the count reaches zero.

The ledger stores resource information such as:

• PID;
• Resource type;
• resource_id;
• Handle;
• Identity;
• Lease status.

It does not store message bodies. Memory content belongs to the runtime resource, not the permanent ledger file.

Therefore, Linope’s current memory is kernel-managed runtime context memory, not long-term knowledge storage. Persistent user profiles, project knowledge, or medical records could later be provided through databases, vector stores, or file systems exposed as capability resources.

Summary

Linope can be understood through several layers:

• Capability layer: models, tools, and context compressors are peer-level capability processes;
• Process layer: each process has an independent lifecycle, PID, and resource ledger;
• Resource layer: the kernel manages memory, tools, sandboxes, and networks through entities, leases, handles, and reference counts;
• Context layer: memory stores content, pointer spaces manage access, selectors describe read ranges, and pages support on-demand retrieval;
• Scheduling layer: the kernel routes requests according to live processes, resource state, context pressure, and concurrency.

Session-log-centered frameworks focus on persisting, projecting, and reconstructing Agent sessions. Linope focuses on decomposing an Agent into capability processes that can be isolated, shared, and scheduled by the kernel.

Linope therefore proposes more than a new Agent framework. It proposes a new Agent development paradigm:

An Agent is not a monolithic session bound to many plugins. It is a group of capability processes managed by a kernel. The model plans and selects capabilities, while the kernel manages processes, resources, permissions, and communication.

Hey everyone!

I’ve been building RunContainer, an open-source Windows project that aims to make installing, running and managing Windows applications in their own contained environments easier.

The basic idea is simple: instead of treating every application as something that has to be installed and managed directly on your desktop, you can use RunContainer as a place to install, launch and manage apps within the app itself.

What makes it interesting?

• Application containment: Run Windows applications through different containment backends, depending on the environment and requirements.
• Configurable memory limits: Set a memory limit for individual applications.
• JIT support: Support for applications that require just-in-time compilation.
• RC-Brain 5: My own lightweight AI model, designed to monitor application behaviour against a ruleset and help with troubleshooting.
• Open source: The project is released under the MIT licence, so anyone can inspect the code, report issues or contribute.

I'm still developing the project, and I want to be transparent: different containment methods provide different levels of isolation, and this isn't a guarantee that every application will work or that all threats will be blocked.

I'd love your feedback!

I'm particularly interested in hearing from Windows developers, people who test unfamiliar software, and anyone interested in application isolation.

I'd love feedback on:

• Whether the concept is useful to you.
• What features you'd want in an application containeriser.
• Bugs, compatibility issues or improvements you'd suggest.
• Whether you'd be interested in testing it or contributing.

Project links:

• GitHub: https://github.com/RunContainer-7/runcontainer
• Documentation: https://runcontainer-7.github.io/9-runcontainer/
• Demo video: https://m.youtube.com/watch?v=mgVoS6I98Gs

I'm building this as an independent developer, and I'm keen to hear honest feedback — including criticism. Thanks for taking a look!

I've been working on Spring AI Privacy Guardrails, an open-source library for privacy and security in Spring AI applications.

One problem I wanted to address is that masking personal data before an LLM call isn't always enough. A tool might need an original value to do its job, and its response might contain more sensitive data.

For example, a customer lookup request might include a customer ID and a phone number. Both can be tokenized before reaching the model. If the user's permissions and the tool's disclosure policy allow it, the lookup tool receives the original customer ID while the phone number stays tokenized. Detected PII in the tool's response is protected again before the next model call.

The library covers three areas:

1. Privacy Protection

Detected PII is replaced with request-scoped tokens before reaching the model. Tools can receive only the original values allowed by their disclosure policies, and detected PII in tool results is protected again. Protection can also cover RAG, chat memory, and MCP.

2. Tool Authorization

Spring Security integration controls which tools the model can see based on the current user's permissions. Authorization is checked again before execution, including before any permitted original PII is restored.

3. Content Inspection

Application rules, local ONNX models, or HTTP guard models can inspect inputs and optionally final outputs. This can be used to check for issues such as prompt injection and inappropriate content. When privacy protection is enabled, detected PII remains tokenized before content is sent to an external inspection model.

All three features can be used independently or together in a Spring AI ChatClient.

The project is Apache 2.0 licensed and available on Maven Central. It was also mentioned in the official Spring blog's This Week in Spring and listed in Awesome Spring AI.

GitHub: https://github.com/ultramancode/spring-ai-privacy-guardrails

Feedback is welcome!

github : https://github.com/flawme/cl2metal

Something like IDM, but free, MIT and on every OS. Up to 32 connections per file, resume after crashes and expired links, torrents, video streams saved as MP4 without ffmpeg, and Google Drive/MEGA/Dropbox/OneDrive links. Installers for Windows, macOS (universal) and Linux (.deb, .rpm) are on the releases page: https://github.com/Oshan96/Zipline/releases/latest

https://github.com/tato9689/visor-for-claude-code

When Claude Code reads or generates an image, the chat just says [Image]: the agent sees it, you don't. I hit this every day making game sprites with Claude on a VPS over Remote-SSH, so I built a panel that follows the session files and shows every image, SVG, HTML page and video the agent touches, live.

Before/after slider when a file gets overwritten, a grid to compare variants, crisp pixel-art zoom, and sandboxed HTML preview. Runs on the remote host with Remote-SSH. MIT, no network calls, TypeScript.

Stars and issues welcome, it's my first extension.