Architecture Evolution Target

Languages: English · 中文

Agently's current evolution is not about adding another agent label. The goal is to connect model requests, external capabilities, durable evidence, workflow lifecycle, and observation into one support chain.

Why This Is More Than Wrapping Model APIs

Once a model enters a software system, it is not a normal function and not just a longer prompt. A better engineering frame is: the model is a partially unpredictable computation unit that can be constrained. It understands natural-language goals, makes semantic judgments, generates plans, and calls capabilities; the surrounding system must add contracts, state, permissions, workflow, and validation.

Layer	Common old shape	New requirement in AI agent systems	Agently capability
Interaction	Forms, fixed params, limited message formats	Users express goals naturally; the entrypoint clarifies intent, asks for missing info, shows progress	AgentExecution, instant stream, FastAPIHelper, interaction playbook
System behavior	Hard-coded functions and if / else	Runtime judgment, step planning, tool selection, observation-based continuation, wait/retry/stop	Output Control, Actions, TriggerFlow, Dynamic Task
Data	Business tables, logs, Session history	Long tasks need evidence, artifacts, decisions, checkpoints, and goal-budgeted recall	Workspace, Recall, ContextPack, RuntimeEvent

Agently's center is the software structure around model behavior: contractual input/output, controlled external action, recoverable workflow lifecycle, traceable state/evidence, and observable runtime facts.

Main Chain

Foundation capabilities
  Model request / output control / Actions / ExecutionEnvironment
  Workspace / Recall / Exchange-Policy / RuntimeEvent
    -> TriggerFlow execution lifecycle
    -> BasicFlow / SignalNet / TaskDAG / AdaptiveLoop / BootstrapLoop
    -> AgentExecution / SkillsExecution / DynamicTask

For application developers, read it this way:

1. Use agent.define(...) for reusable agent behavior.
2. Each .input(...), .goal(...), and .output(...) creates an isolated AgentExecution draft.
3. AgentExecutionResult reads data, text, metadata, stream, status, and diagnostics.
4. Use Actions for external capabilities; ExecutionEnvironment for managed dependencies.
5. Use Workspace / Recall for durable evidence and context reconstruction.
6. Use TriggerFlow when workflow lifecycle needs to be explicit.
7. Use TaskDAG / Dynamic Task when the task graph itself is submitted as input.

Emphasize These Capabilities

Capability	Where it belongs in public docs
AgentExecution / AgentExecutionResult	The recommended owner and result facade for one agent run
agent.define(...)	Reusable definition entrypoint; separate shared config from one-run input
Output Control / Model Response	Stable contract before model results enter business systems
Actions / ExecutionEnvironment	Model-callable capabilities and managed dependency lifecycle
Workspace / Recall / ContextPack	Multi-turn evidence, artifacts, decisions, checkpoints, context reconstruction
TriggerFlow	Branching, concurrency, waiting, recovery, stream, save/load lifecycle
RuntimeEvent / EventCenter / DevTools	Runtime facts, diagnostics, observation, service debugging

These should appear early in the homepage, docs home, capability map, and core tutorials.

De-Emphasize These as Main Entrypoints

Capability or term	Correct position
AgentTask / AgentTaskLoop	Bounded long-task strategy behind AgentExecution, not a second public lifecycle
Dynamic Task	TaskDAG convenience facade; only when the task graph is input
Skills Executor	Guidance, resource, and capability-package selection layer; does not reimplement Actions, ExecutionEnvironment, or TriggerFlow
runtime_resources / runtime stream	API names can remain; architecture language should prefer execution-local resources / execution stream
AgentTurn, task_step, .end(), set_result(), old tools	Migration and compatibility material, not the new-user path

De-emphasizing does not mean hiding. It means not presenting these as the first step for ordinary projects.

Pick the First Step

Problem	Start here
Model call not running yet	Quickstart
Output is unstable	Output Control
Shared agent config is mixed with one-run input	Agent Auto-Orchestration
The model needs external capabilities	Actions Overview
Multi-turn work needs evidence and context	Workspace
Application owns a fixed workflow topology	TriggerFlow Overview
The task graph comes from a model or business system	Dynamic Task

Common Mistakes

• Designing TriggerFlow before the output contract is stable.
• Treating Dynamic Task as a TriggerFlow alias.
• Treating Skills Executor as an independent runtime system.
• Treating AgentTask as the default public handle for new projects.
• Treating RuntimeEvent as control flow. TriggerFlow signals change flow; RuntimeEvent records facts.

Next

• Capability Map
• Extension Boundaries
• Glossary