Enterprise Agent Capability Boundaries
Languages: English · 中文
An enterprise agent is not a large prompt. It is usually a collaboration among multiple owners: the entry layer owns service boundaries, the request layer owns judgment and result contracts, the runtime layer owns action, the workflow layer owns lifecycle, and the state layer owns durable evidence.
Owner Map
| Layer | Owns | Does not own | Agently entrypoint |
|---|---|---|---|
| Gateway / API | Auth, tenant, HTTP/SSE/WebSocket, request validation, routing | Prompt authoring or model decisions | FastAPI Service Exposure |
| AgentExecution | One run's input, goal, output contract, stream, metadata, diagnostics | Long-running workflow lifecycle | Agent Auto-Orchestration |
| Output Control | Fields, types, required checks, validation, retry, instant stream | External capability execution | Output Control |
| Model Response | Reuse text / data / meta / stream from one response | Re-requesting for different views | Model Response |
| Actions | Model-callable capability surface, args schema, call records, result normalization | Long-lived resource lifecycle | Actions Overview |
| MCP | Standard capability supply, discovery, and call protocol | Host-side business orchestration, visibility, redaction, audit | MCP |
| ExecutionEnvironment | Lifecycle for MCP servers, Bash/Python/Node/SQLite, browser, sandbox resources | Deciding the business workflow path | Execution Environment |
| Skills Executor | Discover, select, load, and execute reusable behavior assets | Replacing Actions, TriggerFlow, or sandbox ownership | Skills Executor |
| Dynamic Task | Validate and execute model- or app-submitted DAG data | Replacing stable workflow definitions | Dynamic Task |
| TriggerFlow | Branching, concurrency, events, runtime stream, pause/resume, save/load, close snapshot | Output schema or large long-term memory | TriggerFlow Overview |
| Workspace / Recall | Observations, artifacts, decisions, checkpoints, ContextPack source | Letting the model decide what should be remembered | Workspace |
| Interaction Layer | Product events, SSE/WebSocket, IM gateway, waiting messages, notifications | Workflow control flow or observability storage | Interaction Layer and Active Tasks |
| Scheduler / Worker | Timers, webhooks, queues, proactive tasks, idempotency, task table | Prompt authoring or hidden business loops | Interaction Layer and Active Tasks |
| Observability | RuntimeEvent, Event Center, DevTools, evaluation, debugging | Changing flow control | Observability Overview |
Where MCP Fits
MCP lets capability providers and AI application hosts separate concerns: Server exposes capabilities, Client manages connections, and Host decides how the model may use them.
Enterprise systems still need Host logic:
- End-user identity and tokens often need to pass from the application to the capability side.
- Different roles should see different tools; exposing everything and letting servers reject calls is a poor user and audit experience.
- Sensitive fields should be redacted or aggregated before entering model context.
- Audit needs both the capability-side access log and the Host-side reason for exposing, selecting, and calling that capability.
MCP standardizes supply. Agently Actions, ExecutionEnvironment, TriggerFlow, and Observability help the application put those capabilities into a controlled execution path.
Where Skills Fit
A Skill is a reusable behavior asset. It can include guidance, resource indexes, tool dependencies, script declarations, workflow descriptions, output contracts, and validation rules.
It is not the same as a tool, prompt, workflow, or sandbox:
- A Tool is an atomic call; a Skill can describe a multi-step behavior.
- A Prompt is a text fragment; a Skill is selectable, loadable, and executable behavior.
- A Workflow owns lifecycle; a Skill can map to TriggerFlow or Dynamic Task.
- Scripts and third-party capabilities still enter through Actions / ExecutionEnvironment.
Multi-Role Collaboration
Multi-role collaboration is not a separate lifecycle parallel to TriggerFlow. It is an application topology:
- Role-specific agents handle focused judgments such as risk, facts, editing, or execution.
- Sub-flows isolate each role's process and test boundary.
- Workspace defines shared and isolated evidence/artifact areas.
- The parent TriggerFlow dispatches, waits, aggregates, approves, and delivers.
When documenting multi-agent systems, emphasize role responsibilities, handoff fields, state topology, and aggregate acceptance instead of how many model calls run at once.
Common Boundary Errors
| Error | Consequence | Correction |
|---|---|---|
| Keyword or regex routing for business semantics | The semantic boundary breaks as rules grow | Use a model request with output schema for category, evidence, and dispatch hints |
| Executing raw model output as control flow | Permission, parameter, and audit risks | Structure first; deterministic code consumes the result |
| Treating Actions as workflows | No clear phases, waits, recovery, or concurrency | Use TriggerFlow when lifecycle exists |
| Treating RuntimeEvent as a flow signal | Observation and control flow get mixed | TriggerFlow signals change flow; RuntimeEvent records facts |
| Treating RuntimeEvent as a product UI protocol | Frontend couples to low-level operations | Product UI consumes mapped business events |
| Treating multi-agent as free chat | Hard to test, audit, and aggregate | Use role agents + Sub-Flow + Workspace topology |
| Putting scheduled work inside HTTP handlers | Request lifecycle and proactive tasks get coupled | Scheduler / queue / worker owns triggers; Agently execution owns processing |
| Putting reports or logs into execution state | State grows and recovery becomes fragile | Store Workspace artifacts; keep state compact refs and summaries |
| Making service code the business core | API becomes hard to test and migrate | Routers handle entry and return; agent/flow/service layers own business capability |
Decision Order
- What fields must be delivered to the business system?
- What external capabilities does the model need, and what permission/audit boundary do they have?
- Does execution require a managed environment, sandbox, MCP server, or browser lifecycle?
- Does the workflow need branches, concurrency, waits, recovery, approvals, or process visibility?
- Do multiple specialist roles need to contribute, and how do they hand off results?
- Does a UI, IM, or proactive task system need process updates?
- Which artifacts and evidence must survive across turns?
- How will the team observe, evaluate, and replay production behavior?