Manowar has two execution paths: an agent turn and a workflow run. Both paths use the same internal inference gateway and telemetry, but they make different control-plane choices. In both paths, registered agents remain first-class runtime objects. A workflow can delegate to another agent, but the target is still a wallet-addressed agent with its own card model, tools, memory scope, and creator identity. Direct model calls useDocumentation Index
Fetch the complete documentation index at: https://docs.compose.market/llms.txt
Use this file to discover all available pages before exploring further.
models_call; they are useful tools, not swarm participants.
Agent Turn
The runtime injects a dynamic system block per turn. It includes identity, optional persona text, compact memory, session context, and one capability sentence. The cached agent config is not mutated; per-request session data flows throughAsyncLocalStorage in agent/context.ts.
Workflow Run
Workflow execution lives underruntime/src/manowar/workflow. The orchestrator loads a workflow card, builds a coordination context, asks TaskPlanner for a structured plan, delegates each step to registered agents, reflects on outputs, and optionally synthesizes a final answer.
High-risk workflow steps require approval when the task text includes operations such as transfers, swaps, approvals, deletion, webhooks, or other write-like actions. The check is implemented in workflow/orchestrator.ts.
Runtime Stops
The agent loop has hard stop conditions:| Stop guard | Default | Env override |
|---|---|---|
| Wall time per turn | 4 minutes | COMPOSE_AGENT_MAX_WALL_MS_PER_TURN |
| Consecutive failed tool batches | 4 | COMPOSE_AGENT_MAX_TOOL_FAILURES_IN_ROW |
| Tool batches per turn | 50 | COMPOSE_AGENT_MAX_TOOL_BATCHES_PER_TURN |
| Managed subagent depth | 3 | fixed in framework.ts |
run:{agentWallet}:{runId} or fall back to thread:{agentWallet}:{threadId}.