Papers
Topics
Authors
Recent
Search
2000 character limit reached

Function-as-Agents Paradigm

Updated 8 July 2026
  • Function-as-Agents is a paradigm that reifies program functions as autonomous agents with state, enabling them to reason, coordinate, and be accountable.
  • It encompasses execution-centric, protocol-centric, and goal-centric approaches that formalize function invocation through stateful, interactive agent models.
  • Empirical studies across code execution, distributed control, and business-process management illustrate its performance benefits and spur debates on reliability and control flow.

The Function-as-Agents paradigm denotes a family of research programs that reify functions, tools, services, or program procedures as autonomous or quasi-autonomous agents rather than treating them as inert call targets. In current work, this move appears in several distinct but related forms: StackPilot models each program function as an autonomous agent with its own inputs, outputs, local state, and body (Zhao et al., 6 Aug 2025); Foundation Protocol models “everything that can be invoked or can act” as an Entity, so functions, tools, services, humans, agents, and organizations participate in the same graph-native coordination layer (Liu et al., 22 May 2026); and business-process, fog-computing, and agentic-services research recasts functions as goal-bearing or policy-bearing agents embedded in broader organizational workflows (AzariJafari et al., 29 Jul 2025, Akbar et al., 28 Jan 2026, Deng et al., 29 Sep 2025). The common theme is that function execution is elevated from a local request-response primitive to a stateful unit of reasoning, coordination, and accountability.

1. Conceptual scope and terminological boundaries

Current literature does not use Function-as-Agents to mean one single architecture. In StackPilot, the paradigm is execution-centric: each function is modeled as an autonomous agent capable of fine-grained reasoning and collaborative verification, and function invocation becomes the unit of execution (Zhao et al., 6 Aug 2025). In Foundation Protocol, the paradigm is protocol-centric: a function, tool, API, microservice, or GPU provider is represented in the same way as a human, autonomous agent, or company, namely as an addressable entity with identity, capabilities, and policies (Liu et al., 22 May 2026). In agentic business-process development, Agentic Fog, and Agentic Services Computing, the shift is organizational: a service is no longer treated as a fixed task endpoint but as a goal-driven or policy-driven agent that operates over objects, local state, and social structure (AzariJafari et al., 29 Jul 2025, Akbar et al., 28 Jan 2026, Deng et al., 29 Sep 2025).

A recurrent misconception is that any tool-calling system already instantiates the paradigm. The survey on data agents argues that simple query responders, tool-using executors, and autonomous orchestrators are often conflated, and introduces an L0–L5 taxonomy to separate stateless prompt-response systems, tool-using systems, and autonomous orchestration (Zhu et al., 27 Oct 2025). This taxonomy places prompt-response assistants at L1, environment-facing tool users at L2, and autonomous pipeline orchestrators at L3. StackPilot makes a closely related distinction when it contrasts typical tool-calling with a design in which the program’s own functions are reified as agents, rather than only external tools being callable (Zhao et al., 6 Aug 2025). This suggests that the paradigm is best understood as a spectrum whose strongest form begins when functions become stateful decision units rather than merely typed endpoints.

Formulation Core reformulation Representative work
Execution-centric Each program function invocation becomes an agent instance with local state and interfaces StackPilot (Zhao et al., 6 Aug 2025)
Protocol-centric Every invokable participant becomes a first-class entity in a coordination graph Foundation Protocol (Liu et al., 22 May 2026)
Goal- or policy-centric Services and business functions become agents with goals, policies, memory, and organization Business-process, fog, and service frameworks (AzariJafari et al., 29 Jul 2025, Akbar et al., 28 Jan 2026, Deng et al., 29 Sep 2025)

2. Formal models of functional agency

The most explicit execution-level formalization appears in StackPilot. A program is defined as a set of functions

F={f1,f2,,fn},\mathcal{F} = \{f_1, f_2, \ldots, f_n\},

with directed call graph

G=(F,E),G = (\mathcal{F}, E),

where each function is

fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).

The Function-as-Agents step is then

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},

with each agent defined identically to the function tuple,

ai=(xi,yi,si,Bi).a_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).

Inter-agent communication is captured by

Mij:yixj,M_{i \rightarrow j}: \mathbf{y}_i \rightarrow \mathbf{x}_j,

and the resulting collaboration graph is

C=(A,E).C = (\mathcal{A}, \mathcal{E}).

This formulation makes explicit that function boundaries, call-graph structure, and call-return semantics are themselves the agent decomposition (Zhao et al., 6 Aug 2025).

A different formalization appears in agent-based business-process development. There, an agent is a 6-tuple

Agent=(aID,Ca,OTa,ORa,OFa,ga),\mathbf{Agent} = \mathbf{(aID, C_a, OT_a, OR_a, OF_a, g_a)},

where capabilities CaC_a, trigger objects OTaOT_a, resource objects G=(F,E),G = (\mathcal{F}, E),0, final objects G=(F,E),G = (\mathcal{F}, E),1, and goal G=(F,E),G = (\mathcal{F}, E),2 jointly define a function-like but goal-conditioned unit. Goals are defined as

G=(F,E),G = (\mathcal{F}, E),3

and merge goals compute their object set by

G=(F,E),G = (\mathcal{F}, E),4

This replaces task-sequence semantics with goal–object–agent semantics, so that a function-agent is defined not only by what it does but by which business goal it advances and which objects it consumes or produces (AzariJafari et al., 29 Jul 2025).

Agentic Fog presents yet another formalization in which infrastructure functions are modeled as policy-driven agents. A general agent is

G=(F,E),G = (\mathcal{F}, E),5

and each fog node hosts

G=(F,E),G = (\mathcal{F}, E),6

The global objective is

G=(F,E),G = (\mathcal{F}, E),7

while local decision making minimizes the expected marginal contribution

G=(F,E),G = (\mathcal{F}, E),8

Because the induced game admits the exact potential function

G=(F,E),G = (\mathcal{F}, E),9

local policy updates become aligned with a global optimization problem (Akbar et al., 28 Jan 2026). Together, these formulations indicate that the paradigm replaces the purely extensional view of functions as stateless maps with models that attach identity, state, local policy, interfaces, and contribution structure to each functional unit.

3. Runtime architectures and control ownership

Foundation Protocol provides a concrete runtime architecture for turning functions and tools into protocol-native agents. Its starting point is the Entity, defined as an addressable participant with identity, capability metadata, and privacy controls. A function-agent is such an entity plus a handler that maps protocol messages to function execution. Addressing is

fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).0

and a handler is described as

fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).1

A function call is therefore not just an RPC. It is an Activity inside a Session, transported by signed Envelopes, producing Events and optionally Receipt and Provenance objects (Liu et al., 22 May 2026). This architecture makes a function an accountable participant in a graph of relationships, budgets, roles, and policies.

StackPilot operationalizes the paradigm at the program-runtime level through a stack-based scheduler with snapshots. The global verifier is

fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).2

where fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).3 is the set of function-agents, fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).4 the call graph, fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).5 the LLM-as-Executor, fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).6 the global heap, and fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).7 the scheduler. On a function call, StackPilot performs a stop-the-world snapshot: local state, execution pointer, logs, and interface state are frozen, a callee agent is instantiated, and control returns only after exact restoration of the caller snapshot. The paper characterizes this context switching as deterministic and lossless (Zhao et al., 6 Aug 2025).

A more radical claim about control ownership is made by Agentic Programming. There, the program governs all control flow, while the LLM is an adaptive component called only where reasoning or generation is needed. Context is built from the execution history’s call tree and forms a DAG; each call’s context length is determined by call depth rather than by accumulation over steps. In a computer-use case study on OSWorld, the LLM-as-Code design with Claude Sonnet 4.6 achieved 86.8 overall with 15 steps, compared with Holo3-35B-A3B at 80.4 and OpenAPA with Gemini-3.1-pro at 78.3, both at 100 steps (Qi et al., 14 Jun 2026). This is an explicit rejection of the design in which the LLM itself owns looping, branching, and termination.

Two additional systems refine control without modifying the core model. AgentOptimizer treats functions as learnable agent parameters and optimizes the function set

fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).8

instead of updating LLM weights, so adaptation is expressed as progressive addition, revision, and removal of callable functions (Zhang et al., 2024). Best-of-Q separates action proposal from action selection: a frozen VLM proposes fi=(xi,yi,si,Bi).f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).9 candidates, a Q-function scores them via A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},0, and the system executes

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},1

On WebVoyager, this improved a Qwen2.5-VL-7B agent from 38.8% to 55.7% and a GPT-4.1 agent from 82.4% to 88.8% (Biré et al., 30 Jan 2026). These designs suggest that the runtime core of the paradigm is not merely “LLM + tools,” but structured ownership of control, context, and adaptation.

4. Coordination layers, economics, and governance

Foundation Protocol extends the paradigm from local execution to inter-agent society. Its minimal vocabulary comprises Entity, Session, Activity, Envelope, Event, Receipt/Settlement, and Provenance, and it adds economic primitives for “metering, receipts, settlement references, and dispute signals, in a ledger-agnostic form” (Liu et al., 22 May 2026). The reference implementation includes a contract state machine

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},2

with failure branches to CANCELLED and DISPUTED. Sessions can carry budget ceilings

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},3

and every inbound message passes through an ordered checkpoint pipeline for ACL checks, session validation, rate limiting, payment verification, contract approval, payment approval, and custom policies. In this formulation, a function-agent is governable because identity, billing, provenance, and audit are built into the invocation substrate rather than added after the fact (Liu et al., 22 May 2026).

Agentic Services Computing generalizes this into a lifecycle- and capability-driven framework for “intelligent service agents that perceive, decide, collaborate, and evolve in dynamic environments” (Deng et al., 29 Sep 2025). Its “Scale” framework distinguishes five characteristics that move services beyond static functions: stateful and context-aware interaction, cognitive autonomy, agent as goal executor, lifelong collaborative learning, and end-to-end lifecycle governance. The lifecycle is organized as Design, Deployment, Operation, and Evolution. This recasts service composition as the management of living, adaptive service agents rather than of static request-response components (Deng et al., 29 Sep 2025).

At the level of decentralized coordination, AgentSociety supplies a mechanism grounded in liquid democracy and information diffusion. Agents are nodes in an undirected graph A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},4, each with base model, state, tools, and role; delegation to more competent neighbor agents is shown to be incentive compatible, and the resulting consensus routing path is selected by collective delegation. The mechanism characterizes a Nash equilibrium in which agent payoffs are reflective of marginal contributions (Kesari et al., 25 May 2026). This introduces a strong economic reading of the paradigm: functions-as-agents need not only execute and collaborate; they may also strategically route tasks and information under explicit reward mechanisms.

The broader institutional consequence is highlighted by work on the agentic economy, which distinguishes unscripted interactions from unrestricted interactions. Rich, natural-language-like communication can be technically enabled while network openness remains governed by market structure and policy (Rothschild et al., 21 May 2025). For Function-as-Agents systems, this implies that semantic flexibility and orchestration power do not by themselves determine openness, interoperability, or accountability.

5. Representative applications and reported results

Reported evaluations span code execution, web interaction, distributed infrastructure control, network management, and autonomous trading. The metrics are heterogeneous and not directly comparable, but they show that the paradigm is already being operationalized across distinct computational substrates.

System Domain Reported result
StackPilot Environment-free code verification and execution Reliability 96.9 on HE (Python), 96.0 on MBPP, 89.6 on HE (Java), and 92.7 on HE (Rust) (Zhao et al., 6 Aug 2025)
Best-of-Q Web agents on WebVoyager Qwen2.5-VL-7B improved from 38.8% to 55.7%; GPT-4.1 improved from 82.4% to 88.8% (Biré et al., 30 Jan 2026)
Agentic Fog Distributed fog coordination 15–30% lower average latency than Greedy and 10–18% lower latency than ILP under dynamic workloads (Akbar et al., 28 Jan 2026)
Symbiotic Agents AGI-driven 5G/6G network control Decision errors reduced fivefold; smaller LLMs achieved similar accuracy with a 99.9% reduction in GPU resource overhead and near-real-time loops of 82 ms; RAN over-utilization reduced by approximately 44% (Chatzistefanidis et al., 23 Jul 2025)
AgenticAITA Autonomous trading dry run 157 zero-intervention invocations across 76 assets with an 11.5% agentic friction rate (Letteri, 1 May 2026)

These results suggest two broad application regimes. One is execution-centric, where each function invocation becomes a stateful or deliberative execution unit, as in StackPilot and Best-of-Q (Zhao et al., 6 Aug 2025, Biré et al., 30 Jan 2026). The other is coordination-centric, where the function-agent is a controller, negotiator, or service endpoint embedded in a larger infrastructure, as in fog systems, network optimization, and trading pipelines (Akbar et al., 28 Jan 2026, Chatzistefanidis et al., 23 Jul 2025, Letteri, 1 May 2026). The empirical record therefore supports the claim that the paradigm is not confined to tool-calling chat agents; it is being used to redesign control loops, routing mechanisms, and organizational workflows.

6. Debates, limitations, and prospective directions

A central debate concerns what should count as an agent at all. The survey on data agents argues that the term suffers from terminological ambiguity and that the decisive transition is from L2 procedural execution to L3 autonomous orchestration (Zhu et al., 27 Oct 2025). Under this view, many current systems remain tool-using executors rather than full agentic orchestrators, even when they use function calling or maintain conversational state.

A second debate concerns ownership of control flow. Agentic Programming argues that token explosion, control-flow hallucination, and unreliable completion are not implementation bugs but architectural consequences of assigning looping, branching, and sequencing to a probabilistic system (Qi et al., 14 Jun 2026). StackPilot identifies a related but narrower limitation at the framework level: dependence on LLM reasoning accuracy, lack of full support for code that requires graphics, hardware, OS-level operations, or complex external APIs, and a serial scheduler that is essentially single-threaded (Zhao et al., 6 Aug 2025). These criticisms converge on the view that reifying functions as agents is not sufficient unless control boundaries are carefully engineered.

A third debate concerns reliability under partial observability and imperfect utility design. Agentic Fog notes that local utility estimation assumes shared memory provides enough data to build consistent estimators, that objectives may not decompose cleanly into marginal contributions, and that convergence is only to local minima of A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},5 (Akbar et al., 28 Jan 2026). At a broader engineering level, Agentic Problem Frames argues that frameless development risks scope creep and open-loop failures, and proposes dynamic specification

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},6

a Hoare-style execution relation

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},7

and an Act–Verify–Refine loop that aims toward

A={aiai=Agent(fi), fiF},\mathcal{A} = \{ a_i \mid a_i = \mathrm{Agent}(f_i),\ f_i \in \mathcal{F} \},8

This framework locates reliability not in internal model intelligence alone but in bounded jurisdiction, runtime context injection, and explicit verification (Park, 22 Feb 2026).

At the most general level, Embedded Agency challenges the classical “agent as function” abstraction itself. Traditional models assume agents are cleanly separated from their environment, have a known functional relationship with that environment, can model it in every detail, and need not reason about themselves or their internal parts. Embedded agents do not have well-defined i/o channels, are smaller than their environment, and must reason about themselves as physical systems made of interacting parts (Demski et al., 2019). This suggests that the strongest future versions of the Function-as-Agents paradigm will likely require bounded world models, explicit competence and delegation mechanisms, richer policy and provenance layers, and stronger methods for verifying self-modifying or socially embedded function-agents rather than treating them as idealized black-box policies.

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to Function-as-Agents Paradigm.