Agently AI Application Runtime
A Python runtime for AI backends with structured results, observable actions, and recoverable event-driven workflows.
- Source repo
- AgentEra/Agently
- Stars
- ★ 1.7k
- Last updated
- 24d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 63/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API · Claude API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- 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.
- Not a fit if
- Teams whose product is only one or two simple prompts and should stay on direct SDK calls
- Teams whose core product primitive is open-ended multi-agent chat collaboration
- Source review
- 63/100 · Some gaps
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.
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.
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 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.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Agently AI Application Runtime This agent | 63 · Some gaps | Library / SDKFree + model costs | ★ 1.7k | 24d ago | Python | OpenAI API · Claude API |
| Strands Agents | 30 · Major gaps | Library / SDKFree + model costs | ★ 9.1k | today | TypeScript | OpenAI API · Claude API |
| deepx-code | 63 · Some gaps | CLIFree + model costs | ★ 392 | 1mo ago | Go | OpenAI API |
| Honcho Memory Infrastructure | 44 · Major gaps | Library / SDKFreemium | ★ 8k | today | Python | Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
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.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v4.1.4.10 Agently 4.1.4.10
Release notes excerpt
Long-task file Actions could succeed while the selected private file disappeared at terminal cleanup. Observations also lost file references, and implicitly inherited file Actions could bind to the Agent workspace identity instead of the current execution. This patch preserves observed file identities, validates exact file selections, and retains selected deliverables after close, including useful files from blocked runs. ```python execution = ( agent.create_execution("long_task") .input(task) .use_actions(["read_file", "write_file"]) .output({"files": [str], "summary": str}) …View on GitHub ↗ -
v4.1.4.6 Agently 4.1.4.6
Release notes excerpt
--- title: Agently 4.1.4.6 Release Notes description: Standard package version inspection, unified reasoning lifecycle events, and live TriggerFlow sub-flow resources. keywords: Agently, 4.1.4.6, version, reasoning, thinking, DeepSeek, Anthropic, Responses, TriggerFlow --- Agently 4.1.4.6 Release Notes Agently 4.1.4.6 is a focused compatibility patch over 4.1.4.5. It: - exposes the package version through the standard __version__ spelling; - normalizes generated reasoning across OpenAI-compatible Chat Completions, Anthropic-compatible Messages, and Responses adapters; …View on GitHub ↗ -
v4.1.4.5 Agently 4.1.4.5
Release notes excerpt
--- title: Agently 4.1.4.5 Release Notes description: Opt-in long-output continuation and Stage-backed TriggerFlow task lifecycle ownership. keywords: Agently, 4.1.4.5, long output, TriggerFlow, Agently-Stage, settlement --- Agently 4.1.4.5 Release Notes Agently 4.1.4.5 strengthens two runtime boundaries without changing their semantic owners: - AgentExecution can opt into lossless continuation when a direct ModelRequest ends with an observed length or incomplete terminal; - TriggerFlowExecution now uses Agently-Stage as the direct owner of its …View on GitHub ↗