OpenSage: Self-Programming Agent Kit

Updated 4 July 2026

OpenSage is a self-programming agent development kit enabling LLMs to dynamically generate agent topology, toolsets, and hierarchical memory structures for adaptive automation.
It integrates unified APIs for creating, managing, and orchestrating sub-agents and domain-specific tools to streamline complex AI workflows.
The framework employs a hierarchical graph-based memory to optimize short-term and long-term context management, enhancing reasoning and benchmark performance.

OpenSage most specifically denotes an agent development kit that enables LLMs to automatically create agents with self-generated topology and toolsets while providing comprehensive and structured memory support. In "OpenSage: Self-programming Agent Generation Engine" (Li et al., 18 Feb 2026), it is presented as the first AI-centered ADK that lets LLMs self-program agent topology, toolsets, and memory, with effective functionality for agents to create and manage their own sub-agents and toolkits, a hierarchical, graph-based memory system for efficient management, and a specialized toolkit tailored to software engineering tasks.

1. Motivation and conceptual framing

Agent Development Kits (ADKs) like Google ADK, OpenAI Agents SDK, Claude ADK, OpenHands SDK, LangChain, etc., provide primitives for building LLM-based agents but leave three critical components—agent topology, tool design, and memory management—to manual, expert engineering (Li et al., 18 Feb 2026). The same source states that manually specifying sub-agent structure and toolsets for each new task is time-consuming, error-prone, and does not adapt when the agent enters new domains, while static memory or no memory forces agents to reexplore or drop context, limiting long-horizon reasoning.

OpenSage is positioned as a parallel shift to the transition from handcrafted features to end-to-end learning in machine learning. The formulation used in the paper is a shift for agent construction from human-driven design, described as “human-centered,” to AI-driven self-programming, described as “AI-centered” (Li et al., 18 Feb 2026). In that framing, the central design claim is not merely that an LLM can call tools, but that it can generate and manage its own topology, toolsets, and memory structures.

A common misconception is to reduce OpenSage to a tool wrapper or a memory layer. The architecture described in the paper is explicitly tripartite: self-generating agent topology, dynamic tool synthesis and management, and hierarchical graph-based memory. This suggests that the intended unit of automation is the agent construction process itself, rather than only inference-time orchestration.

2. Runtime architecture and control surfaces

OpenSage is organized around three interlocking subsystems: self-generating agent topology, dynamic tool synthesis and management, and hierarchical graph-based memory (Li et al., 18 Feb 2026). At runtime, a “parent” agent can invoke a set of APIs exposed as LLM-callable tools. These include:

create_agent(…) to spawn a new sub-agent object and register it in a global pool
list_active_agents() to enumerate available sub-agents
call_agent(name, task_message) to run a particular sub-agent on a new prompt
list_tools(), run_tool(name, args), and register_tool(…) to discover, invoke, or add tools
memory_agent.search_memory(…), memory_agent.save_memory(…), and memory_agent.update_memory(…)

The create_agent interface takes as input a JSON-style agent configuration with fields agent_name, role (system prompt), model_name, tool list (by name or path), description, and initial memory summary (Li et al., 18 Feb 2026). Internally, OpenSage parses this into a Python AgentRun object and stores it in a global “sub-agent pool.” The call_agent API clones the AgentRun instance, appends the new user message, and runs the LLM to produce a response; when the sub-agent finishes, its clone is discarded. list_active_agents allows the parent to check for reuse before spawning new agents.

The architecture also exposes agent ensemble as a first-class operation through ensemble_agents(task, [agent1, agent2,…]), which clones and runs multiple sub-agents in parallel, then aggregates or summarizes their outputs back to the parent (Li et al., 18 Feb 2026). This makes horizontal composition part of the ADK surface rather than an external orchestration pattern.

3. Self-generated topology and dynamic tool synthesis

OpenSage defines three topology patterns. Vertical Decomposition allows a parent to delegate distinct sub-tasks, such as code exploration, PoC generation, and debugging, to specialized sub-agents. Horizontal Ensemble allows multiple sub-agents to attempt the same sub-task with different plans or prompts, after which their results are merged. Dynamic Model Collaboration allows a powerful LLM to orchestrate weaker LLMs by creating sub-agents assigned to execution-heavy steps, yielding cost-effective pipelines (Li et al., 18 Feb 2026).

The tool subsystem is organized as a filesystem hierarchy in which directories represent tool categories and modules, such as Python scripts and Bash files, represent individual tools, each accompanied by metadata including description, interface signature, and dependency list (Li et al., 18 Feb 2026). Meta-tools allow an LLM to write new tools: the agent emits source code plus metadata, and OpenSage validates and registers them instantly under the correct directory.

Containerized sandboxing is an explicit part of the execution model. Each tool module carries metadata on its required environment, such as Python version, C compiler, and library dependencies. OpenSage automatically provisions an isolated Docker container for each tool set, mounts a shared workspace, and caches image layers after first use to speed up subsequent invocations (Li et al., 18 Feb 2026). Long-running tools can also be offloaded asynchronously: run_tool returns a handle, denoted in the description as corresponding to a process ID, which the agent can poll for status or use to retrieve results later.

This combination of topology synthesis and tool synthesis is central to the “self-programming” characterization. The paper’s ablations indicate that replacing all tools with a raw bash interface produces a large performance drop versus full OpenSage, and disabling all OpenSage features yields a further drop under raw BCHL conditions (Li et al., 18 Feb 2026). A plausible implication is that the framework treats tool creation and agent decomposition as coupled capabilities rather than independent add-ons.

4. Hierarchical graph-based memory

OpenSage distinguishes two memory tiers, short-term and long-term, and represents both as labeled directed graphs (Li et al., 18 Feb 2026). The formal definition is given as follows. Let $G = (V, E)$ be a directed graph. For short-term memory, $V = \{\text{AgentRun nodes}\} \cup \{\text{Event nodes}\} \cup \{\text{RawToolResponse nodes}\}$ . For long-term memory, $V = \{\text{entity nodes (code elements, questions, concepts)}\}$ . The edge set $E \subseteq V \times V$ is typed. Short-term memory includes “creates” edges from AgentRun to Event, “parent_of” edges between AgentRun nodes when sub-agents spawn, and “refers_to” edges from Event to RawToolResponse. For long-term memory, edges capture relations such as “defines,” “calls,” “imports,” and “depends_on.” Each node $u \in V$ carries attributes label(u), content(u), and embedding(u) for retrieval (Li et al., 18 Feb 2026).

In the short-term memory graph, a parent AgentRun node spawns Event nodes for each tool call and LLM response. When create_agent is called, a new AgentRun child is linked by a parent_of edge. RawToolResponse nodes store full outputs, while Event nodes hold summaries referencing them. When $|context|$ grows beyond a threshold, a summarization tool collapses older Event subgraphs into summary nodes to preserve salient information and keep query latency low (Li et al., 18 Feb 2026).

Long-term memory is managed by a dedicated Neo4j instance. Entities are stored with types such as “function,” “file,” “search_result,” and “error,” together with embeddings of their labels. Two retrieval primitives are defined. The first is graph-pattern lookup, exemplified as listing nodes of type “error” whose label matches /.*ModuleNotFoundError.*/. The second is embedding-based search: given a query $q$ , compute $e = \mathrm{Embed}(q)$ and return the top- $k$ nodes by $\mathrm{cosine\_similarity}(e, \mathrm{embedding}(v))$ , together with their one-hop subgraph (Li et al., 18 Feb 2026).

The memory agent exposes three LLM-callable tools: save_memory(node_type, label, content), search_memory(query_label), and update_memory(…) (Li et al., 18 Feb 2026). On save_memory, the memory agent embeds the label and issues a CREATE node or CREATE edge command to Neo4j. On search_memory, it decides short versus long term; for long term, it issues either a similarity search or a pattern match and formats results into a natural-language summary. The paper characterizes memory reads and writes as fully delegated to an LLM-driven agent that enforces consistency, deduplication, and relevance.

5. Software-engineering toolchain and empirical evaluation

OpenSage ships with a domain-specific tool suite for coding and security (Li et al., 18 Feb 2026). The static-analysis components are Joern, for Code Property Graph queries, and CodeQL, for call-graph and dataflow slicing. The dynamic-analysis components are AFL++ and LibFuzzer for coverage-guided fuzzing with custom seeds and mutation, and llvm-cov for coverage measurement with HTML and JSON reports. The debugger layer includes GDB for C/C++ and PDB for Python, with breakpoints, step execution, memory inspection, and custom helper commands. All tools run in sandboxed containers, share a workspace volume, and support asynchronous calls. Agents may invoke, combine, or write new tools via the same register_tool API.

The reported evaluation spans CyberGym, Terminal-Bench 2.0, SWE-Bench Pro, and LOCOMO (Li et al., 18 Feb 2026). The benchmark definitions and metrics are part of the system’s characterization: CyberGym contains 1,507 real-world C/C++ vulnerabilities and uses PoC-reproduction success rate, denoted “% Resolved”; Terminal-Bench 2.0 contains 89 expert-curated high-skill terminal tasks and uses average pass@1 over 5 trials under CPU/time constraints; SWE-Bench Pro contains 266 Python GitHub issues and uses the percentage of issues automatically resolved; LOCOMO contains 10 long dialogues with approximately 200 QA each and uses LLM judge accuracy on single-hop, multi-hop, open-domain, and temporal questions.

Benchmark	Metric	Reported summary
CyberGym	PoC-reproduction success rate (“% Resolved”)	SageAgent (GPT-5 medium) resolves 60.2% vs. 50.6% (Claude ADK) and 39.4% (OpenHands)
Terminal-Bench 2.0	Average pass@1 over 5 trials	SageAgent (Gemini 3 Pro) achieves 65.2% ± 2.0 vs. 64.7% ± 2.7 (Ante) and 62.9% ± 3.0 (OpenAI ADK)
SWE-Bench Pro	% issues automatically resolved	SageAgent (Gemini 3 Flash) attains 59.0% vs. 40.2% (SWE-agent) and 9.4% (no-agent baseline)
LOCOMO	LLM judge accuracy	OpenSage memory roughly matches Mem0ᵍ on open-domain (76.4% vs. 75.7%) and temporal (57.8% vs. 58.1%) while outperforming non-memory baselines

The results section is paired with ablations that attribute performance to specific subsystems. On a CyberGym subset of 300 instances, disabling horizontal ensemble reduces resolution by 15% on tasks where ensemble was triggered. Disabling dynamic sub-agent creation causes resolution to drop sharply and increases summarization events per task from 6.4 to 13.1 on average. On SWE-Bench Pro, NoMem yields the lowest resolved rate, Mem0ᵍ gives only marginal improvement over NoMem, and full OpenSage memory reaches the highest resolved rate, 59.0%, which the paper uses to argue for AI-created memory schemas and an LLM-driven memory agent (Li et al., 18 Feb 2026).

6. Contributions, limitations, and stated future directions

The primary contributions are enumerated explicitly in the paper: first AI-centered ADK that lets LLMs self-program agent topology, toolsets, and memory; unified APIs for dynamic sub-agent creation, ensemble, and lifecycle management; hierarchical graph memory with formal short-term and long-term tiers driven by a specialized memory agent; domain-optimized toolchain with static analysis, fuzzing, debuggers, container sandboxing, and asynchronous execution; and extensive empirical validation on three state-of-the-art benchmarks plus a conversational memory dataset (Li et al., 18 Feb 2026).

The paper’s emphasis on topology, tooling, and memory as coequal design axes clarifies the scope of the system. OpenSage is not restricted to pre-authored workflows, nor is it defined only by a fixed set of domain tools. Instead, the agent can create and manage sub-agents, synthesize tools, and decide how memory should be read or written through an LLM-driven memory agent. This suggests a design objective of self-scaffolding rather than fixed orchestration.

Future directions are also stated concretely. These include AI-generated workflows that allow LLMs to autonomously decide sub-agent dependencies and communication protocols in complex pipelines; end-to-end training support through integration with RLHF and large-scale rollout frameworks such as AReaL and HybridFlow on Kubernetes backends for continuous learning; and adaptive memory schemas that enable on-the-fly refinement of node and edge types based on agent experience across domains (Li et al., 18 Feb 2026). A plausible implication is that the current release emphasizes runtime self-programming, while later extensions may target continual adaptation and training-time optimization.

The label “OpenSage” is not unique across arXiv-adjacent technical discourse. In the present context, its most specific and direct referent is the self-programming ADK introduced in 2026 (Li et al., 18 Feb 2026). However, the same or closely related naming appears in other domains, and distinguishing these systems avoids category errors.

arXiv id	System	Scope
(Li et al., 18 Feb 2026)	"OpenSage: Self-programming Agent Generation Engine"	AI-centered ADK with self-generated topology, toolsets, and memory
(Tong et al., 31 Jan 2026)	"SAGE: Accelerating Vision-LLMs via Entropy-Guided Adaptive Speculative Decoding"	Entropy-guided adaptive speculative decoding for VLMs
(Strehlow et al., 12 Jan 2026)	"SAGE: Tool-Augmented LLM Task Solving Strategies in Scalable Multi-Agent Environments"	OPACA-based conversational AI interface; described as an open-source rebranding to OpenSage in the provided technical overview
(Croton et al., 2016)	"Semi-Analytic Galaxy Evolution (SAGE): Model Calibration and Basic Results"	Semi-analytic galaxy evolution model; the provided technical overview also describes an OpenSage codebase

The entropy-guided speculative-decoding work uses SAGE to denote a framework that dynamically adjusts the speculation tree structure based on real-time prediction uncertainty and reports up to $V = \{\text{AgentRun nodes}\} \cup \{\text{Event nodes}\} \cup \{\text{RawToolResponse nodes}\}$ 0 decoding speedup for LLaVA-OneVision-72B and $V = \{\text{AgentRun nodes}\} \cup \{\text{Event nodes}\} \cup \{\text{RawToolResponse nodes}\}$ 1 for Qwen2.5-VL-72B without loss in output quality (Tong et al., 31 Jan 2026). The OPACA-based system implements four prompting methods—Simple, Simple-Tools, Tool-Chain, and Orchestration—and is described in the supplied technical overview as an open-source rebranding to OpenSage (Strehlow et al., 12 Jan 2026). The galaxy-formation SAGE work is a publicly available codebase for modelling galaxy formation in a cosmological context, with modular C++ science modules and calibration on Millennium, Bolshoi, and GiggleZ (Croton et al., 2016).

This naming overlap can obscure the identity of the self-programming ADK. In current agent-systems usage, “OpenSage” most precisely refers to the framework in which LLMs automatically create agents with self-generated topology and toolsets while operating over hierarchical graph-based memory (Li et al., 18 Feb 2026).