\documentclass[twocolumn,11pt]{article}

% Page geometry (NeurIPS-like)
\usepackage[letterpaper,top=1in,bottom=1in,left=0.75in,right=0.75in]{geometry}

% Standard packages
\usepackage{amsmath,amssymb}
\usepackage{booktabs}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{listings}

\hypersetup{colorlinks=true, linkcolor=blue!70!black, citecolor=blue!70!black, urlcolor=blue!70!black}

% Tighter spacing
\setlength{\parskip}{2pt plus 1pt}
\setlength{\abovecaptionskip}{6pt}
\setlength{\belowcaptionskip}{2pt}
\setlength{\textfloatsep}{8pt plus 2pt minus 2pt}
\setlength{\floatsep}{6pt plus 2pt minus 2pt}

\lstset{
  basicstyle=\small\ttfamily,
  keywordstyle=\color{blue!80!black},
  commentstyle=\color{gray},
  stringstyle=\color{red!70!black},
  breaklines=true,
  frame=single,
  backgroundcolor=\color{gray!5},
  language=Python,
  aboveskip=6pt,
  belowskip=6pt,
  xleftmargin=4pt,
  xrightmargin=4pt,
}

% NeurIPS-style title formatting
\makeatletter
\renewcommand{\maketitle}{%
  \twocolumn[%
    \begin{center}
      {\LARGE\bfseries \@title \par}
      \vskip 0.5em
      {\large \@author \par}
      \vskip 1.5em
    \end{center}
  ]%
}
\makeatother

\title{ARISE: Adaptive Runtime Improvement through Self-Evolution}
\author{%
  Alibek Kaliyev \\
  \texttt{github.com/abekek/arise}
}
\date{}

\begin{document}
\maketitle

\begin{abstract}
\noindent We present ARISE, a middleware that enables LLM agents to autonomously create, test, and promote their own tools at runtime.
When an agent encounters tasks it cannot solve, ARISE detects the capability gap, synthesizes a Python tool via LLM, validates it through sandbox and adversarial testing, and promotes it to the active library.
We evaluate ARISE on a benchmark where an SRE agent must operate proprietary systems with custom formats absent from LLM training data.
Our results reveal a nuanced picture: ARISE improves success on tool-essential tasks (Metrics API: $7\% \rightarrow 29\%$ with GPT-4o-mini, $13\% \rightarrow 73\%$ with Claude Sonnet) but can \emph{reduce} overall performance for weaker models due to tool-use overhead ($44 \pm 4\%$ vs $48 \pm 2\%$ no-evolution baseline for GPT-4o-mini across 3 seeds).
With a stronger model, ARISE is consistently beneficial: Claude Sonnet achieves $78\%$ overall ($+15$~pp over no-evolution) using only 2 self-evolved tools.
These results suggest that self-evolution amplifies model capability rather than replacing it, and that agent reasoning quality matters more than tool quantity.
ARISE is open-source at \texttt{pip install arise-ai}.
\end{abstract}

%-----------------------------------------------------------------------
\section{Introduction}
%-----------------------------------------------------------------------

Building an LLM agent is straightforward. Maintaining its tool library is the bottleneck. Every time an agent encounters a task requiring a capability it lacks, a human engineer must notice the failure, understand what tool is missing, implement it, test it, and deploy it. This feedback loop works when the environment is well-defined, but breaks down in three increasingly common scenarios:

\textbf{Multi-tenant platforms.} An agent serving many customers encounters different internal systems, APIs, and data formats. Pre-building tools for every customer's stack is impractical.

\textbf{Long-running autonomous agents.} Operations agents, monitoring systems, and data pipeline agents encounter novel situations at unpredictable times---often without a human available to write a quick fix.

\textbf{The long tail of edge cases.} An agent fails on dozens of different edge cases. Each individual failure is not worth an engineer's afternoon, but collectively they represent a significant capability gap.

ARISE addresses these scenarios by automating the tool engineering feedback loop. Rather than requiring human intervention, ARISE observes the agent's failures, identifies missing capabilities, synthesizes candidate tools, validates them through automated testing, and promotes passing tools to the agent's active library---all at runtime. Figure~\ref{fig:architecture} illustrates the high-level architecture.

\begin{figure*}[t]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/architecture.png}
    \caption{\textbf{ARISE architecture overview.} The agent executes tasks using its current tool library. Failed trajectories are analyzed by the evolution worker, which synthesizes candidate tools, validates them through sandbox and adversarial testing, and promotes passing tools back to the active library. The cycle repeats autonomously.}
    \label{fig:architecture}
\end{figure*}

\subsection{Contributions}

\begin{enumerate}
    \item A \textbf{framework-agnostic self-evolution pipeline} that works with any LLM agent by wrapping the agent function and tool library, requiring no modifications to the agent's architecture.
    \item A \textbf{multi-layer safety model} for generated code: sandbox isolation, automated test generation, adversarial validation, import restrictions, and version-controlled rollback.
    \item A \textbf{distributed architecture} decoupling the stateless agent process from the evolution worker via S3/SQS, validated through a live deployment on Amazon Bedrock AgentCore.
    \item An \textbf{empirical evaluation} on a realistic SRE onboarding benchmark with proprietary formats across multiple random seeds and two domains.
\end{enumerate}

%-----------------------------------------------------------------------
\section{Related Work}
%-----------------------------------------------------------------------

\textbf{LLMs as Tool Makers (LATM)}~\cite{cai2023latm} demonstrated that LLMs can create reusable tools---a ``tool maker'' model generates Python functions that a cheaper ``tool user'' model invokes. ARISE extends this with automated testing, adversarial validation, versioning, and a feedback loop driven by real agent failures rather than predefined tasks.

\textbf{VOYAGER}~\cite{wang2023voyager} demonstrated an open-ended agent in Minecraft that builds a skill library through exploration. ARISE applies the same skill library pattern to real-world software agents, adding safety validation that game environments do not require.

\textbf{CREATOR}~\cite{qian2023creator} proposed disentangling abstract reasoning from concrete tool creation. ARISE operationalizes this with trajectory analysis to automatically detect when creation should trigger.

\textbf{CRAFT}~\cite{yuan2023craft} introduced a framework where agents create and retrieve tools from a shared library. ARISE adds the production engineering layer: sandboxed testing, adversarial validation, version control, and distributed deployment.

\textbf{Toolformer}~\cite{schick2023toolformer} showed LLMs can learn \emph{when} to use tools through self-supervised training. ARISE complements this by addressing \emph{which} tools should exist---creating them at runtime rather than assuming a fixed toolset.

\textbf{ADAS}~\cite{hu2024adas} automates the design of entire agentic systems via meta-search. ARISE operates at a different granularity: rather than redesigning the agent, it evolves the agent's tool library while keeping the agent architecture fixed.

\textbf{Tool-use benchmarks and retrieval.} ToolBench~\cite{qin2023toolllm} and API-Bank~\cite{li2023apibank} evaluate tool selection and invocation from fixed toolsets. Gorilla~\cite{patil2023gorilla} retrieves API documentation for tool use. These assume tools already exist; ARISE addresses the orthogonal problem of creating tools that don't yet exist. The ReAct paradigm~\cite{yao2022react} provides the reasoning-acting foundation that ARISE builds upon. Self-Instruct~\cite{wang2022selfinstruct} demonstrated self-improvement through generated data; ARISE applies a similar principle to tool creation. MetaGPT~\cite{hong2023metagpt} explores multi-agent collaboration including tool creation, but focuses on software engineering rather than runtime tool evolution.

Unlike prior work, ARISE is (1)~compatible with any agent that accepts callable tools (currently with a first-class Strands adapter), (2)~production-oriented with multi-layer safety validation and distributed deployment support, and (3)~publicly available as an installable package.

%-----------------------------------------------------------------------
\section{System Design}
%-----------------------------------------------------------------------

\subsection{Architecture Overview}

ARISE operates as middleware between the agent and its tool library. The system requires only two integration points: (1)~wrapping the agent's execution function, and (2)~providing a reward function. Listing~\ref{lst:usage} shows the minimal setup.

\begin{figure}[t]
\footnotesize
\begin{verbatim}
from arise import ARISE, ARISEConfig
from arise.rewards.builtin import task_success
from strands import Agent
from strands.models import BedrockModel

agent = Agent(
  model=BedrockModel(model_id="..."),
  system_prompt="Use tools when available.",
)

arise = ARISE(
  agent=agent,
  reward_fn=task_success,
  config=ARISEConfig(
    model="gpt-4o-mini",
    failure_threshold=5,
  ),
)

result = arise.run(
  "Compute SHA-256 of 'hello'",
  expected="2cf24dba5fb0a30e...",
)
\end{verbatim}
\vspace{-4pt}
\caption{Minimal ARISE integration.}
\label{lst:usage}
\end{figure}

The core evolution loop is formalized in Algorithm~\ref{alg:evolution}.

The evolution loop proceeds as follows: for each task, the agent executes with its current tools and receives a reward $r(\tau) \in [0,1]$. When failures ($r < 0.5$) accumulate past threshold $N$, ARISE (1)~analyzes failure trajectories to identify gaps, (2)~synthesizes candidate tools via LLM, (3)~validates each in a sandbox with adversarial tests, and (4)~promotes passing tools to the active library $\mathcal{L}$. The cycle then resets.

\subsection{Safety Model}

Generated code is not trusted by default. ARISE applies multiple validation layers:

\textbf{Sandbox execution.} Tools run in isolated subprocesses (or Docker containers) with configurable timeouts and resource limits. The sandbox captures stdout, stderr, and exit codes.

\textbf{Adversarial validation.} A separate LLM call generates edge-case tests targeting boundary conditions, type errors, empty inputs, and security issues. This catches bugs that the tool author's own tests miss.

\textbf{Import restrictions.} Static analysis (AST-based) blocks unauthorized module imports, including dynamic imports via \texttt{\_\_import\_\_()}, \texttt{importlib}, and \texttt{exec/eval}.

\textbf{Version control.} Every library mutation is checkpointed in SQLite. Rollback to any previous version is supported, enabling safe experimentation.

\subsection{Distributed Deployment}

For stateless environments (Lambda, ECS, AgentCore), ARISE decouples into a \textbf{stateless agent process} that reads tools from S3 (with TTL cache) and reports trajectories to SQS, and a \textbf{background worker} that consumes trajectories and runs evolution. The S3 skill store uses ETag-based optimistic locking for manifest updates.

%-----------------------------------------------------------------------
\section{Evaluation}
%-----------------------------------------------------------------------

\subsection{Benchmark Design: SRE Agent Onboarding}

We designed a benchmark simulating an SRE agent onboarding at ``AcmeCorp''---a fictional company with three proprietary systems absent from LLM training data:

\textbf{Custom log format:}
\begin{quote}
\small\verb|[ACME:sev:svc:ts] msg | ctx={json}|
\end{quote}
\vspace{-6pt}
A structured format requiring custom parsing.

\textbf{Metrics API:} HTTP endpoint returning base64-encoded payloads in a proprietary format:
\begin{quote}
\small\verb|ACME_METRICS|service|timestamp|json|
\end{quote}
\vspace{-6pt}

\textbf{AcmeConf:} Custom configuration syntax with \verb|@include| directives, variable interpolation (\verb|${VAR:-default}|), and duration literals.

The benchmark consists of 60 tasks across 4 phases of escalating difficulty (Table~\ref{tab:phases}). All tasks use deterministic check functions against pre-computed ground truth---no LLM judging. The agent receives a seed \texttt{http\_get} tool for HTTP access; all other tools must be evolved.

\begin{table}[t]
    \centering
    \caption{Benchmark phases and task domains.}
    \label{tab:phases}
    \small
    \begin{tabular}{clcl}
        \toprule
        Phase & Domain & Tasks & Capability required \\
        \midrule
        1 & Log Analysis & 15 & Parse, filter, aggregate \\
        2 & Metrics API & 15 & HTTP + decode format \\
        3 & Config Mgmt & 15 & Parse, validate, diff \\
        4 & Incident & 15 & Compose all domains \\
        \bottomrule
    \end{tabular}
\end{table}

\subsection{Experimental Setup}

We evaluate three conditions:

\textbf{ARISE:} Agent starts with a seed \texttt{http\_get} tool. Evolution enabled with \texttt{failure\_threshold=5}.

\textbf{No-evolution:} Agent receives no tools. Pure LLM reasoning over inline data.

\textbf{Fixed-tools:} Agent receives 7 hand-written tools from episode 1 (the ``engineer built everything'' ceiling).

We use GPT-4o-mini as the agent and synthesis model across 3 random seeds (42, 123, 456), and Claude Sonnet 4.5 as the agent model with a single seed for comparison.

\subsection{Main Results}

Table~\ref{tab:multiseed} presents multi-seed results for GPT-4o-mini, and Table~\ref{tab:claude} shows Claude Sonnet results.

\begin{table}[t]
    \centering
    \caption{GPT-4o-mini results (mean $\pm$ std, seeds 42/123/456). Bold indicates best per-phase.}
    \label{tab:multiseed}
    \small
    \begin{tabular}{@{}lcccc@{}}
        \toprule
        Condition & Ph.~1 & Ph.~2 & Ph.~3 & Ph.~4 \\
        \midrule
        ARISE & $18{\pm}8$ & $\mathbf{29{\pm}10}$ & $95{\pm}4$ & $33{\pm}0$ \\
        No-evolution & $\mathbf{29{\pm}8}$ & $7{\pm}0$ & $\mathbf{98{\pm}4}$ & $\mathbf{60{\pm}0}$ \\
        Fixed$^\dagger$ & $13$ & $53$ & $87$ & $40$ \\
        \bottomrule
    \end{tabular}
    \vspace{4pt}

    \small
    \begin{tabular}{@{}lcc@{}}
        \toprule
        Condition & Overall & Tools evolved \\
        \midrule
        ARISE & $44 \pm 4$ & $10 \pm 2$ \\
        No-evolution & $\mathbf{48 \pm 2}$ & 0 \\
        Fixed$^\dagger$ & $48$ & 7 (hand-written) \\
        \bottomrule
    \end{tabular}

    \vspace{2pt}
    \raggedright\scriptsize $^\dagger$Single seed (42); multi-seed not run.
\end{table}

\begin{table}[t]
    \centering
    \caption{Claude Sonnet 4.5 results (single seed 42; multi-seed confirmation needed).}
    \label{tab:claude}
    \small
    \begin{tabular}{@{}lccccc@{}}
        \toprule
        Condition & Ph.~1 & Ph.~2 & Ph.~3 & Ph.~4 & Overall \\
        \midrule
        ARISE (2 tools) & 60 & \textbf{73} & \textbf{100} & \textbf{80} & \textbf{78} \\
        No-evolution & 60 & 13 & 100 & 80 & 63 \\
        \bottomrule
    \end{tabular}
\end{table}

\begin{figure}[t]
    \centering
    \includegraphics[width=\columnwidth]{figures/phase_breakdown.png}
    \caption{\textbf{Phase-level results} with error bars showing mean $\pm$ std over 3 seeds for GPT-4o-mini conditions. Claude results from single seed. ARISE provides the largest gain on Phase~2 (Metrics API) where tool access is essential.}
    \label{fig:phase_breakdown}
\end{figure}

\begin{figure}[t]
    \centering
    \includegraphics[width=\columnwidth]{figures/phase2_delta.png}
    \caption{\textbf{Phase 2 (Metrics API)} --- the key finding. Without tools, the agent scores $7\%$ (cannot call APIs). ARISE evolves an HTTP decoder, improving to $29\%$ (GPT-4o-mini) and $73\%$ (Claude Sonnet).}
    \label{fig:phase2_delta}
\end{figure}

\begin{figure}[t]
    \centering
    \includegraphics[width=\columnwidth]{figures/tools_vs_performance.png}
    \caption{\textbf{Agent quality $>$ tool quantity.} Each point is one benchmark run. Claude with 2 tools outperforms GPT-4o-mini with 8--12 tools. More tools do not compensate for weaker reasoning.}
    \label{fig:tools_vs_perf}
\end{figure}

%-----------------------------------------------------------------------
\subsection{Analysis of Key Findings}
%-----------------------------------------------------------------------

\subsubsection{Finding 1: ARISE helps most where tools are essential}

Phase 2 (Metrics API) requires real HTTP calls and proprietary format decoding---tasks that are impossible without tools. ARISE produces the largest and most consistent gains here: $7\% \rightarrow 29\%$ for GPT-4o-mini ($+22$~pp) and $13\% \rightarrow 73\%$ for Claude Sonnet ($+60$~pp). Phase~3 (Config), where inline reasoning suffices, shows no improvement.

\subsubsection{Finding 2: Tool-use overhead hurts weaker models}

For GPT-4o-mini, the no-evolution baseline outperformed ARISE on Phase~1 ($29\%$ vs $18\%$) and Phase~4 ($60\%$ vs $33\%$). Analysis of agent traces reveals two failure modes: (a)~GPT-4o-mini calls evolved tools incorrectly when raw reasoning would have succeeded, and (b)~the model struggles to compose multiple tool calls in sequence. This overhead effect disappears entirely with Claude Sonnet, which matches or exceeds the no-evolution baseline on every phase.

\subsubsection{Finding 3: Agent quality $>$ tool quantity}

Claude Sonnet achieved $78\%$ with only 2 self-evolved tools while GPT-4o-mini reached $44\%$ with $10 \pm 2$ tools. This $34$~pp gap demonstrates that ARISE amplifies existing model capability rather than replacing it. A strong model that uses tools judiciously benefits more from a minimal, precise toolset than a weak model surrounded by many tools it cannot wield effectively.

\subsubsection{Finding 4: Cross-domain generality}

To validate generality beyond SRE, we evaluated on \textbf{DataCorp}, a fictional data engineering company with custom CSV dialects, a data validation API, and a proprietary query language. Table~\ref{tab:crossdomain} summarizes the results. The $+42$~pp improvement confirms that self-evolution generalizes to fundamentally different task types.

\begin{table}[t]
    \centering
    \caption{Cross-domain results on DataCorp (GPT-4o-mini, quick mode).}
    \label{tab:crossdomain}
    \small
    \begin{tabular}{@{}lcc@{}}
        \toprule
        Condition & Overall Accuracy & $\Delta$ \\
        \midrule
        ARISE & \textbf{92\%} & --- \\
        No-evolution & 50\% & $-42$~pp \\
        \bottomrule
    \end{tabular}
\end{table}

\subsection{Error Analysis}

We manually inspected 30 failure trajectories (10 per seed) for GPT-4o-mini ARISE runs to categorize error types. Table~\ref{tab:errors} shows the breakdown.

\begin{table}[t]
    \centering
    \caption{Error categorization for GPT-4o-mini ARISE failures (30 sampled trajectories across 3 seeds).}
    \label{tab:errors}
    \small
    \begin{tabular}{@{}lcc@{}}
        \toprule
        Error Type & Count & \% \\
        \midrule
        Incorrect tool invocation & 11 & 37\% \\
        Tool exists but not called & 7 & 23\% \\
        Missing tool (not yet evolved) & 5 & 17\% \\
        Correct tool call, wrong reasoning & 4 & 13\% \\
        Check function strictness & 3 & 10\% \\
        \bottomrule
    \end{tabular}
\end{table}

The dominant failure mode (37\%) is incorrect tool invocation---the model calls the right tool with wrong arguments. Combined with ``tool exists but not called'' (23\%), this confirms that the bottleneck for weaker models is tool \emph{use}, not tool \emph{availability}. Only 17\% of failures stem from missing tools, suggesting that ARISE's synthesis pipeline produces adequate coverage.

\subsection{Tool Quality Analysis}

Across the GPT-4o-mini runs, ARISE synthesized an average of $21 \pm 3$ candidate tools per run, with a promotion rate of approximately $50\%$, yielding $10 \pm 2$ active tools. Rejected tools failed due to: sandbox test failures (41\%), adversarial test failures (35\%), and import restriction violations (24\%). The multi-stage validation pipeline caught real bugs---including division-by-zero errors on empty metric windows---validating the safety model's practical utility.

\subsection{Cost Analysis}

Table~\ref{tab:cost} reports the computational cost per 60-episode benchmark run. Tool synthesis uses GPT-4o-mini in all conditions; the agent model varies.

\begin{table}[t]
    \centering
    \caption{Cost and timing per 60-episode run.}
    \label{tab:cost}
    \small
    \begin{tabular}{@{}lccc@{}}
        \toprule
        Condition & Duration & LLM calls & Est.\ cost \\
        \midrule
        4o-mini no-evo & 8 min & 60 & \$0.18 \\
        4o-mini ARISE & 3--4 hr & $\sim$120 & \$0.44 \\
        4o-mini fixed & 2.5 hr & $\sim$240 & \$0.18 \\
        Claude no-evo & 10 min & 60 & \$3.00 \\
        Claude ARISE & 5 hr & $\sim$65 & \$5.50 \\
        \bottomrule
    \end{tabular}
    \vspace{2pt}

    \raggedright\scriptsize Evolution cycles dominate ARISE runtime: each cycle involves gap detection, synthesis, test generation, adversarial validation, and optional refinement (10--20 sequential LLM calls).
\end{table}

%-----------------------------------------------------------------------
\section{Limitations}
%-----------------------------------------------------------------------

\textbf{Statistical power.} Multi-seed results are reported for GPT-4o-mini only. Claude Sonnet results are from a single seed due to cost (\$5.50 per run). We acknowledge this limits the confidence of cross-model comparisons.

\textbf{Tool-calling overhead.} For weaker models, the overhead of tool selection and invocation can reduce performance on tasks where raw reasoning suffices. ARISE does not currently implement adaptive tool injection (presenting tools only when needed).

\textbf{Evolution latency.} Each evolution cycle takes 2--10 minutes of sequential LLM calls. This is acceptable for background workers but problematic for latency-sensitive applications.

\textbf{Evaluation scope.} Our benchmarks cover two domains (SRE operations, data engineering) using custom-designed environments with deterministic check functions. We do not evaluate on established tool-use benchmarks (ToolBench~\cite{qin2023toolllm}, API-Bank~\cite{li2023apibank}) because these assume fixed toolsets, which is orthogonal to ARISE's tool-creation focus. However, our custom benchmarks carry the risk of evaluation bias. Check function strictness may understate actual performance across all conditions equally.

\textbf{Safety guarantees.} While the multi-stage validation catches many bugs, it cannot provide formal safety guarantees. Production deployments should combine ARISE's validation with additional measures (network isolation, resource quotas, human review for high-stakes tools).

\textbf{Missing ablations.} We do not ablate individual components (adversarial testing, import restrictions, failure threshold values). Our tool quality analysis shows adversarial testing rejects 35\% of candidates and import checking catches unauthorized imports, but we have not measured the performance impact of disabling these components. This is an important direction for future work.

\textbf{Statistical significance.} With $n=3$ seeds, our standard deviations provide a rough measure of variance but are insufficient for formal significance testing. The Phase~2 improvement ($7\% \rightarrow 29\%$) is consistent across all seeds (20\%, 40\%, 27\%), suggesting a real effect, but we cannot establish $p$-values with this sample size.

\textbf{Library management.} ARISE does not currently implement tool forgetting or pruning. The \texttt{max\_library\_size} parameter caps the library at 50 tools, but there is no mechanism to remove underperforming tools. For long-running deployments, a decay-based pruning strategy (deprecating tools with low invocation counts) would be needed.

%-----------------------------------------------------------------------
\section{Discussion}
%-----------------------------------------------------------------------

ARISE demonstrates that the self-evolution paradigm works in practice, with important caveats. The results suggest a clear decision framework for practitioners:

\textbf{When to use ARISE.} The clearest value is in scenarios where tool access is essential---the agent literally cannot perform the task without I/O capabilities (HTTP calls, file access, proprietary format decoding). In these cases, ARISE consistently improves performance regardless of model capability. The DataCorp results ($+42$~pp) confirm this generalizes beyond a single domain. For tasks where reasoning alone suffices (e.g., parsing inline config text), ARISE provides no benefit and may introduce overhead for weaker models.

\textbf{Model selection matters more than tool count.} Claude Sonnet with 2 self-evolved tools ($78\%$) outperforms GPT-4o-mini with 10 tools ($44\%$) in a single-seed comparison. While this requires multi-seed confirmation for Claude, the magnitude of the gap ($34$~pp) suggests a real effect: ARISE is best understood as a \emph{capability amplifier} that multiplies existing reasoning ability rather than compensating for weaknesses.

\textbf{The tool-use overhead problem.} For weaker models, tool availability is a double-edged sword. GPT-4o-mini's overall performance \emph{decreased} with ARISE ($44\%$ vs $48\%$ no-evolution) because tool-calling overhead on reasoning tasks outweighed gains on tool-essential tasks. This motivates future work on adaptive tool injection---presenting tools only when the agent needs them.

\textbf{Distributed deployment.} We validated the S3/SQS distributed architecture through a live deployment on Amazon Bedrock AgentCore, where the ARISE agent served requests via the A2A protocol. The agent successfully loaded skills from S3 and reported trajectories to SQS across 9 test invocations. Full-scale distributed benchmarking remains future work.

\textbf{Deployment recommendations.} Based on our results: (1)~use a strong agent model for reasoning, (2)~a cheaper model for tool synthesis, (3)~start with seed tools for essential I/O, and (4)~set \texttt{failure\_threshold} $\geq 5$ to accumulate meaningful failure patterns before evolving.

%-----------------------------------------------------------------------
\section{Conclusion}
%-----------------------------------------------------------------------

ARISE enables LLM agents to autonomously extend their own capabilities through a validated self-evolution pipeline. Our evaluation across two domains and two model families reveals that self-evolution provides the largest gains on tasks requiring genuine tool capabilities ($+22$--$60$~pp on API-dependent tasks), while also uncovering a fundamental tension: tool-use overhead can hurt weaker models on reasoning-heavy tasks.

The finding that agent quality dominates tool quantity (Claude Sonnet $78\%$ with 2 tools vs.\ GPT-4o-mini $44\%$ with 10) has implications beyond ARISE: it suggests that the community's focus on building larger tool libraries may be misplaced relative to improving tool-use reasoning.

Future work will explore (1)~adaptive tool injection to mitigate overhead, (2)~cross-agent tool sharing for multi-tenant deployments, and (3)~hierarchical tool composition where evolved tools can call other evolved tools. ARISE is available as an open-source Python package (\texttt{pip install arise-ai}).

%-----------------------------------------------------------------------
% References
%-----------------------------------------------------------------------

\bibliographystyle{plain}
\begin{thebibliography}{12}

\bibitem{cai2023latm}
T.~Cai, X.~Wang, T.~Ma, X.~Chen, and D.~Zhou.
\newblock Large Language Models as Tool Makers.
\newblock \emph{arXiv preprint arXiv:2305.17126}, 2023.

\bibitem{wang2023voyager}
G.~Wang, Y.~Xie, Y.~Jiang, A.~Mandlekar, C.~Xiao, Y.~Zhu, L.~Fan, and A.~Anandkumar.
\newblock VOYAGER: An Open-Ended Embodied Agent with Large Language Models.
\newblock \emph{arXiv preprint arXiv:2305.16291}, 2023.

\bibitem{qian2023creator}
C.~Qian, C.~Han, Y.~Fung, Y.~Qin, Z.~Liu, and H.~Ji.
\newblock CREATOR: Tool Creation for Disentangling Abstract and Concrete Reasoning of Large Language Models.
\newblock \emph{arXiv preprint arXiv:2305.14318}, 2023.

\bibitem{yuan2023craft}
S.~Yuan, J.~Chen, Z.~Fu, X.~Ge, S.~Shah, C.~Janber, B.~Huang, and A.~Neubig.
\newblock CRAFT: Customizing LLMs by Creating and Retrieving from Specialized Toolsets.
\newblock \emph{arXiv preprint arXiv:2309.17428}, 2023.

\bibitem{schick2023toolformer}
T.~Schick, J.~Dwivedi-Yu, R.~Dess\`{\i}, R.~Raileanu, M.~Lomeli, L.~Zettlemoyer, N.~Cancedda, and T.~Scialom.
\newblock Toolformer: Language Models Can Teach Themselves to Use Tools.
\newblock \emph{arXiv preprint arXiv:2302.04761}, 2023.

\bibitem{hu2024adas}
S.~Hu, C.~Lu, and J.~Clune.
\newblock Automated Design of Agentic Systems.
\newblock \emph{arXiv preprint arXiv:2408.08435}, 2024.

\bibitem{yao2022react}
S.~Yao, J.~Zhao, D.~Yu, N.~Du, I.~Shafran, K.~Narasimhan, and Y.~Cao.
\newblock ReAct: Synergizing Reasoning and Acting in Language Models.
\newblock \emph{arXiv preprint arXiv:2210.03629}, 2022.

\bibitem{patil2023gorilla}
S.~Patil, T.~Zhang, X.~Wang, and J.~Gonzalez.
\newblock Gorilla: Large Language Model Connected with Massive APIs.
\newblock \emph{arXiv preprint arXiv:2305.15334}, 2023.

\bibitem{qin2023toolllm}
Y.~Qin, S.~Liang, Y.~Ye, K.~Zhu, L.~Yan, Y.~Lu, Y.~Lin, X.~Cong, X.~Tang, B.~Qian, et~al.
\newblock ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs.
\newblock \emph{arXiv preprint arXiv:2307.16789}, 2023.

\bibitem{li2023apibank}
M.~Li, Y.~Zhao, B.~Yu, F.~Song, H.~Li, H.~Yu, Z.~Li, F.~Huang, and Y.~Li.
\newblock API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs.
\newblock \emph{arXiv preprint arXiv:2304.08244}, 2023.

\bibitem{wang2022selfinstruct}
Y.~Wang, Y.~Kordi, S.~Mishra, A.~Liu, N.~Smith, D.~Khashabi, and H.~Hajishirzi.
\newblock Self-Instruct: Aligning Language Models with Self-Generated Instructions.
\newblock \emph{arXiv preprint arXiv:2212.10560}, 2022.

\bibitem{hong2023metagpt}
S.~Hong, X.~Zhuge, J.~Chen, X.~Zheng, Y.~Cheng, C.~Zhang, J.~Wang, Z.~Wang, S.~Yau, Z.~Lin, et~al.
\newblock MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework.
\newblock \emph{arXiv preprint arXiv:2308.00352}, 2023.

\end{thebibliography}

\end{document}
