A Case for Simulation-Driven Resilience in Agentic Data Systems

Rethinking AI Cloud Infrastructure for Agentic Serving Systems with the Aries Experimentation Framework

This work presents Aries, a full-stack experimentation framework that separates task semantics from execution configurations, reconstructs cross-component agent trajectories with correlated system telemetry, and exposes stateful tool execution through a consistent interface across heterogeneous sandbox substrates.

Towards Designing An Execution Control System with Metastability Resilience

Modern databases must serve highly variable workloads: short queries that demand low latency and long-running tasks that consume significant resources. Under heavy load, these workloads risk spiraling into metastability, a self-sustaining state of degraded throughput and high latency that persists even after the initial stressor is removed. In this paper, we investigate the design of an Execution Control System (ECS) specifically engineered for metastability resilience.To explore this design space, we developed MESSI, a discrete-event simulator implemented in Go that enables us to replay stress scenarios, visualize the formation of metastable feedback loops, and quantify resource allocation trade-offs. By representing systems as a graph of Logic Nodes and Processors, MESSI captures queueing dynamics, I/O delays, and retry policies at a fine grained level. Our research highlights how conventional management policies can inadvertently trigger metastable failures and demonstrates that principled load shedding and bounded concurrency (via a ticket-based abstraction) are essential for maintaining responsiveness. Our findings provide a roadmap for building performant and predictable ECS that explicitly operate within a safe resilient envelope even under dynamically shifting workloads.

Workflow, Not Prose: A Multi-Agent Methodology for Data Agents

Tool-Making and Self-Evolving LLM Agents in Low-Latency Systems

Production LLM agents often waste latency and reliability by regenerating code for the same procedural steps on every request. We replace this inference-time coding loop with an agentic tool-making pipeline that compiles repeated SOP steps into validated, versioned tools before deployment. The tool-maker grounds synthesis in the live environment as it collects execution traces, observes backend schemas and values, generates candidate tools, and repairs them against labeled cases. At runtime, the production agent calls these tools directly and falls back to code generation only when needed. We deploy the approach in a Fulfillment Center alarm-triage system, where an agent diagnoses alarms against a 44-node SOP over heterogeneous metric backends. In production, tool calls reduce p50 latency by 42%. On 1,500 historical alarms, they reduce end-to-end error rate by up to 53% by suppressing run-to-run variance in repeated steps. Because tools return compact structured verdicts, they also enable a simpler direct-call architecture, reducing p50 latency by a further 62% in a controlled ablation. Versioned tools also improve auditability and expose specification gaps and upstream data drift. Our results show that agents that build and maintain their own tool libraries, a key element of self-evolving agents, can make industrial LLM systems faster, more reliable, and easier to operate.

Architecting the Agentic AI Systems Stack What Should Infrastructure Manage When the Unit of Work Is a Trajectory-

Agentic AI is becoming a systems workload. A delegated goal is not a single prompt-response request; it unfolds as an agentic trajectory through model calls, tool calls, context operations, waits, approvals, recovery actions, and external effects. The trajectory is the smallest unit over which budget, authority, recovery, evidence, and physical cost can be stated without hiding essential state in application convention. Existing managed units still matter. Instructions, processes, requests, and model calls each made a different layer of the stack schedulable, protectable, accountable, recoverable, and optimizable. Agentic trajectories strain these units because state, authority, cost, and side effects span many calls. The stack therefore needs a system-visible unit for such trajectories. This paper calls that unit a managed trajectory and focuses on the contract that gives lower layers a common handle on identity, goals, budgets, placement, memory, authority, effects, evidence, and recovery. From a computer architect's perspective, agentic work is an interface and resource-management problem. The paper develops a stack organization and open research agenda around context hierarchy, protected effects, and metrics for useful work per verified action rather than only tokens per second.

Evaluating Agentic Code Repair Capabilities in Distributed Systems

DDBench is introduced, a code-repair benchmark of 60 historical bugs mined from 13 open-source distributed systems, partitioned into three difficulty tiers, isolating the effect of debugging context from model capability.