Designing Execution Boundaries for Agent Tools: The PRAXOVELA Runtime

Most current Agent Frameworks let a model invoke tools by generating a function call, which the runtime matches to a function and returns the result. This approach works for prototypes, but when agents modify files, operate enterprise systems, run code, or trigger external side effects, simple tool calling is inadequate.

Enterprises must answer questions such as: Does the agent truly have permission to perform the action? Where does high‑risk code run? How to recover if tool execution crashes midway? How to avoid duplicate payments, submissions, or messages during recovery? Must sensitive context be sent to the cloud? Can each step be reconstructed after the fact?

PRAXOVELA is a governance‑first, locally‑prioritized desktop Agent Runtime that treats governance, isolation, recovery, and audit as foundational capabilities rather than after‑the‑fact add‑ons.

Four‑Step Execution Model

1. Capability Request

The agent requests a capability instead of directly obtaining a tool handle. The request passes through a default‑deny governance gate. A policy plane evaluates the subject, capability, context, and risk, and high‑risk operations may require human approval.

2. Isolation Level Selection

Based on risk, the runtime chooses an isolation level. Ordinary local capabilities run in the host process; untrusted skills, adapters, or model‑generated code are executed inside WASM, containers, or OS sandboxes. Before execution, artifact hashes can be verified to prevent unapproved code from entering the environment.

3. Persistent Effect Recording

Actions and side effects are written to a persistent record. Simple logs can only indicate that “something may have happened” and cannot reliably answer whether an effect was committed. PRAXOVELA uses an Effect Ledger and a Checkpoint Store to save execution state, enabling deterministic recovery from a known point after interruptions.

This mechanism is especially suited to payment, approval, ticketing, and message‑sending scenarios, where blindly restarting from the previous prompt could cause already‑executed external actions to repeat. The Effect Ledger identifies already‑submitted side effects to prevent duplication.

4. Data Locality Preservation

Sensitive context remains on the user’s device or within the enterprise environment by default. Remote model execution or remote runtimes are not the default path; they must be explicitly selected and governed, turning “whether to leave the local environment” into a controllable architectural decision.

The public repository showcases four stable interfaces:

AxisLink – protocol between UI and the Agent layer.

Capability Protocol – contract between Agent and governance layer.

Connector Protocol – interface between Agent/execution layer and enterprise systems.

Sandbox Protocol – interface between execution layer and isolation providers.

Additional local Agent APIs cover Session, Run Center, Workspace, Model, Knowledge, Approval, event streams, and runtime recovery.

Runtime is not only responsible for looping model calls and tools; it must also serve as the carrier of capability boundaries, execution isolation, state recovery, and responsibility recording.

When an agent only generates text, a failure usually means a poor answer. When an agent can manipulate real systems, failure can lead to data leakage, duplicate transactions, permission overrun, or irrecoverable business states.

Therefore, the critical step for bringing agents into enterprises is not to connect more tools, but to first establish a runtime environment that controls how those tools are authorized, executed, isolated, recovered, and audited.

Project repository: https://github.com/axisrobo/praxovela-open