The six fleet capabilities behind the feature cards
These are implemented as dashboard workflows, API endpoints, MCP tools, and persistence models. The feature-page labels are capability names; production execution goes through the governed surfaces below.
Agent tagging
Group agents by environment, owner, role, or risk class. Tags become the targeting layer for fleet runs, ACL policy, and operator search.
- •Dashboard agent metadata and address-book tags
- •API: GET /v1/tags, POST /v1/tags, GET /v1/tags/{tag}/agents
- •Store: tucdesk_agent_tags with team_id, agent_id, tag, created_at
- •Policy: tags are resolved under the signed team_id before execution
POST /v1/tags
{
"agent_id": "db-01.prod",
"tag": "production-db"
}█Fleet run
Run an approved command across a target set and persist per-agent output, exit code, duration, and audit correlation.
- •Dashboard fleet workflows
- •API: POST /v1/fleet/run, GET /v1/fleet/runs
- •Store: tucdesk_fleet_runs with plan_id and access_decision_id
- •Audit: one access decision per targeted agent
POST /v1/fleet/run
{
"tag": "production-db",
"executable": "systemctl",
"args": ["status", "postgres"],
"parallel": true
}█ACL policy
Allow or deny access by agent, team, tag, session type, and time window before a session or command is created.
- •Dashboard Settings policy editor
- •API: GET /v1/acl, PUT /v1/acl
- •Store: tucdesk_acl_config and policy rule evaluation
- •Audit: policy_result and denial reason are recorded
PUT /v1/acl
{
"mode": "allowlist",
"allowlist": ["prod"],
"defaults": {
"command_execution": "manual_approval"
}
}█Session recording
Capture terminal sessions in asciinema-compatible format with signed audit context and tenant-prefixed object paths.
- •Dashboard Recordings screen
- •API: GET /v1/sessions/{session_id}/recording
- •MCP: get_recording
- •Storage: recordings/{team_id}/{session_id}/session.cast
GET /v1/sessions/{session_id}/recording
asciinema play session.cast█Command approval gate
High-risk command plans pause for human confirmation. The approved actor, command, scope, and expiry are bound to the approval token.
- •Dashboard and mobile approval surfaces
- •API: approval records consumed by fleet, command, and skill execution
- •MCP: execute_skill and execute_natural_command accept approval_id
- •Audit: approved, denied, and expired decisions are visible
POST /v1/fleet/run
{
"tag": "production-db",
"executable": "systemctl",
"args": ["restart", "postgres"],
"approvalId": "appr_..."
}█Address book
Curate known endpoints, labels, notes, favourites, use counts, and tags for repeated access and faster operator routing.
- •Dashboard Address Book screen
- •API: GET/POST /v1/addressbook and /v1/addressbook/{id}
- •MCP: list_address_book
- •Store: tucdesk_address_book with team_id isolation
POST /v1/addressbook
{
"id": "db-01.prod",
"label": "Primary Postgres",
"tags": ["production-db", "pci"],
"notes": "Owner: platform"
}█Command surface by workflow, scope, and storage
| Workflow | Human surface | API / MCP command | Scope | Persistence |
|---|---|---|---|---|
| Tag agents | Dashboard agent metadata | POST /v1/tags | agents:write | tucdesk_agent_tags |
| Resolve tag target | Fleet picker | GET /v1/tags/{tag}/agents | agents:read | none |
| Run command on fleet | Fleet run workflow | POST /v1/fleet/run | fleet:execute | tucdesk_fleet_runs + audit |
| Review fleet history | Fleet history | GET /v1/fleet/runs | fleet:read | tucdesk_fleet_runs |
| Edit ACL policy | Settings policy editor | PUT /v1/acl | acl:write | tucdesk_acl_config |
| Read recordings | Recordings screen | GET /v1/sessions/{id}/recording / MCP get_recording | recordings:read | object storage + audit |
| List address book | Address Book screen | GET /v1/addressbook / MCP list_address_book | address_book:read | tucdesk_address_book |
| Execute skill | Skills screen or AI client | POST /v1/skills/{id}/execute / MCP execute_skill | skills:execute | skill executions + audit |
How a governed fleet command is built
1. Target resolution
Tags, selected agents, and address-book entries resolve to a team-scoped agent set.
2. Policy evaluation
ACL mode, session type, target tags, and risk tier determine whether execution may proceed.
3. Approval gate
High-risk operations require a single-use human approval token bound to the exact command context.
4. Dispatch + audit
The dispatcher records per-agent output, duration, exit state, access decision, and audit context.
Skills turn repeated commands into governed fleet workflows
A skill is a reusable, versioned command recipe with steps, tags, target filters, policy, concurrency, metrics, and execution history. It helps teams move faster because operators and AI agents reuse a reviewed workflow instead of rebuilding risky commands each time.
- •Repeatable runbooks become versioned command recipes instead of one-off shell history.
- •Target filters let the same skill run against one agent, a tag, or a scoped fleet.
- •Concurrency and policy settings control blast radius before execution starts.
- •HIGH and CRITICAL skills use the same approval gate as direct commands.
- •Execution history captures per-step success rate and average duration for improvement.
- •AI-generated skills remain draft until a human reviews and activates them.
POST /v1/skills
{
"name": "Restart nginx safely",
"description": "Check status, restart, verify health",
"tags": ["prod", "nginx"],
"policy": "fail_fast",
"concurrency": 5,
"steps": [
{
"command": "systemctl status nginx",
"targetFilter": "tag:prod",
"timeoutSec": 20
},
{
"command": "systemctl restart nginx",
"targetFilter": "tag:prod",
"timeoutSec": 60
}
]
}█AI agents reuse skills safely
list_skills
Find reusable command skills by tag or status.
get_skill
Read the full skill definition, steps, policy, and recent executions.
create_skill_from_command
Create a draft skill from proposed command steps.
execute_skill
Execute an active skill through ACL, approval, dispatcher, and audit.
get_skill_execution
Inspect per-step and per-agent execution results.