Agently 4.1.4.8 - AI Application Runtime Framework

Build AI service backends with structured outputs, observable Actions, runtime Skills, MCP capabilities, process streams, and recoverable workflows.

English | 中文介绍

Docs · Quickstart · Why Agently · Capabilities · Architecture · Ecosystem

Who This README Is For

Agently is for teams moving from "the model can do it once" to "the application must do it reliably":

• product engineers building assistants, internal copilots, knowledge tools, operation workflows, or AI-backed APIs
• platform teams that need clear extension points for model providers, tools, MCP servers, sandboxes, workflows, and observability
• technical leads comparing AI frameworks for maintainability, explicit control, debuggability, and production handoff
• coding-agent users who want a framework whose recommended patterns can be encoded as reusable project guidance

The main design question is simple: how do you keep model behavior useful while still giving application code stable contracts, observable execution, and restart-safe workflow boundaries?

Agently 4.1.4.8 makes one-run Agent composition easier to discover and verify: Actions and Skills preserve AgentExecution fluent typing, built-in Execution, effort, strategy, Action protocol, and concurrency choices appear in IDEs, and stable interaction, review, final validation, and artifact delivery APIs now have complete examples. It also adds accepted retry-stream replay, fail-closed model aliases, execution-scoped Skills, programmatic Action calling, and clearer concurrent debug output. Read the 4.1.4.8 Release Notes, 4.1.4.7 Release Notes, 4.1.4.6 Release Notes, 4.1.4.5 Release Notes, 4.1.4.4 Release Notes, 4.1.4.3 Release Notes, and 4.1.4 Release Notes for the current release and upgrade path.

Why Agently

Many AI frameworks are strong at exploration or at assembling broad integration stacks. Agently is optimized for the engineering layer that makes model applications survive model changes, output drift, streaming UX, action execution, workflow signals, and service boundaries.

Agently is a good fit when you care about:

• AI services should be runtime executions, not prompt glue - AgentExecution owns one run's prompt, strategy, Actions, Skill bindings, process stream, TaskContext evidence, and result views across direct, flat, and TaskBoard strategies. Read 4.1.4.8 Release Notes, 4.1.4 Release Notes, and Agent Auto Orchestration examples.
• Model switching should not rewrite business logic - Agently normalizes provider setup, prompt slots, response parsing, action execution, and response reading into one request/runtime contract. Read Model Setup, Models Overview, and Requests Overview.
• Structured output should be a framework guarantee, not only a provider feature - .output(...) schemas, required field extraction, parser feedback, retries, ensure_keys, ensure_all_keys, and validation handlers work together inside Agently. Read Schema as Prompt, Output Control, and examples in examples/basic/.
• Streaming should expose structure before the final token - instant mode lets consumers react to structured fields while the model is still streaming, which is useful for UI updates, SSE routes, and workflow signals. Read Model Response, FastAPI Service Exposure, and examples/fastapi/.
• Actions should be observable and model-portable - local functions, built-in actions, MCP servers, shell/Python/Node/SQLite/TaskWorkspace helpers, and custom executors produce structured records and can share one Action Runtime. Read Action Runtime, MCP, and examples/action_runtime/.
• Skills should be immutable guidance, not a hidden execution route - SkillLibrary owns installed revisions, AgentExecution owns selection and exact-revision binding, and TaskContext owns disclosure. Agently.skills_executor remains management/context compatibility only. Read Skills and examples/skills_executor/.
• Execution dependencies should have lifecycle owners - Execution Resource providers manage reusable resources such as MCP processes, browser sessions, shell/Python/Node runtimes, SQLite handles, and sandboxes. Built-in gVisor, Seatbelt, and Landlock candidates stay inactive until selected and probe their external mechanism on demand. Read Execution Resource and examples/execution_resource/.
• Generated plans should become validated task graphs - Dynamic Task turns model-generated or app-generated DAG data into validated, observable task execution through Agently.create_dynamic_task(...). Read Dynamic Task and examples/dynamic_task/.
• Workflows should be signal-driven, not just graph-shaped - TriggerFlow supports events, fan-out, runtime streams, pause/resume, save/load, sub-flows, and close snapshots; instant structured output can become workflow input without waiting for the whole response. Read TriggerFlow Overview, Events and Streams, and examples/trigger_flow/.
• Common model-app patterns should be composable - router, To-Do/dependency execution, planning, reflection, evaluator/reviser, and multi-agent collaboration can be built from the same request/action/signal primitives. Read Playbooks, TriggerFlow Model Integration, and examples/step_by_step/.
• Services should keep clean project boundaries - async APIs, FastAPI helpers, settings files, prompt files, DevTools observation, and companion coding-agent skills fit non-trivial projects. Read Project Framework, FastAPI Service Exposure, and Observability.

Current framework version: 4.1.4.8.

Python: >=3.10.

Framework Positioning

The point is not that other frameworks are wrong. They choose different centers of gravity.