Skip to main content
Local managed agents provide cloud-style APIs while running on your local infrastructure.

Quick Start

1

Basic Local Agent

2

With Secure Package Installation


How It Works

Local managed agents provide the same APIs as cloud providers while keeping data on your infrastructure.

Security: Sandboxed Package Installation

Local managed agents enforce sandbox-first security for package installation by default. When packages are specified, three resolution paths exist:
  1. Compute Provider (Recommended): Attach compute="docker" to install packages in a sandbox
  2. Host Installation (Development Only): Set host_packages_ok=True for trusted environments
  3. No Packages: Remove packages configuration to avoid installation
Setting host_packages_ok=True installs packages directly on your host system, which can create security risks. Only use this in trusted developer environments where you control the package sources.

Compute Tool Bridging

When a compute provider is attached, four shell-based tools automatically execute inside the compute instance instead of on the host: Bridged tools: execute_command, read_file, write_file, list_files

Tool Name Resolution

LocalManagedAgent resolves the strings in tools=[...] through the same canonical ToolResolver chain used by CLI --tools, YAML agents.yaml, recipes, and plain Agent(tools=[...]). A tool that resolves in one surface now resolves here too. Resolution order (first match wins):
  1. Local tools.py / tools/ folder (requires PRAISONAI_ALLOW_LOCAL_TOOLS=true)
  2. Wrapper ToolRegistry (register_function, register_from_module)
  3. praisonaiagents.tools built-ins (e.g. execute_command, read_file)
  4. praisonai-tools package
  5. Entry-point plugins (praisonai.tool_sources)
When praisonai-code is not installed, the backend falls back to the historical praisonaiagents.tools lookup, so existing configs keep working unchanged. Anthropic-style tool configs ({"type": "agent_toolset_20260401", ...}) and TOOL_ALIAS_MAP normalisation still run before resolution — the resolver only ever sees canonical tool names. Compute-bridge wrapping (execute_command, read_file, write_file, list_files) still runs after resolution regardless of the resolved source, so shell-based tools continue to execute inside the compute instance when one is attached.

Configuration Options

LocalManagedConfig Fields


Session Management

Persistent Sessions

Both agent.start(..., stream=True) and the non-streaming path persist the user prompt, the full assistant response, and token usage to the session store. Resume the session later and the full history is available — streaming does not drop messages.
retrieve_session() always returns all 4 keys (id, status, title, usage) with sensible defaults when no session exists.

Resume Sessions


Multi-turn Conversations


Usage Tracking


Best Practices

Use compute providers like compute="docker" for package installation. Only set host_packages_ok=True in trusted developer environments. Packages require a sandbox by default to prevent security risks.
Save session IDs using save_ids() for resuming conversations. Store IDs in a database or file system for persistence across application restarts.
Only enable tools your agent needs. When using compute providers, shell tools automatically execute in the sandbox for security.
Any tool that resolves via YAML/CLI/Python now resolves for LocalManagedAgent too. Reference your local tools.py function or your plugin tool by name in the tools=[...] list — no re-registration needed. Requires PRAISONAI_ALLOW_LOCAL_TOOLS=true for local tools.py loading.

Managed Agents

Overview of managed agent concepts

Docker Compute

Containerized execution environments

SessionInfo Schema

Unified session schema reference