{"slug": "how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels", "title": "How Do Agent System Kernels Differ from Traditional Operating System Kernels?", "summary": "A developer built Linope, an Agent kernel that applies traditional operating-system concepts—process and thread management, inter-process communication, load balancing, resource and sandbox management—to coordinating AI agent capabilities. Linope defines an agent as \"Kernel + Capabilities,\" loading models, tools, and services as peer-level capability processes rather than plugins attached to a fixed session, in contrast to frameworks like deepseek-harness that organize around a SessionEvent log and Agent Loop.", "body_md": "The road ahead is long and arduous; I shall seek high and low.\n\nThis report introduces Linope’s design philosophy, development paradigm, and core technical ideas in an accessible way.\n\nAbstract\n\nAs more developers build Agents, an important question has emerged:\n\nWhat is the difference between the kernel of an Agent system and that of a traditional operating system?\n\nMotivated 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.\n\nThe report focuses on:\n\nLinope’s design philosophy;\n\nLinope’s Agent development paradigm.\n\nI have often wondered: if a Coding Agent and a medical consultant Agent used the same kernel, where would their differences lie?\n\nIf we replace their tools, prompts, knowledge sources, and MCP integrations, could a Coding Agent become a medical consultant Agent?\n\nModern 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.\n\nThis 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.\n\nThe 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.\n\nTherefore, Linope defines an Agent as:\n\nAgent = Kernel + Capabilities\n\nIn 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.\n\nFollowing this idea, an Agent OS kernel can manage processes, threads, and resources, including:\n\nInter-process communication;\n\nProcess lifecycles;\n\nThread startup and concurrency control;\n\nLoad balancing;\n\nResource management;\n\nContext management;\n\nNetwork and sandbox management.\n\nIn an Agent system, these correspond to model calls, tool calls, context retrieval, communication between capability processes, and resource scheduling under concurrent workloads.\n\nThe kernel coordinates external capabilities; it does not implement every capability itself.\n\nA New Agent Development Paradigm\n\nLinope’s design philosophy is:\n\nAgent = Kernel + Capabilities\n\nLinope does not merely place models and tools into independent processes. It changes the basic organization of an Agent.\n\nAn Agent is no longer a program containing a fixed business workflow. It is a collection of peer-level capability processes coordinated by the kernel.\n\nIn 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.\n\nFor 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:\n\nPlugin system\n\n    ↓\n\nAgent Loop\n\n    ↓\n\nSessionEvent log\n\n    ↓\n\nMessage projection\n\n    ↓\n\nModel request\n\nThis 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.\n\nHowever, 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.\n\nLinope takes a different approach.\n\nIn Linope, models, tools, and context compressors are all capability processes:\n\nA model process provides reasoning;\n\nA search process provides web search;\n\nA code-execution process provides execution;\n\nA context-compression process provides context processing.\n\nNone of them naturally belongs to another. The kernel is responsible for:\n\nCreating and reclaiming capability processes;\n\nManaging process-owned resources;\n\nPassing requests between processes;\n\nSelecting live processes able to handle tasks;\n\nManaging memory, tools, sandboxes, and networks;\n\nScheduling according to context pressure and process load.\n\nThe difference between Linope and deepseek-harness is mainly the position of plugins and capabilities.\n\nIn 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.\n\nThis 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.”\n\nPreviously, developers often designed an Agent workflow first and then inserted model, tool, and context-processing code into it.\n\nIn 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.\n\nAs 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.\n\nThis 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.\n\nA Coding Agent and a medical consultant Agent can use the same process, resource, and scheduling mechanisms. Their differences mainly come from:\n\nThe model;\n\nMounted tools;\n\nKnowledge sources;\n\nSystem prompts and Skills;\n\nMemory contents;\n\nSandbox and network permissions;\n\nSecurity policies.\n\nMedical 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.\n\nThe paradigm proposed by Linope is:\n\nDeclare the capabilities an Agent needs, provide them through peer-level capability processes, and let the kernel manage their lifecycles, communication, and permissions.\n\nThe two approaches focus on different layers:\n\ndeepseek-harness:\n\nSession log → Message projection → Agent Loop → Model request\n\nLinope:\n\nCapability processes → Resource leases → Pointer spaces → Kernel scheduling\n\nThe core novelty of Linope is not simply turning an Agent into several processes. It changes the organizational unit of an Agent:\n\nFrom “an Agent with plugins” to “a collection of capability processes coordinated by the kernel.”\n\nWhy Treat Capability Scripts as Processes?\n\nA capability is an external ability provided to an Agent. Creating a capability process gives the Agent that ability.\n\nFor example:\n\nA model process provides reasoning;\n\nA search process provides web search;\n\nA file-tool process provides file access;\n\nA context-compression process provides context management.\n\nIn 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.\n\nThese 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.\n\nLinope therefore treats capability processes as peers.\n\nIndependent Process Lifecycles\n\nIf a tool process crashes, the kernel only cleans up that process. The model and other tools can continue running.\n\nThis matches Agent behavior: capability calls are dynamic, and one failed tool call should not automatically destroy the entire Agent.\n\nResource Isolation Does Not Spread Through Inheritance\n\nA peer process receives only information explicitly granted by the kernel:\n\nResource handles;\n\nResource types;\n\nCall parameters;\n\nRequired configuration.\n\nIt does not automatically receive other processes’ resource identifiers or inherit all resources from a parent.\n\nThe 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.\n\nResource Sharing Must Be Explicit\n\nPeer processes do not automatically share memory or other resources simply because they belong to the same Agent.\n\nResources in the same scope may still be compiled into separate entities. Processes share an entity only when sharing is explicitly declared.\n\nIn 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.\n\nTherefore, sharing a model capability and sharing a memory resource are separate concepts.\n\nCalls Target Currently Live Processes\n\nAgent calls are dynamic. A model may call search, then code execution, and then another model. A tool may be unavailable, busy, or terminated.\n\nTherefore, 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.\n\nResource Ledgers Are Per Process\n\nLinope maintains an independent resource record for every PID:\n\nA process receives leases when it starts;\n\nIt uses resources while running;\n\nLeases are released when it exits;\n\nA resource is unloaded when its reference count reaches zero.\n\nThreads do not have independent resource ledgers.\n\nBinding 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.\n\nInter-Process Communication\n\nPeer-level processes cannot rely on parent-child inheritance to exchange data. They use communication mechanisms provided by the kernel.\n\nLinope’s inter-process communication addresses three questions:\n\nHow does one process send a task to another?\n\nHow does it receive the result?\n\nHow are the sender’s resources and context prevented from leaking?\n\nWhen 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.\n\nIn kernel/communication/channel.py, Linope defines two main channel types.\n\nMemoryChannel reads and writes a process’s own memory. It can store user input, model results, tool results, and internal context.\n\nServiceChannel is an opened service channel that provides:\n\nsend: send a message to an address;\n\npublish: publish a message to a topic;\n\nreceive: receive messages sent to the current address;\n\nclose: close the channel.\n\nThe kernel does not determine the transport protocol or automatically create connections for every capability. The caller opens a channel and communicates through it.\n\nThe responsibilities are separated:\n\nCapability process:\n\nProcesses tasks\n\nCommunication channel:\n\nTransfers tasks and results\n\nKernel scheduler:\n\nSelects targets and checks permissions\n\nA model only needs to know that a capable search process exists. The kernel locates that process and passes the request through the channel.\n\nThis also leaves room for remote communication. Processes may communicate locally today and use HTTP, RPC, or another protocol when deployed across machines.\n\nInter-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.\n\nThreads: Execution Units Inside a Process\n\nA process is Linope’s unit of resource isolation and accounting. A thread is its unit of task execution.\n\nA 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.\n\nLinope therefore uses threads within a capability process. Threads:\n\nClaim tasks from the input channel;\n\nExecute capability calls;\n\nWait for model, tool, or network responses;\n\nSubmit results to the output channel;\n\nOperate within the process concurrency limit.\n\nProcess:\n\nOwns resources, handles, ledgers, and lifecycle\n\nThread:\n\nUses process-owned resources to execute tasks\n\nThreads do not independently own memory, sandbox, or network leases. They share the resources acquired by their process.\n\nA failed thread normally affects only its current request. If the process exits, all its threads stop and its resources are released.\n\nThreads provide concurrency; processes provide isolation and lifecycle management.\n\nTreating an Agent as a Service\n\nAn Agent can be understood both as a process and as a service:\n\nProcess:\n\nHow the Agent runs internally\n\nService:\n\nHow other processes, Agents, or applications access it\n\nA 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.\n\nAn Agent-as-a-Service can be discovered, called, and composed:\n\nA medical Agent can provide a medical question-answering service;\n\nA Coding Agent can provide code-analysis and code-writing services;\n\nA search Agent can be shared by multiple model processes.\n\nA general Agent might be composed of multiple Agent services and eventually resemble an Agent-oriented form of microservices.\n\nAgentScope Runtime exposes Agents as Agent-as-a-Service and provides streaming APIs, tool sandboxes, observability, and local, Kubernetes, and Serverless deployment.\n\nA2A 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.\n\nA2A also allows an Agent’s internal state to remain opaque. Callers only need an Agent Card describing capabilities, connection methods, and supported interactions.\n\nThe relationship can be summarized as:\n\nLinope process:\n\nCapabilities, resources, handles, PID\n\nLinope service:\n\nAddress, capabilities, protocol, call relationships\n\nA2A:\n\nAgent Card, task protocol, remote Agent collaboration\n\nAgentScope Runtime focuses on production deployment, A2A focuses on interoperability, and Linope focuses on kernel-level processes, resources, and scheduling.\n\nTogether, they reflect a broader trend:\n\nAgents are evolving from internally callable programs into services that can be discovered and called by other systems.\n\nA 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.\n\nCommunication Between Services\n\nInter-process communication occurs between capability processes managed by one kernel. Service-to-service communication occurs between independent services and may involve:\n\nNetwork latency;\n\nService discovery;\n\nAuthentication;\n\nPermission control;\n\nTimeouts and retries;\n\nTask-status queries;\n\nStreaming output;\n\nAsynchronous callbacks;\n\nVersion compatibility.\n\nTherefore, service communication is not simply inter-process communication over a network. A service needs a clear contract describing:\n\nIts identity;\n\nSupported tasks;\n\nAccepted input;\n\nReturned results;\n\nLong-running task behavior;\n\nStreaming support;\n\nStatus queries;\n\nCancellation;\n\nRequired permissions.\n\nLinope’s ServiceChannel provides an abstraction through send, publish, and receive, while the actual transport may be local communication, HTTP, RPC, or another implementation.\n\nThe kernel manages service resources and scheduling; the communication layer transfers service data.\n\nHATEOAS and Hypermedia Links\n\nA service must tell its caller what can currently be done.\n\nHardcoding every interface requires the client to know operations such as:\n\n/search\n\n/tool\n\n/ask\n\n/start\n\n/stop\n\nThis becomes fragile when services are unavailable, permissions change, or new operations are added.\n\nLinope instead lets the current page expose available actions.\n\nA page in kernel/hypermedia contains facts and links. A memory page may include:\n\nCurrent memory state;\n\nCurrent-turn content;\n\nHistorical-content addresses;\n\nReadable memory links;\n\nCallable tools;\n\nAskable models;\n\nStartable processes;\n\nA final-answer entry point.\n\nmemory_page() generates memory links. model_page() adds links for tools, models, and capability processes according to live process state and permissions.\n\nThis is inspired by HATEOAS:\n\nHypermedia as the Engine of Application State\n\nHATEOAS allows clients to discover available state transitions through hypermedia links instead of hardcoding every possible operation.\n\nLinope’s kernel/hypermedia is not a complete REST implementation. It borrows the idea of dynamically exposing executable relationships according to the current resource state.\n\nA model page might contain:\n\nmemory/message/0\n\ntool:search\n\nask:model-02\n\nprocess start tools.ddgs\n\nanswer\n\nThe model does not need to memorize every command. It selects an available link from the current page.\n\nThis design provides several benefits.\n\nReduced Hardcoded Scheduling\n\nNew capabilities can be displayed dynamically by the kernel without modifying every prompt, client, or scheduling rule.\n\nCurrent Runtime State\n\nA link can reflect whether a tool is alive, a model is busy, a capability is authorized, or a service is available.\n\nSeparation of Discovery and Authorization\n\nA link is only an entry point, not a security authorization. The scheduler must still check:\n\nProcess existence;\n\nResource existence;\n\nProcess permissions;\n\nSelector membership in the pointer space;\n\nHandle validity.\n\nThe page tells the model what may be attempted; the kernel decides what is allowed.\n\nService-Oriented Extension\n\nA 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:\n\nself\n\ncapabilities\n\ntask\n\nstatus\n\ncancel\n\nresult\n\nThe caller does not need to know how the service is implemented internally.\n\nReduced Context Waste\n\nLinope 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.\n\nThis follows a core context-engineering principle:\n\nDo not put all potentially useful information into the context at once. Provide relevant information when it is needed.\n\nLinks are not permissions. A model may fabricate an address, but actual reads and calls must still pass selector, pointer-space, and handle checks.\n\nAgent Services and Future Microservices\n\nA capability process could eventually be wrapped as an independent service with:\n\nIts own address;\n\nVersion;\n\nResource quota;\n\nDeployment location;\n\nObservability;\n\nUpgrade cycle.\n\nThe call relationship could evolve from:\n\nModel process → Kernel → Tool process\n\nto:\n\nModel service → Service discovery → Tool service\n\nThe kernel may still manage resources and permissions, while HTTP, RPC, A2A, or another protocol handles communication.\n\nHowever, service-oriented Agents require more than adding an HTTP interface. Important questions include:\n\nHow are tasks recovered after network failures?\n\nAre duplicate requests idempotent?\n\nHow are service versions kept compatible?\n\nHow are long-running tasks queried?\n\nHow are remote services authenticated?\n\nWhich side owns memory?\n\nShould tool results be persisted?\n\nWho performs retries after failures?\n\nHow are tracing and audit data transferred?\n\nA more accurate description is:\n\nLinope decomposes an Agent into peer-level capability processes and preserves a path toward Agent microservices through resources, communication, service descriptions, and hypermedia links.\n\nA process is the local runtime carrier of a service. A service is the external access boundary of a capability.\n\nAgent service\n\n    ↓\n\nOne or more capability processes\n\n    ↓\n\nResource leases, threads, tools, and memory\n\nChanging the transport layer should not require redesigning the capability itself. It should only require new service providers and transport implementations.\n\nLinope’s Resource Design\n\nTraditional 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.\n\nLinope focuses on Agent-specific resources:\n\nmemory;\n\ntool;\n\nsandbox;\n\nnetwork.\n\nThese are runtime capability resources that Agents may request, isolate, share, and reclaim.\n\nThe resource model is:\n\nRequirement → Declaration → Entity → Lease → Handle\n\nA capability declares its requirements. The kernel creates or obtains a resource entity, establishes a process lease, and issues a handle.\n\nThe process sees the handle, resource type, and call parameters, not the complete internal resource structure.\n\nThe concepts are separated as follows:\n\nA resource entity stores runtime state;\n\nA lease records who is using the resource;\n\nA process ledger records resources held by a PID;\n\nA handle verifies access rights.\n\nThis lets new resource types reuse the same entity, lease, handle, and ledger mechanisms.\n\nMemory: The Context Space of an Agent\n\nTokens can be viewed as units of context capacity, while a model’s context window resembles available memory in a traditional operating system.\n\nHowever, tokens are not Linope memory:\n\nMemory stores context content;\n\nContext is projected from memory for a model request;\n\nTokens measure context usage;\n\nThe context limit is the maximum input length accepted by the model.\n\nLinope memory is therefore context memory, not a database, vector database, or permanent knowledge store.\n\nComparison with Session-Log-Centered Frameworks\n\ndeepseek-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:\n\nSessionEvent log\n\n    ↓\n\nSurface projection\n\n    ↓\n\nderiveMessages()\n\n    ↓\n\nModel message history\n\nCompression replaces an old message range with a summary while preserving the original events.\n\nThis approach emphasizes persistence, replayability, compression traceability, and deterministic context reconstruction.\n\nLinope focuses on another problem: treating memory as a kernel resource with identity, permissions, virtual addresses, and lifecycle.\n\nSession-log-centered:\n\nEvent log → Message projection → Complete context → Compression replacement\n\nLinope:\n\nResource lease → Pointer space → Selector authorization → On-demand reading\n\nThe first approach reconstructs a reliable Agent session. The second manages how peer-level processes isolate, share, and access context.\n\nMemory Is a Resource\n\nMemory is registered as a resource type and identified through a scope:\n\nmemory=chat\n\nmemory=medical-session\n\nmemory=coding-task\n\nThe kernel generates a resource_id, creates a process lease, and issues a handle.\n\nA 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.\n\nFor example:\n\n--with memory=chat\n\nThe 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.\n\nPointers and Context Access\n\nA process cannot directly read a memory dictionary. It must first obtain a pointer.\n\nIn kernel/scheduler/memory_space.py, a pointer contains:\n\nscope       Name of the memory\n\nresource_id Underlying resource entity\n\nclasses     Permitted categories\n\nhandle      Process-owned handle\n\nFor example:\n\nscope = chat\n\nclasses = (\"message\", \"artifact\")\n\nThis permits access to messages and tool results in chat, but not tasks or system content.\n\nAccess succeeds only when:\n\nThe process holds the memory;\n\nThe scope is in its pointer space;\n\nThe requested category is permitted;\n\nThe handle remains valid.\n\nMemory Stores Original Content\n\nA newly opened memory initially contains:\n\naddress_space:\n\n    scope: chat\n\nAs it is used, it contains:\n\nitems: messages, tasks, and tool results;\n\nnext: the next identifier for each category;\n\nseq: a global sequence number;\n\nsystem: the system prompt;\n\nprompt_files: loaded prompt files.\n\nA record usually contains:\n\nclass: message, task, artifact, or system;\n\nkind: user, model, tool, or other;\n\ncontent;\n\ntime;\n\nseq;\n\nstate, such as asked, resulted, rejected, or answered.\n\nExamples:\n\nmessage/0  → User question\n\nmessage/1  → Model response\n\nartifact/0 → Tool result\n\ntask/0     → Task assigned to another process\n\nIdentifiers 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.\n\nPrompt 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.\n\nPer-Process Address Spaces\n\nProcesses may share a memory entity without sharing the same local addresses.\n\nFor example:\n\nUnderlying memory:\n\nmessage/0 = First message\n\nProcess A:\n\nmessage/0 → message/0\n\nAfter process B joins and A writes another message:\n\nUnderlying memory:\n\nmessage/0 = First message\n\nmessage/1 = Second message\n\nProcess A:\n\nmessage/0 → message/0\n\nmessage/1 → message/1\n\nProcess B:\n\nmessage/0 → message/1\n\nThus, A’s message/1 and B’s message/0 may point to the same actual record.\n\nLinope distinguishes:\n\naddress: local process-visible address;\n\nreal: actual record name in memory;\n\nscope: resource-space name;\n\nresource_id: internal kernel entity identifier.\n\nThis resembles virtual memory: processes may map the same underlying resource through different virtual addresses.\n\nMemory therefore has two layers:\n\nThe memory entity, which stores actual content;\n\nThe process-specific pointer space, which controls accessible memory and categories.\n\nExamples include:\n\nmessage/0\n\nmessage/0-10\n\nartifact/0\n\nchat/message/0\n\nA scope alone is not permission. Reading is allowed only when the process owns a pointer to that scope.\n\nModel Pages and On-Demand Reading\n\nIn 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:\n\nmessage/0\n\nartifact/0\n\nmessage/1\n\nIf the model needs history, it sends a MemoryRead request:\n\nModel requests message/0-3\n\n    ↓\n\nauthorize_selector()\n\n    ↓\n\nPointerSpace.require()\n\n    ↓\n\nmemory_contents()\n\n    ↓\n\nGenerate the next page\n\nAn address is only an entry point, not authorization. The scheduler performs the actual permission check.\n\nA typical model turn is:\n\nWrite the user question to memory;\n\nGenerate the current page;\n\nLet the model read history, call a tool, ask another model, or answer;\n\nValidate the request;\n\nExecute the approved action;\n\nWrite the result to memory;\n\nGenerate the next page;\n\nContinue until the final answer.\n\nReading 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.\n\nContext Compression Is a Capability\n\nCompression timing and whether the original context is replaced are host policies.\n\nThe kernel manages context resources and access boundaries. A compression capability decides how context should be rewritten.\n\nThe 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.\n\nCompression rules therefore belong to capabilities rather than being hardcoded into the kernel.\n\nMemory Lifecycle\n\nMemory follows resource leases, not a fixed process tree.\n\nWhen a process starts:\n\nIt declares that it needs memory;\n\nThe kernel compiles a resource entity from the scope;\n\nThe resource pool creates or obtains memory;\n\nA handle is assigned;\n\nA ledger and address space are created;\n\nThe process begins reading and writing.\n\nWhen it exits:\n\nThe handle is released;\n\nThe reference count decreases;\n\nShared memory remains if other processes still use it;\n\nThe resource is unloaded when the count reaches zero.\n\nThe ledger stores resource information such as:\n\nPID;\n\nResource type;\n\nresource_id;\n\nHandle;\n\nIdentity;\n\nLease status.\n\nIt does not store message bodies. Memory content belongs to the runtime resource, not the permanent ledger file.\n\nTherefore, 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.\n\nSummary\n\nLinope can be understood through several layers:\n\nCapability layer: models, tools, and context compressors are peer-level capability processes;\n\nProcess layer: each process has an independent lifecycle, PID, and resource ledger;\n\nResource layer: the kernel manages memory, tools, sandboxes, and networks through entities, leases, handles, and reference counts;\n\nContext layer: memory stores content, pointer spaces manage access, selectors describe read ranges, and pages support on-demand retrieval;\n\nScheduling layer: the kernel routes requests according to live processes, resource state, context pressure, and concurrency.\n\nSession-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.\n\nLinope therefore proposes more than a new Agent framework. It proposes a new Agent development paradigm:\n\nAn 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.\n\nYou can search for answeryt/Linope on GitHub to learn more about the technical details and implementation.", "url": "https://wpnews.pro/news/how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels", "canonical_source": "https://dev.to/answeryt/how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels-8og", "published_at": "2026-10-27 15:34:33+00:00", "updated_at": "2026-10-27 15:42:00.269917+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools", "developer-tools"], "entities": ["Linope", "deepseek-harness", "Cordis", "DeepSeek", "Claude Code", "Codex"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels", "markdown": "https://wpnews.pro/news/how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels.md", "text": "https://wpnews.pro/news/how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels.txt", "jsonld": "https://wpnews.pro/news/how-do-agent-system-kernels-differ-from-traditional-operating-system-kernels.jsonld"}}