DEV Community: answeryt

How Do Agent System Kernels Differ from Traditional Operating System Kernels?

answeryt — Tue, 27 Oct 2026 15:34:33 +0000

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.
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:
The process holds the memory;
The scope is in its pointer space;
The requested category is permitted;
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:
The memory entity, which stores actual content;
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:
Write the user question to memory;
Generate the current page;
Let the model read history, call a tool, ask another model, or answer;
Validate the request;
Execute the approved action;
Write the result to memory;
Generate the next page;
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:
It declares that it needs memory;
The kernel compiles a resource entity from the scope;
The resource pool creates or obtains memory;
A handle is assigned;
A ledger and address space are created;
The process begins reading and writing.
When it exits:
The handle is released;
The reference count decreases;
Shared memory remains if other processes still use it;
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.

You can search for answeryt/Linope on GitHub to learn more about the technical details and implementation.

The 'Demo Spell' and 'Production Dilemma' of AI Agents: How I Built a Self-Learning Agent System

answeryt — Wed, 20 Aug 2025 09:53:27 +0000

Introduction: From "Amazing" to "Usable," How Far Do AI Agents Still Have to Go?
Since 2024, "AI Agent" has undoubtedly been the hottest term in the tech community. From the shock of AutoGPT to the agent frameworks launched by major companies (like the very famous LangChain, LlamaIndex, etc.), we've all seen an exciting future: a "digital employee" capable of understanding complex instructions, planning autonomously, and executing tasks. The stunning demo videos on social media seem to be heralding a new era.

However, like every wave of technology, once the initial excitement fades, sober reflection emerges. I believe there are three "hard truths" facing AI Agents today:

Fragile Systems: In multi-step workflows, every small failure rate is amplified exponentially, causing the success rate of the entire task chain to be shockingly low.

High Costs: As conversations and tasks progress, the ever-growing context window leads to quadratic token costs, making them commercially unsustainable.

Mismatched Design: The industry generally pins its hopes on more powerful LLMs, but the real bottleneck is how to design "tools" that agents can effectively understand and use, and a "feedback system" that allows them to learn from failure. This requires agent framework developers to find a very clever balance between failure and feedback.

An amazing demo might only need to succeed once, but a stable and reliable production system must work correctly 99% of the time, which is clearly something current AI agents cannot do.

Undeniably, current AI has already demonstrated astonishing capabilities in many scenarios. As a developer, I also enjoy the efficiency dividends brought by AI. Programming assistants like Cursor and Claude Code can indeed compress hours of coding work into minutes. However, after this "honeymoon" period, a series of practical problems emerge, which I believe every friend who uses AI deeply can relate to:

The Side Effects of Being "Helpful": AI sometimes "takes matters into its own hands," modifying code you didn't ask it to touch and introducing unexpected bugs.

Lack of "Self-Awareness": The AI makes a mistake but is completely unaware of it, leading us into the awkward situation of "five minutes of coding, two hours of debugging."

The "Instruction Discount" Problem: When you ask the AI to generate a detailed 2000-word report, it might only deliver a draft of a few hundred words, with its understanding and execution of core requirements falling far short of expectations.

These "minor frictions" in daily use precisely validate my point: although current AI Agents are powerful, there is still a significant gap between them and a truly "usable" productivity tool in terms of reliability, controllability, and depth of task understanding.

So, how do we cross this chasm? Do we wait for the next, more powerful version of GPT, or do we build a more robust and adaptive framework from a systems engineering perspective?

Faced with these challenges, I have also been exploring over the past period. A common misconception is that we place all our hopes for a breakthrough on the next, more powerful foundational model (LLM). But this is like expecting a genius race car driver to set a world record in a mediocre car, ignoring the importance of the vehicle itself.

I believe the relationship between an AI Agent framework and a foundational large model is like that of a race car and its driver. The foundational model is the driver with incredible reflexes and decision-making abilities, while the AI Agent framework is the meticulously tuned race car with an advanced suspension and stable braking system. A great driver can push a car to its limits, while an excellent car allows the driver to race more confidently and stably on complex tracks, even compensating for the driver's occasional mistakes.

Therefore, rather than passively waiting for the "genius driver" to arrive, we should proactively build a more reliable and intelligent "race car." Based on this philosophy, I have constructed a complex AI Agent decision-making system. The complete program has been open-sourced on GitHub, and interested readers can find it here: https://github.com/answeryt/Neosgenesis. Its core design is precisely to provide the strongest support for the "driver" (LLM) and to confront and solve the three major challenges mentioned above. This article will deconstruct the architecture of this system and share how I, starting from engineering practice, built a self-learning, self-optimizing AI Agent system aimed at moving beyond the "demo spell" and toward "production usability."

Part 1: Confronting Fragility—How to Counter Exponential Error Accumulation?
Imagine an agent with a 99% success rate for a single step. After executing 100 consecutive steps, the total success rate drops to just 36.6%. This "success rate avalanche" is a challenge that all complex automation systems must face. A traditional linear agent workflow is like a fragile glass rod; a break in any single link causes the entire task to fail.

My solution is this: replace the fragile "glass rod" with a resilient "high-elasticity fiber bundle" through systemic redundancy and adaptive capabilities.

Solution 1: Verify Before Executing—Nipping Fragility in the Bud with "Thought Verification" (controller.py)
A major flaw of traditional agents is being a "giant in execution, but a dwarf in thought." They receive an instruction and immediately dive into the details of execution, rarely stopping to think, "Is my plan itself reliable?" If the initial direction is wrong, then no matter how perfectly each subsequent step is executed, it's just racing down the road to failure. This is the root cause of error accumulation.

To cut off this fragility at its source, my system introduces the core principle of "verify before executing." Before the agent invests any substantial execution cost, it must first subject its own "thoughts" to rigorous self-scrutiny.

The following code from controller.py shows the five-stage decision process, where verification happens before execution.

# In controller.py -> MainController
def make_decision(self, user_query: str, ...):
    """
    🚀 Five-stage intelligent verification-learning decision process
    """
    # ...

    # 🧠 Stage 1: A Priori Reasoning - Generate a thinking seed
    thinking_seed = self.prior_reasoner.get_thinking_seed(user_query, execution_context)

    # 🔍 Stage 2: Verify the thinking seed (New) - Quickly verify the high-level direction
    seed_verification_result = self.verify_idea_feasibility(
        idea_text=thinking_seed,
        context={'stage': 'thinking_seed', ...}
    )

    # ...

    # 🛤️ Stage 3: Path Generation - Generate a list of reasoning paths based on the (verified) seed
    all_reasoning_paths = self.path_generator.generate_paths(...)

    # 🚀 Stage 4: Path Verification and Learning - Verify paths one by one and learn instantly
    for i, path in enumerate(paths_to_verify, 1):
        path_verification_result = self.verify_idea_feasibility(
            idea_text=f"{path.path_type}: {path.description}",
            context={'stage': 'reasoning_path', ...}
        )

        # 💡 Instant Learning: Immediately feed the verification result back to the MAB system
        self.mab_converger.update_path_performance(
            path_id=path.strategy_id,
            success=(path_verification_result.get('feasibility_score', 0) > 0.3),
            reward=path_verification_result.get('reward_score', 0.0)
        )

    # 🎯 Stage 5: Intelligent Final Decision - Make a decision based on verification results
    # ...

This multi-layered verification mechanism ensures that every decision the agent makes is built on a more reliable, scrutinized foundation. It nips fragility in the bud by replacing expensive, high-risk "physical execution" with low-cost, front-loaded "thought experiments," thereby dramatically reducing the probability of the entire task chain failing due to a directional error.

Solution 2: From a Single Path to a Strategy Matrix (path_generator.py & mab_converger.py)
A traditional agent usually follows a fixed plan. If any step in that plan fails (e.g., a tool call), the entire task gets stuck. My system, however, believes that there's never just one way to solve a problem. Therefore, we've introduced a "multi-path reasoning" mechanism:

Generate Diverse Strategies: At the start of a task, the PathGenerator module steps in. It doesn't just create one plan; it generates multiple ReasoningPaths with different styles based on the nature of the task. For example, for a complex technical problem, it might generate:

A "Systematic Analysis" path: Emphasizes logical decomposition and step-by-step execution.

An "Innovative Breakthrough" path: Encourages out-of-the-box thinking and shortcuts.

A "Practical & Pragmatic" path: Prioritizes the simplest, most direct solution.

Select Based on Experience: After the paths are generated, the choice is handed over to the MABConverger (the learning core of our system, detailed later). It evaluates which type of path has the highest success rate and best performance for similar problems based on historical data, and then makes a selection.

Here are some of the path templates defined in path_generator.py.

# In path_generator.py -> ReasoningPathTemplates
@staticmethod
def get_all_templates() -> Dict[str, ReasoningPath]:
    """Get all predefined path templates"""
    return {
        # Systematic thinking
        "systematic_analytical": ReasoningPath(
            path_id="systematic_analytical_v1",
            path_type="Systematic Analysis",
            description="Systematically decompose and analyze problems...",
            ...
        ),
        # Innovative thinking
        "creative_innovative": ReasoningPath(
            path_id="creative_innovative_v1", 
            path_type="Innovative Breakthrough",
            description="Think outside the box to find innovations and breakthroughs...",
            ...
        ),
        # ... more templates
    }

And this is how the best path is selected in mab_converger.py.

# In mab_converger.py -> MABConverger
def select_best_path(self, paths: List[ReasoningPath], ...) -> ReasoningPath:
    """Select the optimal path from a list of reasoning paths"""
    # ...
    # Automatically select an algorithm (thompson_sampling, ucb_variant, etc.)
    algorithm = self._select_best_algorithm_for_paths()

    if algorithm == 'thompson_sampling':
        best_arm = self._thompson_sampling_for_paths(available_arms)
    # ...

    selected_path = strategy_to_path_mapping.get(best_arm.path_id)
    return selected_path

This design provides fault tolerance at the strategy level. If the agent chooses the "Systematic Analysis" path this time and fails, the MABConverger records this failure. When faced with a similar problem in the future, its decision weight might lean towards the "Practical & Pragmatic" path, thus automatically bypassing the previous point of failure. The system no longer follows a single track but dynamically seeks the optimal solution within a strategy matrix.

Solution 3: "A Light at the End of the Tunnel"—Intelligent Detour Thinking (controller.py)
Even with multiple alternative paths, it's possible to reach a dead end where all known paths are unworkable. At this point, a truly intelligent system shouldn't just spin its wheels or give up. For this, we designed an advanced fault-tolerance mechanism called "Aha-Moment" or "Intelligent Detour Thinking."

The controller.py module contains the logic for triggering this "Aha-Moment".

# In controller.py -> MainController
def _check_aha_moment_trigger(self, chosen_path) -> Tuple[bool, str]:
    """Check if an Aha-Moment decision (detour thinking) needs to be triggered"""
    # Trigger condition 1: Path confidence is too low
    path_confidence = self.mab_converger.get_path_confidence(chosen_path.strategy_id)
    if path_confidence < self.aha_moment_stats['confidence_threshold']:
        return True, f"Selected path confidence is too low ({path_confidence:.3f})"

    # Trigger condition 2: All paths are performing poorly
    if self.mab_converger.check_low_confidence_scenario(...):
        return True, "Confidence in all available paths is low"

    # Trigger condition 3: Too many consecutive failures
    if self.aha_moment_stats['consecutive_failures'] >= self.aha_moment_stats['failure_threshold']:
        return True, f"Consecutive failures: {self.aha_moment_stats['consecutive_failures']}"

    return False, "Normal decision path is performing as expected"

def _execute_aha_moment_thinking(self, ...):
    """Execute Aha-Moment detour thinking"""
    # Step 1: Generate creative detour paths
    creative_paths = self.path_generator.generate_paths(
        ...,
        mode='creative_bypass'  # Key: enter creative detour mode
    )
    # Step 2: Combine and re-select
    combined_paths = original_paths + creative_paths
    final_chosen_path = self.mab_converger.select_best_path(combined_paths)
    return final_chosen_path, combined_paths

This is essentially a meta-cognitive ability. The system can recognize, "It seems none of my current methods are working," and then proactively and strategically "brainstorm" instead of endlessly retrying on a failing path.

Part 2: Breaking the Cost Curse—Structured State and Information Compression
The second point directly addresses the core pain point of commercializing AI Agents: cost. As the task chain lengthens, simply concatenating all dialogue history and tool call results causes the context to expand dramatically, leading to quadratic growth in token costs.

Our strategy is to replace disordered, lengthy "running ledger" contexts with structured memory and front-end information compression.

Solution 1: Goodbye to "Running Ledgers," Hello to "Structured Memory" (state_manager.py)
One of the biggest problems with traditional agents is processing all context information as one giant, undifferentiated block of text. This is not only expensive but also inefficient. Our StateManager module changes this by upgrading the agent's memory from "text" to "objects."

The data structures in state_manager.py show this object-oriented approach.

# In state_manager.py
@dataclass
class ConversationTurn:
    """Data structure for a conversation turn"""
    turn_id: str
    timestamp: float
    user_input: str
    llm_response: str
    tool_calls: List[Dict[str, Any]] = field(default_factory=list)
    # ...

@dataclass
class UserGoal:
    """Data structure for a user goal"""
    goal_id: str
    original_query: str
    status: GoalStatus = GoalStatus.PENDING
    progress: float = 0.0
    # ...

@dataclass
class IntermediateResult:
    """Data structure for an intermediate result"""
    result_id: str
    source: str  # tool_name or "llm_analysis"
    content: Any
    relevance_score: float = 0.0
    # ...

class StateManager:
    def __init__(self, session_id: Optional[str] = None):
        self.conversation_history: List[ConversationTurn] = []
        self.user_goals: List[UserGoal] = []
        self.intermediate_results: List[IntermediateResult] = []
        # ...

By making the state "object-oriented" rather than "text-based," we fundamentally solve the problem of infinite context growth, paving the way for controlling token costs and achieving commercial viability.

Solution 2: Front-End Information Noise Reduction—RAG Thinking Seeds (rag_seed_generator.py)
Many tasks require an agent to retrieve information from the outside world. Our RAGSeedGenerator module adopts a strategy of "information preprocessing and compression." Before a task officially begins, it uses Retrieval-Augmented Generation (RAG) to produce a highly condensed "thinking seed."

This process is handled by the generate_rag_seed function in rag_seed_generator.py.

# In rag_seed_generator.py -> RAGSeedGenerator
def generate_rag_seed(self, user_query: str, ...) -> str:
    """Generate a RAG-based thinking seed - a three-stage core process"""
    # Stage 1: Understand the problem and devise a search strategy
    search_strategy = self._analyze_and_plan_search(user_query, ...)

    # Stage 2: Execute a web search
    search_results = self._execute_web_search(search_strategy)

    # Stage 3: Synthesize information and generate the seed
    synthesis_result = self._synthesize_information(
        user_query, search_strategy, search_results, ...
    )

    return synthesis_result.contextual_seed

This "thinking seed" acts as a custom "mission briefing" for the agent. Subsequent modules, like PathGenerator, work around this refined seed, avoiding the repeated processing of large amounts of raw information and further controlling context length and cost.

Part 3: The Soul of the System—Building a Feedback Loop that Learns and Reflects
The third point, and the most central challenge, lies in the design of tools and feedback systems. An agent that cannot learn from experience will forever remain a "toy." This is precisely the soul of my system's design.

Solution 1: The Core of Learning—The Empiricism of Multi-Armed Bandits (MAB) (mab_converger.py)
I introduced an empirical learning mechanism for the agent. Every "reasoning path" and every "tool" is treated as an EnhancedDecisionArm, recording its historical performance.

The EnhancedDecisionArm data structure from data_structures.py is key here.

# In data_structures.py
@dataclass
class EnhancedDecisionArm:
    """A decision arm - tracks the performance of a reasoning path"""
    path_id: str
    success_count: int = 0
    failure_count: int = 0
    total_reward: float = 0.0
    rl_reward_history: List[float] = field(default_factory=list)
    # ...

    def update_performance(self, success: bool, reward: float):
        if success:
            self.success_count += 1
        else:
            self.failure_count += 1
        self.total_reward += reward
        self.rl_reward_history.append(reward)
        # ...

The MABConverger in mab_converger.py uses this data to update its knowledge.

# In mab_converger.py -> MABConverger
def update_path_performance(self, path_id: str, success: bool, reward: float = 0.0):
    """Update the performance feedback for a path or tool"""
    if path_id in self.path_arms:
        target_arm = self.path_arms[path_id]
        target_arm.update_performance(success, reward)
        # ...

This MAB system is the concrete engineering implementation of the "feedback system" I mentioned. It turns every action the agent takes into a learning opportunity. Good strategies and tools are reinforced, while poor ones are gradually phased out, allowing the system to achieve continuous self-optimization.

Solution 2: Beyond "Success/Failure," Pursuing "Effectiveness"—High-Quality Feedback from an LLM Referee (controller.py)
Simply providing feedback of "success" or "failure" is not enough. To solve this, I introduced an innovative mechanism: the "LLM Referee."

This is implemented in the _calculate_tool_reward method in controller.py.

# In controller.py -> MainController
def _calculate_tool_reward(self, tool_result: Any, original_prompt: str) -> float:
    """🏆 LLM Referee reward calculation system"""
    # Prioritize the LLM referee system
    llm_reward = self._llm_judge_tool_effectiveness(tool_result, original_prompt)
    if llm_reward is not None:
        logger.info(f"🏆 LLM Referee reward: {llm_reward:.3f}")
        return llm_reward
    # ... fallback to traditional calculation

def _llm_judge_tool_effectiveness(self, tool_result: Any, original_prompt: str) -> Optional[float]:
    """🧠 LLM Referee: Assess how helpful the tool's result is for solving the problem"""
    judge_prompt = f"""
You are an expert AI tool effectiveness evaluator.
Original user problem: {original_prompt}
Tool execution result: {tool_result}
Evaluation task: Please assess how helpful the tool result is for solving the user's original problem and provide a numerical score from -1.0 to 1.0.
Score:"""

    llm_response = self._call_llm_for_parameters(judge_prompt)
    score = self._parse_llm_judgment_score(llm_response)
    return score

This provides an extremely high-quality, contextually relevant feedback signal. The MAB learns not just "Will this API crash?" but a deeper, utility-focused knowledge: "For solving this type of problem, how useful is this tool?"

Solution 3: The System's "Self-Awareness"—Cold Start Detection and Decision Mode Switching (mab_converger.py & controller.py)
MAB relies on historical data, so how does it make a decision when faced with a brand-new tool or strategy (the "cold start" problem)? I solved this by giving the system a form of "self-awareness."

The is_tool_cold method in mab_converger.py allows the system to check its own experience.

# In mab_converger.py -> MABConverger
def is_tool_cold(self, tool_name: str) -> Dict[str, any]:
    """🔍 Determine if a tool is in a cold start state"""
    tool_arm = self.tool_arms.get(tool_name)
    if not tool_arm or tool_arm.activation_count < cold_start_config["min_usage_count"]:
        # ...
        return {'is_cold_start': True, ...}
    # ...
    return {'is_cold_start': False, ...}

Then, the MainController uses this information to switch between experience-driven and exploration-driven modes.

# In controller.py -> MainController
def _mab_decide_action(self, ..., available_tools: List[str]) -> Optional[str]:
    """🌟 Step 3: Hybrid Decision Core - MAB experience + LLM intelligent exploration"""
    # ...
    # Stage 2: MAB's initial recommendation
    mab_recommendation = self.mab_converger.select_best_tool(real_tools)

    # Stage 3: Check experience level
    cold_analysis = self.mab_converger.is_tool_cold(mab_recommendation)

    # Stage 4: Intelligent mode switching
    if cold_analysis['is_cold_start']:
        # 🧠 Insufficient tool experience → Switch to LLM exploration mode
        logger.info("🧠 Switching to exploration mode (LLM-led decision)")
        return self._llm_explore_tool_selection(...)
    else:
        # 📊 Rich tool experience → Trust MAB's recommendation, use experience mode
        logger.info("📊 Using experience mode (MAB-led decision)")
        return mab_recommendation

This is a very elegant "exploitation vs. exploration" balancing strategy. It perfectly combines the decision-making efficiency of MAB when there is sufficient data with the generalization ability of LLM when facing new situations. The system can thus safely and efficiently learn and adopt new tools and strategies, solving the core problem of agent capability expansion.

Conclusion: Beyond Prompt Engineering, a Return to Systems Thinking
Looking back at the three challenges I outlined, we find that the root of all problems points in a common direction: building a truly usable AI Agent is far more than just writing clever prompts (Prompt Engineering); it is a complex and serious systems engineering endeavor.

The system I've built is a practical application of this philosophy. By introducing redundancy and adaptability to combat fragility, using structured state management to control costs, and most importantly, by building a feedback learning loop based on MAB and an LLM referee, we give the agent three valuable abilities:

1.Learning from Experience

2.Recovery from Failure

3.Exploration under Uncertainty

This is perhaps the key for AI Agents to move beyond the "demo spell," evolving from "cool-looking" toys into "digital employees" that can create real value in a production environment. The road ahead is still long, but I believe that returning to a systems engineering mindset and building frameworks that can self-learn and reflect is the right path to that future. Of course, the current system is in development and still faces many difficulties and challenges to be solved. If you have great ideas and opinions, please point them out. Thank you very much for your valuable feedback, I will continue to improve!