---
title: Function-as-Agents Paradigm
url: https://www.emergentmind.com/topics/function-as-agents-paradigm
type: topic
---

# Function-as-Agents Paradigm

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 [2508.11665]; 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 [2605.23218]; and business-process, fog-computing, and agentic-services research recasts functions as goal-bearing or policy-bearing agents embedded in broader organizational workflows [2507.21823], [2601.20764], [2509.24380]. 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 [2508.11665]. 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 [2605.23218]. 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 [2507.21823], [2601.20764], [2509.24380].

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 [2510.23587]. 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 [2508.11665]. 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 [2508.11665] |
| Protocol-centric | Every invokable participant becomes a first-class entity in a coordination graph | Foundation Protocol [2605.23218] |
| Goal- or policy-centric | Services and business functions become agents with goals, policies, memory, and organization | Business-process, fog, and service frameworks [2507.21823], [2601.20764], [2509.24380] |

## 2. Formal models of functional agency

The most explicit execution-level formalization appears in StackPilot. A program is defined as a set of functions
\[
\mathcal{F} = \{f_1, f_2, \ldots, f_n\},
\]
with directed call graph
\[
G = (\mathcal{F}, E),
\]
where each function is
\[
f_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).
\]
The Function-as-Agents step is then
\[
\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,
\[
a_i = (\mathbf{x}_i, \mathbf{y}_i, s_i, \mathcal{B}_i).
\]
Inter-agent communication is captured by
\[
M_{i \rightarrow j}: \mathbf{y}_i \rightarrow \mathbf{x}_j,
\]
and the resulting collaboration graph is
\[
C = (\mathcal{A}, \mathcal{E}).
\]
This formulation makes explicit that function boundaries, call-graph structure, and call-return semantics are themselves the agent decomposition [2508.11665].

A different formalization appears in agent-based business-process development. There, an agent is a 6-tuple
\[
\mathbf{Agent} = \mathbf{(aID, C_a, OT_a, OR_a, OF_a, g_a)},
\]
where capabilities \(C_a\), trigger objects \(OT_a\), resource objects \(OR_a\), final objects \(OF_a\), and goal \(g_a\) jointly define a function-like but goal-conditioned unit. Goals are defined as
\[
\mathbf{g} = \mathbf{(gID, O_g, A_g)},
\]
and merge goals compute their object set by
\[
\mathbf{OG_g} = \bigcup_i \mathbf{OF_i}.
\]
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 [2507.21823].

Agentic Fog presents yet another formalization in which infrastructure functions are modeled as policy-driven agents. A general agent is
\[
\mathcal{A}_i = \langle \mathcal{O}_i, \zeta_i, \pi_i, \Lambda_i, \upsilon_i \rangle,
\]
and each fog node hosts
\[
A_i = (\zeta_i, \mathcal{M}_i, \pi_i).
\]
The global objective is
\[
\mathcal{O}^{*} = \alpha L + \beta C + \gamma R,
\]
while local decision making minimizes the expected marginal contribution
\[
\upsilon_i(a) = \mathbb{E}[\Delta \mathcal{O}_i \mid \zeta_i, \mathcal{M}_i, \mathcal{M}^{*}, a].
\]
Because the induced game admits the exact potential function
\[
\Phi = \mathcal{O}^{*},
\]
local policy updates become aligned with a global optimization problem [2601.20764]. 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
\[
\text{entity\_id} = \text{HostUid} : \text{EntityUid},
\]
and a handler is described as
\[
\mathrm{Handler}_f: (\mathrm{Envelope}, \mathrm{Activity}, \mathrm{Session}) \mapsto \mathrm{Events} \cup \mathrm{Receipts}.
\]
A function call is therefore not just an RPC. It is an `Activity` inside a `Session`, transported by signed `Envelope`s, producing `Event`s and optionally `Receipt` and `Provenance` objects [2605.23218]. 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
\[
\mathcal{V}(P) = \mathcal{S}(\mathcal{A}, G, \mathcal{L}, \mathcal{H}),
\]
where \(\mathcal{A}\) is the set of function-agents, \(G\) the call graph, \(\mathcal{L}\) the LLM-as-Executor, \(\mathcal{H}\) the global heap, and \(\mathcal{S}\) 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 [2508.11665].

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 [2606.15874]. 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
\[
\mathcal{F} = \{f_1,\dots,f_n \mid f_i \in \mathcal{V}\}
\]
instead of updating LLM weights, so adaptation is expressed as progressive addition, revision, and removal of callable functions [2402.11359]. Best-of-Q separates action proposal from action selection: a frozen VLM proposes \(N\) candidates, a Q-function scores them via \(Q_\theta(s,a)\), and the system executes
\[
a^* = \arg\max_{a \in A_{\mathrm{cand}}} Q_\theta(s,a).
\]
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% [2601.22701]. 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” [2605.23218]. The reference implementation includes a contract state machine
\[
\mathrm{DRAFT} \rightarrow \mathrm{PENDING} \rightarrow \mathrm{ACTIVE} \rightarrow \mathrm{COMPLETING} \rightarrow \mathrm{SETTLING} \rightarrow \mathrm{SETTLED},
\]
with failure branches to `CANCELLED` and `DISPUTED`. Sessions can carry budget ceilings
\[
B = (\mathrm{max\_spend}, \mathrm{currency}, \mathrm{token\_ceilings}, \dots),
\]
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 [2605.23218].

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” [2509.24380]. 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 [2509.24380].

At the level of decentralized coordination, AgentSociety supplies a mechanism grounded in liquid democracy and information diffusion. Agents are nodes in an undirected graph \(G=(\mathcal{N},E)\), 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 [2605.26203]. 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 [2505.15799]. 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) [2508.11665] |
| 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% [2601.22701] |
| Agentic Fog | Distributed fog coordination | 15–30% lower average latency than Greedy and 10–18% lower latency than ILP under dynamic workloads [2601.20764] |
| Symbiotic Agents | AGI-driven 5G/6G network control | Decision errors reduced fivefold; smaller language models 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% [2507.17695] |
| AgenticAITA | Autonomous trading dry run | 157 zero-intervention invocations across 76 assets with an 11.5% agentic friction rate [2605.12532] |

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 [2508.11665], [2601.22701]. 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 [2601.20764], [2507.17695], [2605.12532]. 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 [2510.23587]. 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 [2606.15874]. 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 [2508.11665]. 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 \(\Phi\) [2601.20764]. At a broader engineering level, Agentic Problem Frames argues that frameless development risks scope creep and open-loop failures, and proposes dynamic specification
\[
(E_t, C_t) \xrightarrow{M} S_t,
\]
a Hoare-style execution relation
\[
\{S_t\} A \{K_{t+1}\},
\]
and an Act–Verify–Refine loop that aims toward
\[
\lim_{t \to T} \{S_t, K_{t+1}\} \vdash R.
\]
This framework locates reliability not in internal model intelligence alone but in bounded jurisdiction, runtime context injection, and explicit verification [2602.19065].

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 [1902.09469]. 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.

Source: https://www.emergentmind.com/topics/function-as-agents-paradigm