Agents as Software: A Programming Languages Agenda for Agent Reliability

Shraddha Barke; Adithya Murali

cs.PLSep 26, 2026

Agents as Software: A Programming Languages Agenda for Agent Reliability

Authors: Shraddha Barke, Adithya Murali

Organizations: Microsoft Research Redmond, USA · University of Wisconsin-Madison Madison, USA

Abstract

AI agents increasingly resemble software systems: they call tools, remember facts, follow policies, delegate work, and take actions with real consequences. % Yet the ``program'' of an agent is scattered across prompts, tools, memories, workflows, and execution traces, making its behavior difficult to inspect through ordinary testing and debugging alone. % This essay argues that a programming-systems perspective offers a natural lens for making agents reliable. % We recast agents as programmable artifacts whose behavior can be specified over traces and state, checked before deployment, monitored during execution, and improved from observed failures. % The goal is not to make probabilistic agents behave like deterministic programs, but to give them enough structure that their behavior can be reasoned about, controlled, and repaired.

Figures & tables

Panel of Figure 1 — Figure 1. The programming-systems view of an agent. The agent’s “program” (left) is distributed across artifacts in different languages, some of which are written during execution. An abstraction mechanism lifts concrete executions into event traces, over which specifications are stated in some logic and vocabulary of atoms (middle). Analyses (right) consume these before, during, and after execution, and what they observe is fed back into the artifacts.

Spec example	Property kind	Logic	Usage
Tool inputs/outputs must satisfy the given pre/post- condition	Interface correctness	FOL	R
Every Acquire(r) must have a matching Release(r) later before another Acquire(r)	Resource well-formedness	Regexes over trace vocabulary	R
Cannot issue delete_resource(r) without prior Owns(agent, r) in session	Action admissibility	LTL	R
Order retrieval must be preceded by an authentication of the corresponding customer	Action admissibility	LTL	R
confirmation_token argument equals token from prior request_confirmation ; not reused	Input integrity (freshness / use-once)	Session types	R
Capabilities held by subagent $\subseteq$ capabilities held by parent at spawn	Permission discipline	Permission Logics	R

Table 1. An example set of agent specifications, varied by specification purpose and type of logic that may be used to express the property. The Usage column notes whether these properties are typically found in a survey of related work on agent reliability (R), were not found in related work by the authors verbatim but are essentially natural extensions of those currently used (B as in Boundary), or are speculated by the authors (S).

Panel of Figure 2 — Figure 2. Runtime monitor example. The agent attempts to issue a refund (Step 3), but the monitor blocks the action because the required temporal guard verify_return_receipt has not been discharged. The agent then re-plans by first checking whether the return has been received. A runtime-monitoring example showing an agent trace, monitor state, a blocked refund action, and a safe re-planning step.

Phase	Analysis Technique	What It Checks	Artifact / Object
Static Analysis	Prompt testing and analysis	Are task obligations explicit? Does the prompt specify when to call tools, stop, escalate, or ask for confirmation?	Prompt text
	Tool contract validation	Are tool preconditions, effects, and required evidence explicit? Are high-impact actions guarded?	Tool schemas
	Cross-artifact consistency	Can individually safe artifacts compose into unsafe behavior? Do the prompt, tools, and policies fit together, or do they create gaps where the agent can take an unsafe action?	Prompt $\times$ Tools $\times$ Policy
	Information-flow analysis	Can untrusted information influence sensitive actions without validation?	Dataflow across artifacts
	Abstract interpretation	Can an unsafe action become reachable before its required evidence, authorization, or confirmation is established?	Abstract agent state
Dynamic Analysis	Runtime state tracking	What facts, permissions, constraints, obligations, and provenance are established by the current execution prefix?	Execution prefix

Table 2. Analysis techniques for agent reliability, organized by phase. Static analysis checks agent configurations before execution; dynamic analysis monitors behavior during execution.

Explore similar work

Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model
Aug 14, 2026Stephanie JarmakAI Agent Reliability Coding Agents
Willful Disobedience: Automatically Detecting Failures in Agentic Traces
Mar 25, 2026Reshabh K Sharma, Shraddha Barke, Benjamin ZornAI Agent Evaluation AI Agent Auditing
University of Washington Seattle, Washington, USA · Microsoft Research Redmond, Washington, USA
On the Reliability of Computer Use Agents
Apr 20, 2026Gonzalo Gonzalez-Pumariega, Saaket Agashe, Jiachen Yang +2AI Agent Reliability Agent Reliability
Simular

Aug 14, 2026J/K move · Enter open · S save

Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model

Stephanie Jarmak

AI Agent Reliability Coding Agents AI Agent Evaluation Software Engineering Agents

Open paper AskPDF arXiv

AI coding agents are commonly evaluated as models but deployed as systems. Their reliability depends not only on model capability, but on the harness, execution state, retrieval, memory and state management, permissions, review interfaces, and resource allocation. This monograph examines those boundaries and develops a framework for evaluating and operating coding agents reliably. It synthesizes 164 scholarly works, 100 practitioner records, 29 benchmark records, and 17 author-system case records through a structured multivocal review, targeted update audits, software-engineering coverage analysis, and distributed-systems evidence synthesis. Across this evidence, many apparent model failures originate elsewhere in the system, while improvements at one layer often fail to propagate to end-to-end outcomes. Evaluation and operation are treated as a dependency chain in which weaknesses in task construction, execution environments, retrieval, state management, verification, or observability can invalidate downstream conclusions. The monograph contributes a versioned catalog of 206 reliability records: 193 gated practices, including 56 developed in depth, plus 13 research leads; an evidence ledger; a framework for dependency and repair asymmetry across the agent lifecycle; measurements and failure cases from operated agent systems; runnable evaluation and reliability protocols; and five reusable agent skills with evidence maps. Together, these provide a system-level methodology for distinguishing model capability from infrastructure effects, designing defensible evaluations, and building systems that recover safely when components fail. The review is structured rather than exhaustive, evidence strength varies by topic, and results depend on workload and configuration. The methods record which search lanes were executed, which remain unexecuted, and limits on evidence-grading claims.

Abstract

Explore similar work

Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model

Willful Disobedience: Automatically Detecting Failures in Agentic Traces

On the Reliability of Computer Use Agents