Agent-Oriented Invocation Systems

• Agent-oriented invocation systems are software frameworks that let AI agents autonomously trigger capabilities using structured inputs, explicit contracts, and deterministic execution.
• They transition traditional human-centric interfaces to machine-friendly protocols, enabling dynamic orchestration and reliable, protocol-governed invocations.
• Recent advancements integrate formal models, semantic contracts, and layered runtime architectures to enhance efficiency, safety, and governance in AI-native systems.

Searching arXiv for the cited papers to ground the article in current literature. Agent-oriented invocation systems are software and systems arrangements in which agents, rather than human operators or conventional deterministic programs, are treated as the primary invokers of capabilities, services, protocols, and operating-system-mediated actions. In current research, the term spans several closely related shifts: from human-oriented interfaces to machine-invocable agent interfaces and invocable capabilities; from OS abstractions centered on processes, threads, and syscalls to ones centered on agents, goals, capabilities, context, and actions; and from ad hoc inter-agent messaging to explicitly governed, protocol- or contract-based invocation workflows (Wang et al., 19 Mar 2026, Sharma et al., 1 Jun 2026).

1. Conceptual foundations and scope

A central formulation defines an agent interface as a software interaction layer designed for machine invocation, characterized by structured inputs, explicit semantics, and deterministic execution. In that formulation, the interface is optimized for interpretability, reliable invocation, and composability rather than human navigation and usability. The same work defines an invocable capability as a minimal, self-contained unit of functionality that exposes a structured interface and can be reliably executed by an AI agent without human intervention; its key properties are explicitly structured inputs and outputs, self-contained execution given its inputs, and predictable behavior under the same inputs and environment (Wang et al., 19 Mar 2026).

This capability-centric view reframes the dominant software abstraction. Human-oriented interfaces are described as optimized for perception and usability, with ambiguous and flexible inputs, manual execution, predefined workflows, and feature/page as the abstraction. Agent interfaces, by contrast, are optimized for machine interpretability and reliability, with structured and validated inputs, autonomous execution, dynamic orchestration, and capability/contract as the abstraction. The same account describes an architectural transition from monolithic, feature-centric applications to capability-based systems dynamically composed by AI agents at runtime, with the UI layer remaining but becoming secondary for supervision, debugging, and exception handling (Wang et al., 19 Mar 2026).

Earlier multi-agent and hybrid systems literature already treated invocation as more than a raw call. In ACRE, invocation is modeled as a protocol-driven conversation with an initial trigger, correlated message flow, defined completion or failure, and explicit exception mechanisms such as timeout, cancel, and not-understood. In SoSAA, invocation is the set of mechanisms by which intentional agents locate, bind to, configure, and call component-level services, data producers/consumers, and event sources/sinks through a standardized interface that exposes component capabilities as actionable operations and percepts (Lillis, 2017, Lillis et al., 2014).

This suggests that “Agent-Oriented Invocation Systems” names a broader family rather than a single protocol: capability invocation inside AI-native software, conversation-governed inter-agent invocation, and service- or component-mediated invocation all instantiate the same underlying concern—how an agent may act through externalized interfaces without collapsing invocation semantics into either GUI manipulation or unrestricted free-form generation.

2. Core abstractions and formal models

Formalization is uneven across the literature. The conceptual software-design account that introduces agent interfaces and invocable capabilities explicitly does not provide formal mathematical models, typed interface notation, pre/postconditions, invariants, side-effect models, state assumptions, grammars, or reliability functions. It also does not formalize composability algebraically, define invocation semantics with transition systems, or introduce capability graphs or DAGs (Wang et al., 19 Mar 2026). That omission is itself significant: the paper positions agent-oriented invocation as an architectural foundation, but leaves its formal semantics largely open.

A more explicit systems formalization appears in the Agent Operating System literature. There, an agent is modeled as

$A=(id,G,C,X,S),$

where $id$ is a durable identity with scoped authority, $G$ is a goal/task graph, $C$ a set of granted capabilities and bounds, $X$ a deterministic context view, and $S$ agent state. An invocation event is modeled as

$$e=(A,\text{tool }t,\text{params }p,\text{intent }i,\text{context }X,\text{env }E,\text{time }\tau,\text{versions }v),$$

with a deterministic policy decision function

$D(e)\in\{\text{allow},\text{deny},\text{defer}\}.$

The same formulation adds a capability validity predicate $\kappa(A,t,p,E,\tau)$ and four boundary invariants, including that no side-effecting action executes unless $D(e)=\text{allow}$ and that all outcomes are audit-logged before rescheduling (Sharma et al., 1 Jun 2026).

A different formal move appears in AOrchestra, where the unit of invocation is not primarily a tool call but a spawned specialized sub-agent. Any agent instance is represented by the four-tuple

$id$0

where $id$1 is instruction, $id$2 curated working context, $id$3 tool set, and $id$4 the underlying model. The orchestrator’s action space is restricted to

$id$5

making delegation itself the principal invocation mechanism (Ruan et al., 3 Feb 2026).

ACRE offers a more traditional protocol-theoretic formalization. It defines messages as

$id$6

a protocol as

$id$7

and a conversation as

$id$8

Invocation is then governed by predicates such as $id$9 and $G$0, with operational rules for matching, failure, conversation creation, advancement, unmatched messages, and ambiguity detection (Lillis, 2017).

AaaS-AN adds a service-knowledge formalization under the Role-Goal-Process-Service standard. Agent roles are encoded as

$G$1

and agent-group goals as

$G$2

thereby treating agent and group descriptions, prompts, structured I/O, and logic or membership as registration-time invocation objects (Zhu et al., 13 May 2025).

Taken together, these formalisms define different invocation units—capabilities, conversations, sub-agents, or registered agent services. A plausible implication is that the field has converged on the need for explicit invocation objects and boundary conditions, but not yet on a single canonical semantic model.

3. Invocation protocols, semantic layers, and delegation

At the protocol layer, recent work distinguishes transport standards from invocation semantics. A benchmark comparing tool integration via MCP, inter-agent delegation via A2A, and a hybrid router describes MCP as agent-to-tool invocation over stdio or HTTP with tool discovery and argument schemas inside a single LLM context, whereas A2A is agent-to-agent delegation over HTTP JSON-RPC with capability discovery through an Agent Card at /.well-known/agent.json. In that study, MCP is faster on simple and medium queries, A2A is faster on complex queries, and the hybrid architecture tracks the per-tier winner; on complex queries, MCP consumes 34,959 tokens, A2A 11,318 tokens, and A2A costs 39% less than MCP (Dobrovolskyi, 24 Mar 2026).

A stricter semantic application layer is proposed by the Agent-First Tool API paradigm, which decomposes invocation into six verbs—search, resolve, preview, execute, verify, recover—and standardizes responses through a Normalized Tool Contract carrying ok, result_refs, requires_confirmation, confidence, evidence, and next_actions. The same work couples this semantic protocol to a dual-layer governance pipeline with static capability policies and dynamic risk escalation. In a production multi-tenant SaaS platform with 85 registered tools across 6 business domains, the paper reports 88% end-to-end task success rate versus 64% for optimized CRUD baselines, a 72.7% reduction in required human interventions, and 5.8x improvement in autonomous error recovery (Pan, 11 May 2026).

Identity-bound delegation is addressed by AIP, which introduces Invocation-Bound Capability Tokens (IBCTs) in compact JWT form for single-hop calls and Biscuit-based chained form for multi-hop delegation. AIP binds identity, attenuated authorization, delegation depth, context hash, and completion metadata into an append-only token chain. The reported performance is sub-millisecond for compact verification—0.049 ms mean in Rust and 0.189 ms mean in Python—and 2.351 ms total overhead, or 0.086% of total end-to-end latency, in a real multi-agent deployment with Gemini 2.5 Flash. The adversarial evaluation reports 600/600 rejected attacks, including delegation depth violation and audit evasion through empty context (Prakash, 25 Mar 2026).

OpenAgenet/OAN places an additional trust layer before protocol-specific interaction. In this design, agent interconnection requires identity provenance, governance acceptance, discovery authorization, freshness, and signed trust artifacts before any MCP, A2A, or ANP-like exchange begins. Its architecture separates Root, Registrar, Discovery, CDN, Service Agent, and User Agent roles; Discovery returns signed responses for admissible candidates only within authorized capability domains, and trusted invocation uses nonce- and timestamp-bound signed envelopes validated by the Service Agent before business logic proceeds (Xu, 2 Jun 2026).

The combined picture is not that one protocol supplants the others. Rather, transport, delegation, semantic contracts, and trust-governed first contact are being stacked into layered invocation pipelines.

4. Runtime and systems architectures

At the runtime level, Agent Operating Systems reinterpret invocation as a mediated transition from a probabilistic reasoning plane to a deterministic execution boundary. The canonical AOS data/control flow is planner → canonicalization → deterministic validation → policy and risk decision → sandboxed execution → postchecks → audit append. The architecture decomposes responsibilities into an agent lifecycle manager, agent scheduler, context and memory manager, tool and capability registry, policy/trust enforcement, and observability/audit. It also maps invocation control onto concrete Linux and Windows primitives such as cgroups, namespaces, seccomp, LSM/SELinux, eBPF, Job Objects, restricted tokens, AppContainer, and ETW, thereby preserving classical OS mediation of hardware while adding deterministic authorization, least-privilege sandboxes, and decision lineage around agent side effects (Sharma et al., 1 Jun 2026).

AOHP extends this logic to end-user operating systems by treating agents as first-class OS actors inside an AOSP-derived environment. It normalizes invocation through four modes—API, CLI, Structured UI, and rendered GUI—while adding personalized service composition, a native sandbox runtime, virtual displays for parallel background execution, a unified file shortcut plane, and secure information flow based on redaction, a trusted vault, and taint propagation. In the reported comparison against stock Android on 30 real-world mobile tasks, AOHP reaches 75.56% completion rate versus 54.44% for the baseline, with -51.55% token cost, -44.21% duration, and security-policy compliance in the annotated payment-app cases (Zhao et al., 22 Jun 2026).

Middleware and network-oriented variants pursue similar aims at different granularity. SoSAA exposes component services, data channels, and event sources to BDI agents through a standardized adapter with actuators and perceptors, while AaaS-AN models agents and agent groups as vertices in a dynamic Agent Network with HARD, SOFT, and EXT routes, coordinated by a Service Scheduler using an Execution Graph. The latter reports a deployment containing agent groups, RPA workflows, and MCP servers over 100 agent services, and releases a dataset of 10,000 long-horizon multi-agent workflows (Lillis et al., 2014, Zhu et al., 13 May 2025).

Invocation can also become a systems signal for resource management. ScaleSim defines invocation distance as a scalar estimating how soon an agent or shared memory object will next invoke the LLM, and uses it to drive prefetch and eviction decisions for agent-specific GPU-resident state. On simulation benchmarks, the system reports up to 1.73× speedup on AgentSociety, 1.31× on interaction-involved workloads, and 1.74× on hop-based information diffusion, while reducing TTFT by 48–68% versus HiCache at high concurrency (Pan et al., 29 Jan 2026).

These architectures differ in substrate—application runtime, operating system, component framework, or serving system—but they converge on the same runtime principle: probabilistic planning is separated from governed execution by explicit mediation layers.

5. Reliability, governance, and safety

The reliability literature on agent-oriented invocation has shifted from aggregate task success to procedural diagnosis. A diagnostic framework for multi-agent tool invocation defines a 12-category taxonomy as the cross-product of four error types—Not Initialized, Arguments Mismatch, Error, Result Mismatch—and three tool classes—OCR processing, database query, and database update. Across 1,980 deterministic test instances, the study reports that tool initialization failures are the primary bottleneck for smaller models; qwen2.5:14b achieves a 96.6% success rate with 7.3 s latency on RTX A6000, while qwen2.5:32b and GPT-4.1 achieve 100.0% success with zero errors across all categories (Huang et al., 22 Jan 2026).

Governance-oriented evaluation extends beyond reliability into authorization, recovery, portability, upgrade safety, override responsiveness, and auditability. EmbodiedGovBench defines seven governance dimensions—unauthorized capability invocation, runtime drift robustness, recovery success, policy portability, version upgrade safety, human override responsiveness, and audit completeness—and aggregates them into a composite GovScore. In the reported AI2-THOR experiment, a governance-augmented planner reaches GovScore 0.9437, compared with 0.7227, 0.5770, and 0.6357 for three other systems, while also exhibiting the explicit governance–performance trade-off that raw task success can mask (Qin et al., 13 Apr 2026).

AOS makes these measurement targets explicit at the system boundary. It defines Deterministic Enforcement Rate

$G$3

and Audit Completeness

$G$4

and emphasizes deterministic enforcement, auditability, and operator comprehensibility as first-class evaluation criteria. Its threat model includes prompt/context manipulation, tool misuse, privilege escalation, data exfiltration, supply-chain compromise, audit evasion, and stateful compositional attacks, with deny-by-default capabilities, least-privilege sandboxes, controlled egress, posture transitions, and safe failure under policy/audit outage as the corresponding mitigations (Sharma et al., 1 Jun 2026).

A recurring theme is that invocation safety is not reducible to authentication alone. It also requires capability scoping, context policy, risk classification, approval semantics, version awareness, and complete lineage from proposal to postcheck.

6. Empirical landscape and research agenda

Empirical results across the literature are heterogeneous because the invocation unit varies: tool, capability, sub-agent, service, conversation, or memory object. Even so, several systems report substantial gains from making invocation explicit. Z-Space reports 92% tool execution accuracy and a 96.26% reduction in token consumption relative to full tool-prompt injection. AOrchestra reports a 16.28% relative improvement against the strongest baseline when paired with Gemini-3-Flash across GAIA, SWE-Bench, and Terminal-Bench. SelSkill, which learns a “skill-or-skip” invocation policy, improves task success by 10.9 percentage points and execution precision by 29.1 percentage points on ALFWorld, and by 5.7 and 29.5 percentage points respectively on BFCL (He et al., 23 Nov 2025, Ruan et al., 3 Feb 2026, Chen et al., 30 May 2026).

The open problems are correspondingly broad. The conceptual AI-native software literature identifies capability granularity, interface standardization, security, misuse, policy enforcement, dual-audience design, and evaluation criteria beyond human-centric usability metrics as unresolved. OAN identifies single-root trust domains, privacy-preserving discovery, and multi-root federation as future work. AIP defers fuller revocation flows, post-quantum readiness, and broader formal security analysis. EmbodiedGovBench points to portability, upgrade workflows, and audit integrity as governance primitives that current task-success benchmarks undermeasure (Wang et al., 19 Mar 2026, Xu, 2 Jun 2026, Prakash, 25 Mar 2026, Qin et al., 13 Apr 2026).

A plausible synthesis is that agent-oriented invocation systems are becoming the control plane of AI-native software. Their maturation depends less on scaling model reasoning in isolation than on making invocation objects explicit, enforceable, composable, replayable, and audit-complete across tools, services, operating systems, and open multi-operator networks.