agentera/agently-agent-extensions

Agently Agent Extensions

Use this skill when the problem is agent-side extension rather than prompt shape, output contract, or workflow control.

Native-First Rules

• prefer the native Action Runtime, built-in action packages, legacy tool facades, and MCP surfaces before handwritten wrappers
• keep extension choice explicit: Action Runtime, Execution Environment, built-in capability Actions, Agent Components, tools, MCP, FastAPIHelper, auto_func, KeyWaiter, or agently-devtools
• treat Agently.execution_environment as an advanced framework/plugin surface, not the default app-development API
• for application developers, prefer built-in Actions and agent.enable_* component helpers before exposing core manager/provider concepts
• use agent.enable_python(...), agent.enable_shell(...), agent.enable_workspace(...), agent.enable_nodejs(...), and agent.enable_sqlite(...) for common Python, shell, workspace, Node.js, and SQLite access
• treat enable_* helper desc= values as optional extra guidance by default; use desc_mode="override" only when the app intentionally replaces the default capability description
• when changing public helper APIs, use explicit typing for IDE assistance; prefer Literal for finite options such as desc_mode
• use @agent.action_func and agent.use_actions(...) as the primary action APIs; tool_func and use_tool remain compatibility aliases
• use built-in Search/Browse through from agently.builtins.actions import Search, Browse and agent.use_actions(Search(...)) / agent.use_actions(Browse(...)); do not invent enable_search(...) or ActionTools
• keep the permission profile explicit: search-only, local-files-only, network-read, install-capable shell, or trusted broad executor
• use Python sandbox for pure computation or small data shaping; do not use it for imports, filesystem mutation, network access, or dependency installation
• use Bash sandbox or a custom executor when the task needs shell access, package install, or broader command control
• treat MCP, Bash, Python sandbox, Node.js, Docker, SQLite, vector-store, browser, and remote-runner lifecycle as Execution Environment concerns when they need managed handles
• Action executors should declare or consume managed resources instead of hiding lifecycle ownership
• treat agently-devtools as an optional companion package installed from PyPI, not as a required source checkout
• keep observation or evaluation bridge wiring in the app layer through Agently.event_center
• combine with agently-model-response or agently-triggerflow only when the scenario needs those layers
• prefer built-in Browse support with Playwright or PyAutoGUI before writing browser or desktop-driving wrappers from scratch

Anti-Patterns

• do not build a parallel action or tool dispatcher before checking native Action Runtime and MCP support
• do not hide MCP/sandbox/process lifecycle inside a custom ActionExecutor when Agently.execution_environment can own the dependency
• do not recommend core manager/provider APIs to ordinary app developers when a built-in Action or Agent Component is the right surface
• do not create a custom waiter or auto-function shim first
• do not ask users to clone or editable-install DevTools when pip install agently-devtools is the supported public path
• do not build a custom runtime upload bridge before checking ObservationBridge

Read Next

• references/overview.md
• references/devtools.md