Agently 4.1.4.7 is an AI application runtime framework, positioned as a "GenAI application development framework". It is aimed at product engineering, platform teams, technical leads, and coding agent users who are moving from "the model can run successfully once" to "the application must run reliably". The core design question is: how to provide application code with stable contracts, observable execution, and restart-safe workflow boundaries while keeping model behavior useful.
Main capabilities
-
Structured requests: Prompts are composed of named slots, making application intent, constraints, context, and output contracts reviewable. get_result() is used so that the same model call can be inspected in multiple ways; AgentExecutionResult's get_data() returns business results across direct, flat, and TaskBoard strategies, get_full_data() is only used when the complete routing/task envelope is needed, and get_text() is the final text view intended for users.
-
Contract-first output control: Fixed required leaf nodes are written directly in the third tuple item of .output(...); ensure_keys= is used for conditional or runtime-dependent paths; .validate(...) or validate_handler= is used for value-level business rules; ensure_all_keys=True is used to require the entire schema to be present. YAML and JSON prompt files can carry the same contract via $ensure: true, making it easier to review the prompt and response shape outside Python code.
-
Structured streaming output: instant events let UIs, services, or downstream consumers react whenever each structured field changes, suitable for dashboards, chat UIs, SSE responses, and workflows. instant updates should be treated as provisional values, and final validation must be completed before irreversible side effects or business decisions.
-
Actions and tool use: Actions are capabilities the model can call, and new code should start with @agent.action_func and agent.use_actions(...). Common capability helper functions and built-in action packages are provided; MCP servers are used via agent.use_mcp(...); via agent.register_action(..., executor=, execution_resources=[...]) to build custom backends with explicitly managed resources. Instruction-intensive actions keep context compact through execution summaries and artifact references, and applications can explicitly read raw artifacts on demand.
-
Runtime Skills: Skills are reusable task guidance packages. SkillLibrary holds immutable installed revisions, AgentExecution is responsible for selection and binding to exact revisions, and TaskContext is responsible for progressive disclosure. agent.use_skills(...) is the regular candidate binding interface, and agent.require_skills(...) binds known exact revisions. Agently.skills_executor is a thin compatibility layer for installation, inspection, and context projection; in 4.1.4.7, its legacy TaskDAG skill resolver is not yet an executor-ready integration and requires a host adapter from a real TaskDAGContext. Skill capability requirements themselves do not authorize side effects; host code must explicitly mount the required Actions, MCP services, or ExecutionResource providers and apply policies; unavailable, ambiguous, low-confidence, or policy-rejected capabilities fail closed with diagnostics.
-
TriggerFlow orchestration: Agently's workflow layer, supporting explicit stages, branching, fan-out, event-driven input, runtime streams, pause/resume, persistence, and restart-safe execution. close() / async_close() are the canonical completion paths in the 4.1 series, and the close snapshot is the persistent result contract. It is suitable for services, Workers, Webhooks, human review, or SSE/WebSocket routing.
-
Dynamic Task: DAG data used for model generation or application submission, with TaskDAG responsible for planning, validation, resolution, and execution. TaskDAGExecutor.async_run(...) by default compiles the validated DAG directly onto the TriggerFlow foundation; Blocks compilation is an explicit optional path. Do not compile unvalidated runtime plan data directly into new TriggerFlow definitions.
-
Session memory: When the problem is still a single conversation thread rather than a complete workflow, Session maintains bounded multi-turn state; long-running, event-waiting, fan-out, or humanapproval should place TriggerFlow above the request layer.
Usage
Using DeepSeek or other OpenAI-compatible hosted endpoints is supported; change the provider settings when using local Ollama; use Model Pool when the same application needs multiple models, activate_model(...) changes the default model key for subsequent Agent requests, and agent.create_request(model_key="support-chat") performs a one-time override. For file-based settings, prefer file-backed settings. For authentication and installation details, please refer to the official documentation and Quickstart.
Framework positioning and limitations
Use Agently when an application needs an AI execution foundation; when a product has only one or two simple prompts, you can call the SDK directly; use a dedicated multi-agent framework when natural-language agent collaboration is the main product primitive. Compared with LangChain's integration-first style, Agently emphasizes a unified request contract, reducing the impact of changing models or providers on the shape of downstream business logic. Compared with relying only on a provider's native structured output, Agently owns schema-as-prompt, required field extraction, parser feedback, retries, and validation handlers itself. Compared with graph-only orchestration, the core of TriggerFlow is event/signal-driven, and the instant response mode can expose structured fields while the model is still streaming output. Multi-agent collaboration in Agently is a scenario that can be built on top of requests, Actions, TriggerFlow signals, subflows, Sessions, and runtime resources.
The current version 4.1.4.7 requires Agently-Stage 0.3.8, adds built-in inactive gVisor/Seatbelt/Landlock code execution candidates without adding third-party Python dependencies, and improves inference and validation diagnostics.
