Agently AI Application Runtime
A Python runtime for AI backends with structured results, observable actions, and recoverable event-driven workflows.
Per-dimension scores and reasoning
Evidence shows fine-grained permission controls such as workspace access modes (snapshot), execution resource lifecycle management (grant/ensure/materialize/execute/release/close), and diagnostics for timeout and cleanup failures, indicating good least privilege. However, user confirmation mechanisms are only mentioned in docs (e.g., human review) and not clearly in code, so deducted. Data flow transparency is provided via action_logs, artifact_refs, and diagnostics, but not comprehensive. Sensitive data handling is not explicit; API keys are referenced via env vars but no encryption. Dependency security: version ranges are set, but no vulnerability scanning or audit evidence. External effects: framework supports shell/python execution but docs emphasize explicit enablement and policy control, so 2. Rollback is implied in TriggerFlow persistence/snapshots but not explicit. Source attribution: authors listed in pyproject.toml, but no contributor guide or detailed attribution.
Self-consistency: README and code examples align; version numbers slightly differ between README (4.1.4.5) and pyproject.toml (4.1.4.6), but overall consistent. Dependency availability: dependencies listed with version ranges, but no lock file. Failure messages: tests cover timeout, release failure, and provide diagnostic codes, indicating good failure handling.
Audience and scenarios are clear, targeting product engineers, platform teams, etc., with various scenario examples. Capability boundaries: docs distinguish framework vs direct SDK usage, but not all built-in capabilities are listed. Trigger precision: TriggerFlow supports events, condition branches, but trigger conditions not detailed. Environment fit: supports multiple model providers and local Ollama, but no containerization or deployment guides.
Information architecture is clear, with complete documentation structure including quickstart, core capabilities, architecture. Install notes are simple but lack virtual environment or dependency management advice. Naming stability: API names changed across versions (e.g., tool_func to action_func), but docs mention compatibility. Examples and FAQ are rich, but no FAQ section. Known limitations not explicitly listed. License is Apache-2.0, complete. Versioning changelog exists but no CHANGELOG file. Maintenance responsibility: authors listed, but no contribution guide.
Output usability: provides structured output, streaming, but no detailed output format docs. Marginal value: unique features like model switching, structured output, but comparison with other frameworks not quantified. Cost-benefit: no performance benchmarks or resource consumption data.
Claim traceability: README claims have corresponding doc links and examples, but no test coverage. Cross-source corroboration: relies solely on single repository, no external validation. Fact-inference separation: docs distinguish feature descriptions and design intent, but not explicitly marked.
- Version inconsistency: README shows 4.1.4.5 while pyproject.toml shows 4.1.4.6, which may cause confusion.
- Sensitive data handling is not explicit: API keys are only referenced via env vars, no encryption or security recommendations.
- Dependency security lacks vulnerability scanning or audit evidence; consider using lock files.
- User confirmation mechanism is only mentioned in docs, not clearly implemented in code; use with caution.
- Known limitations are not listed, potentially hiding issues.
What does this agent do, and when should you use it?
Agently is a Python AI application runtime framework, currently version 4.1.4.5, for service backends that need reliable outputs, observable execution, and recoverable processes. AgentExecution groups a run’s prompt, strategy, Actions, Skill bindings, process stream, TaskContext, and result views, while ModelRequest handles prompt slots, model invocation, and response parsing. Its output controls combine .output(...) schemas, required-field extraction, parser feedback, retries, and validation; instant mode can expose structured fields during streaming. The Action Runtime supports local functions, MCP servers, and Python, shell, Node, SQLite, and workspace capabilities with execution records. TriggerFlow adds event-driven branching, fan-out, pause/resume, persistence, and close snapshots, while FastAPIHelper exposes agents, requests, and flows through POST, SSE, and WebSocket interfaces.
An application configures a model with Agently.set_settings(...) or Agently.load_settings("yaml_file", "settings.yaml", auto_load_env=True), then creates an agent with Agently.create_agent(). It composes a request through .role(...), .info(...), .instruct(...), .input(...), and .output(...), calls .get_result(), and reads get_data(), get_full_data(), get_text(), or get_meta() from the AgentExecutionResult. For progressive consumers, it iterates result.get_generator(type="instant") to receive structured field paths, deltas, and completed values before final completion. Developers expose local functions using @agent.action_func and agent.use_actions(...), or mount MCP and managed capabilities with agent.use_mcp(...), enable_python(), enable_shell(...), enable_workspace(...), enable_nodejs(), and enable_sqlite(...); action_logs and artifact_refs retain execution evidence. For multi-step work, TriggerFlow.create_execution(), async_start(...), async_emit(...), and async_close() run a flow and produce its close snapshot, while Agently.create_dynamic_task(...) validates and executes DAG data.
- A product engineer building an internal support API who needs to move between DeepSeek and other OpenAI-compatible endpoints while preserving a stable structured response contract for application code.
- A service team building an SSE or WebSocket interface that needs to render structured fields or list items as instant events arrive, before the model response finishes.
- A Python developer whose model must calculate, search, or use controlled runtime capabilities through local Actions, MCP servers, or shell/Python/SQLite helpers with inspectable action logs.
- An operations-platform team handling tickets, webhooks, or human approvals that needs TriggerFlow branches, parallel fan-out, external signals, pause/resume, and saved execution state.
- An application developer accepting model-generated plans as data who needs TaskDAG validation before running a Dynamic Task, rather than compiling unvalidated plan data into a new flow.
What are this agent's strengths and limitations?
- It normalizes provider configuration, prompt slots, response parsing, action execution, and result reading in one request/runtime contract, with documented OpenAI-compatible and Anthropic-native paths.
- Structured-output handling is framework-level rather than only provider-level, combining .output(...), ensure_keys, ensure_all_keys, parser feedback, retries, and validation handlers.
- Instant structured streaming emits field-level events before the final response, supporting SSE, UI updates, and workflow signals.
- The Action Runtime produces structured action logs and artifact references while supporting MCP and lifecycle-managed execution resources.
- TriggerFlow includes event handling, concurrent fan-out, pause/resume, save/load, and close snapshots for service-oriented workflows.
- It requires Python >=3.10, and real model calls require a configured endpoint plus provider credentials or a local Ollama setup.
- The repository advises staying closer to direct SDK calls for products with only one or two simple prompts; AgentExecution, Actions, and TriggerFlow add application structure.
- Instant updates are explicitly provisional, so irreversible side effects and business decisions must wait for final validation.
- Complex services still require host-level controls for in-flight coroutines, TriggerFlow concurrency, model rate/concurrency limits, and thread pools for blocking code.
- The older tool_func/use_tools/use_mcp/use_sandbox family remains compatibility surface; new implementations should move to Actions APIs, creating migration work.
How do you install or deploy this agent?
Python >=3.10 is required. Install with pip install -U agently. For an OpenAI-compatible endpoint, configure its endpoint, model, and credential, for example: Agently.set_settings("OpenAICompatible", {"base_url": "https://api.deepseek.com/v1", "model": "deepseek-chat", "api_key": "${ENV.DEEPSEEK_API_KEY}", "model_type": "chat", "request_options": {"temperature": 0.2}}). The local Ollama example first runs ollama pull qwen2.5:7b, then uses http://127.0.0.1:11434/v1 as base_url, qwen2.5:7b as model, and ollama as api_key.
How do you use this agent?
Start with from agently import Agently; after model configuration, run agent = Agently.create_agent(), then call agent.input("Introduce Python in one sentence.").output({"intro": (str, "one sentence", True)}).get_result() and read the structured result with result.get_data(). For file-backed configuration, call Agently.load_settings("yaml_file", "settings.yaml", auto_load_env=True) and set base_url, api_key, and model under plugins.ModelRequester.OpenAICompatible. Use FastAPIHelper for service exposure. For a recoverable workflow, create a TriggerFlow execution and explicitly call async_close() to receive its close snapshot.
How does this agent compare with similar options?
Against LangChain, Agently emphasizes a uniform request contract, output parsing, validation, and Action Runtime rather than an integration-first center. Against LangGraph, TriggerFlow is signal and event driven, allowing structured streaming events, action results, and external events in one workflow. Against CrewAI and AutoGen, it treats multi-agent collaboration as a buildable pattern over requests, Actions, Session, and TriggerFlow rather than the default root abstraction. For one or two simple prompts, the repository recommends staying closer to direct SDK calls.