Enterprise Agent System Roadmap

Languages: English · 中文

An enterprise agent system is easier to design when the team starts from layers instead of product names. Natural-language input enters at the interaction layer; structured decisions and actions happen in the behavior layer; evidence, artifacts, and checkpoints live in the data layer.

Start with Three Layers

Layer	Business question	Engineering question	Recommended entrypoint
Interaction layer	Users express goals, clarify missing data, and watch progress	The entrypoint must turn ambiguous goals into tasks and expose process events to UI or IM	Agent Auto-Orchestration, Interaction Layer and Active Tasks
System behavior layer	The system judges, plans, calls tools, waits, recovers	Long prompts and `if / else` cannot own every path; contracts, Actions, and lifecycle are needed	Output Control, Actions, TriggerFlow
Data layer	Long tasks contain reports, logs, downloads, evidence, rules, checkpoints	Do not put everything into Session or prompt; store externally and recall by goal and budget	Workspace, Long-Running State

Six Capability Boundaries

Stage	Problem solved	What the business sees	Agently entrypoint
Engineering skeleton	Model request, config, prompt, business code, service entry are mixed	One AI capability can be called from API, script, or UI reliably	Quickstart, Project Framework, FastAPI
Intelligent loop	Model output is text and code does not know the next step	Categories, plans, risks, todos, and replies become consumable fields	Output Control, Ticket Triage Playbook
External action	Tools grow and full exposure causes wrong or unsafe selection	Capabilities have registration, selection, call records, permissions, errors	Actions, MCP, Tool Governance
Complex task	A request needs reusable behavior rules, resources, and execution strategy	Team practices can be selected and reused instead of scattered in prompts	Skills Executor, Dynamic Task
Long-running state	Tasks move across turns, files, and time; context window is too small	Artifacts, evidence, checkpoints, and rules are traceable and recallable	Workspace, Long-Running State
Production governance	After launch, the team must debug, control cost, approve risk, and track quality	Runtime facts, eval results, replay, and update strategy are manageable	Observability, Production Governance

From Model Request to Agent System

Stabilize One Request First

The first milestone is not a workflow graph. It is a request whose output can be checked and reused:

python

result = (
    agent
    .input("Summarize this customer ticket and decide the next step: ...")
    .output({
        "priority": (str, "high / medium / low", True),
        "intent": (str, "problem the user wants solved", True),
        "next_step": (str, "next business action", True),
        "customer_reply": (str, "message to the customer", True),
    })
    .get_result()
)

data = result.get_data()

This gives downstream code stable fields before the system grows.

Turn Judgments into Structured Decisions

Once the request is stable, the agent can return separate fields for:

Pattern	Suitable problem	Deliverable
Classification	Route, priority, risk level	enum/string with evidence
Plan	Next actions, dependencies, approval	structured steps
User reply	Human-facing message	string field
Internal command	Machine-facing instruction	command object consumed by deterministic code

User-facing messages and internal commands should not be the same field.

Add External Action Under Control

Actions let the model call capabilities during a request. The system still controls the visible action surface, argument schema, execution adapter, and call records. If the action depends on MCP, a browser, SQLite, Node.js, or a sandbox, ExecutionEnvironment owns the live resource lifecycle.

Add Workflow Lifecycle Only When Needed

TriggerFlow becomes useful when the task has branches, fan-out, waiting, human approval, runtime stream, save/load, or close snapshots. It should wrap multiple requests/actions/stages; it should not be used to make a single unstable prompt look structured.

Add Workspace for Evidence, Not for Everything

Workspace should hold artifacts, observations, decisions, and checkpoints that need to survive across turns or be recalled later. Execution state should keep compact summaries and refs.

Production Shape

text

Gateway
  auth / tenant / route / request validation / process channel

Agent service
  Agent definition / AgentExecution / output contract / result projection

Capability layer
  Actions / MCP / ExecutionEnvironment / business adapters

Workflow worker
  TriggerFlow / Dynamic Task / pause-resume / runtime stream

State and evidence
  Session / Workspace / checkpoint / business DB refs

Observer and eval
  RuntimeEvent / DevTools / representative cases / release evidence

Enterprise Agent System Roadmap ​

Start with Three Layers ​

Six Capability Boundaries ​

From Model Request to Agent System ​

Stabilize One Request First ​

Turn Judgments into Structured Decisions ​

Add External Action Under Control ​

Add Workflow Lifecycle Only When Needed ​

Add Workspace for Evidence, Not for Everything ​

Production Shape ​

Next Reading ​