Capability Map

This is a navigation aid: figure out which layer your problem lives at, then jump there.

Nine Layers

Layer	The question it answers	Where to read
1. One request	Can I get one structured answer from a model?	Quickstart, Requests Overview
2. Stable output	Do I get the fields I expect, every time?	Schema as Prompt, Output Control
3. Response and memory	Can I reuse one response, continue a bounded conversation, or preserve task records across turns?	Model Response, Session Memory, Workspace
4. Actions and execution environments	Should the model call functions, MCP servers, or sandboxed commands with managed execution dependencies?	Actions Overview, Action Runtime, Execution Environment
5. Knowledge and services	Do I need retrieval, HTTP, SSE, or WebSocket exposure?	Knowledge Base, FastAPI Service Exposure
6. Observability and development	Do I need observation events, DevTools, or coding-agent guidance?	Observability Overview, Coding Agents
7. Agent auto-orchestration	Should one Agent turn choose among model response, Actions, Skills, or Dynamic Task candidates?	Agent Auto-Orchestration
8. Dynamic task graphs	Should a model or app submit a DAG that must be validated and executed?	Dynamic Task
9. Orchestration	Branching, concurrency, pause/resume, persistence	TriggerFlow Overview

Each layer assumes the previous ones work. Skipping ahead is the most common reason something goes wrong — for example, jumping into TriggerFlow before a single request returns the right shape.

Picking the right path

Your situation	Where to go
Brand new to Agently	Quickstart
Output is unstable / sometimes missing fields	Schema as Prompt → Output Control
Want field-by-field streaming UX	Async First → Output Control
Need to reuse one response multiple ways	Model Response
Multi-turn chat with bounded history	Session Memory
Multi-turn task needs durable observations, artifacts, decisions, or checkpoints	Workspace
Explicit workflow loop needs durable structured state, record links, checkpoint lookup, and recall	TriggerFlow Overview + Workspace; see examples/workspace/workspace_loop_foundation.py
Need the model to call tools / MCP servers	Action Runtime
Need common Python / shell / workspace / Node.js / SQLite ability	Action Runtime, start with agent.enable_python(...), agent.enable_shell(...), agent.enable_workspace_file_actions(...), agent.enable_nodejs(...), or agent.enable_sqlite(...)
Need web search or page browse	Action Runtime, use from agently.builtins.actions import Search, Browse and agent.use_actions(...)
Need managed MCP/sandbox/process/browser/SQLite lifecycle before execution	Execution Environment, usually for action/plugin authors
Deciding where a new extension belongs	Extension Boundaries
Building a service over agents	FastAPI Service Exposure
Need to inspect observation events	Event Center → DevTools
Need one Agent turn to choose between model response, Actions, Skills, or Dynamic Task	Agent Auto-Orchestration
Model-generated or app-generated DAG that must be validated before execution	Dynamic Task
Multi-stage workflow with branching	TriggerFlow Overview → Patterns
Long-running flow with human approval / interrupt	Pause and Resume
Need to save and resume execution across restarts	Persistence and Blueprint
Migrating from .end() / set_result() / old runtime_data	TriggerFlow Compatibility

Decision shortcuts

• “Do I need TriggerFlow?” — Only when there are explicit stages, branching, concurrency, or wait/resume. A single request with retries does not need TriggerFlow.
• “Dynamic Task or TriggerFlow?” — Use Dynamic Task when the graph is submitted as data and must be planned, validated, pruned, and executed. Use TriggerFlow directly when you own the workflow topology in code.
• “Sync or async?” — Sync for scripts and demos. Async for services, streaming UI, and TriggerFlow. See Async First.
• “Action or tool API?” — New code: Agently.action / agent.use_actions(...), built-in packages from agently.builtins.actions, plus scenario helpers such as agent.enable_python(...), agent.enable_shell(...), and agent.enable_workspace_file_actions(...). Existing tool_func / use_tools / use_mcp / use_sandbox keep working but are positioned as a compatibility surface; see Action Runtime.
• “Agent start or explicit API?” — Use agent.start() for candidate-driven auto-orchestration and agent.create_execution() when the caller needs route diagnostics or process streaming. Use explicit agent.run_skills_task(...) or Agently.create_dynamic_task(...) when the application must force that route.
• “Executor or Execution Environment?” — Executors run one call. Execution Environment prepares reusable or policy-bound dependencies before that call; see Execution Environment.
• “Core API or syntax sugar?” — App developers should start with built-in actions and Agent Component helpers. Core managers and providers are for framework, action, and plugin developers; see Extension Boundaries.
• “Observation event or TriggerFlow event?” — Observation events belong to Event Center. emit / when and runtime stream belong to TriggerFlow Events and Streams.