AOS Work Agent Runtime System Tools and Action Catalog

1. Scope

This chapter documents the System Tools exposed to agents by the current AOS Work Agent Runtime and the AOS Work business Actions that can be discovered through workbench_action_search and executed through workbench_action_execute.

The two capability layers must be distinguished:

• The Runtime currently provides 10 fixed System Tools.
• AOS Work currently provides 43 business Actions in 8 modules: 22 user-level, 17 administrator-level, and 4 super-administrator-level Actions.
• workbench_action_search returns Action documentation and input Schemas. A search result does not grant execution permission.
• Every call is validated against the current registered Schema and remains subject to the current Run authorization and user permissions.

2. The Runtime's 10 System Tools

3. Common System Tool Boundaries

3.1 Files and Processes

• read, write, edit, and delete operate only on trusted paths under the /workspace Workspace and use Workspace-relative paths. Changes to read-only paths are rejected.
• File edits and deletion use SHA-256 for concurrency protection. If the hash does not match, read the current file and evaluate the change instead of overwriting an unknown newer version.
• A nonzero exit code from exec means the command failed. Inspect stderr, correct the cause, and then decide the next step; do not repeat the same failing command unchanged.
• process accepts only a process ID actually returned by exec; do not guess or construct one.

3.2 Business Actions

• Before every execution, use workbench_action_search to find the specific business Action, then pass the exact fields from that result to workbench_action_execute.
• Business Actions access AOS Work control-plane capabilities such as resource installation, scheduled tasks, session queries, model configuration, and user management. They are not direct database access.
• Action search accepts a query of up to 200 characters. limit defaults to 10 and ranges from 1 to 20. One empty search cannot retrieve the full catalog; search by module or specific function.
• This Runtime does not provide file-upload, network-request, browser, or direct-database tools. Do not describe exec or the file tools as those capabilities.

4. AOS Work Action Module Overview

The risk metadata has these meanings:

• read: a read or query operation. It is not guaranteed to avoid external calls; for example, a model connectivity test calls the provider.
• write: a create or update operation.
• high: a high-risk operation such as deletion, password reset, or third-party invocation.

Risk is metadata, not an automatic approval mechanism. The generic execution entry point does not currently pause for human confirmation solely because risk=high.

5. Resource Discovery and Installation (7 Actions)

Boundaries:

• Use explore.search to answer which resources are available or how many exist. Use explore.list-installed only when the request specifically concerns installed resources.
• exploreItemId is the Explore resource ID, not an installation-record ID.
• Disabling does not uninstall materialized files. Uninstalling starts the resource-cleanup flow.
• Installing a resource and authorizing a third party are separate steps. Installation does not mean third-party credentials are available.

6. Third-party Integration Invocation (1 Action)

For each call:

• The outer AOS Work Action Key is always integration.invoke.
• pluginKey is the resource key or authProviderKey.
• The inner actionKey is the Action key declared by the resource Manifest.
• params contains the business parameters passed to the third-party Action.

The execution flow is: find the user's installed resource → match the resource Action → resolve user credentials as required by that Action → render the HTTP request from the Manifest → call the third party → extract response data.

Current limits and return semantics:

• Available third-party functions depend on the installed resource Manifest. One shared entry point does not mean there is only one third-party business function, and it does not permit arbitrary third-party API calls.
• Authenticated Actions use server-side user credentials. An Action that requires no authentication, or a resource whose authentication type is none, can operate without credentials.
• Although the Schema accepts connectionKey, the current implementation does not use it to select a connection. Do not claim multi-connection switching based on this field.
• The response contains success, requestId, pluginKey, and actionKey; a successful response includes data, while a failure includes error. Check the inner success value.
• The current timeout is 60 seconds and there is no automatic retry. A failed third-party write cannot be assumed to have had no side effects.
• This catalog does not query live user installation data and therefore does not enumerate the dynamic Actions installed for any specific user.

7. Scheduled Tasks (9 Actions)

The common required fields for create and update are name, prompt, workspaceId, aiModelId, scheduleKind, and timezone.

The current RRULE implementation supports minute, hourly, daily, weekly, and monthly schedules with positive integer intervals. A weekly rule can specify one BYDAY; a monthly rule can specify BYMONTHDAY=1..31. Cron, BYHOUR, and multiple weekday values are not supported, and the string does not include an RRULE: prefix.

Boundaries:

• Before creation, use scheduled-task.list-options to obtain workspaces.list[].id and models.list[].value. An implicit Workspace from a standalone session cannot be used.
• scheduled-task.update is a full configuration update. Call scheduled-task.get first and preserve unchanged fields.
• Every trigger creates a new project session. Every run-now creates a new execution, so it must not be repeated automatically merely to confirm success.
• A triggered or queued result does not mean the Run completed. Use the returned runtimeRunId with chat.run.get.
• Pausing or removing a task does not cancel a Run that has already started.
• The taskPurpose parameter for system Memory-maintenance tasks is not exposed.

8. Session and Run Queries (4 Actions)

Boundaries:

• Session search matches titles. Without workspaceId, it includes standalone sessions and sessions across all projects, excluding system Memory-maintenance and deleted sessions.
• createdAtFrom (inclusive) and createdAtTo (exclusive) filter session creation time and support one-sided ranges. For a two-sided range, the start must precede the end. Times must include a time zone such as Z or +08:00; these fields do not filter message time or last activity.
• Page 1 contains the latest messages, ordered chronologically within the page. Increase the page number to read older messages.
• Pagination in chat.run.get applies to timelineItems, ordered from the earliest execution event.
• Obtain the target runId from the session's activeRunId, a message's runId, or a scheduled-run record's runtimeRunId. Do not substitute the scheduled-run record id or database chatRunId.
• chat.run.get returns the persisted product projection and can lag behind live execution. An older Run can have no trace, and the Action does not return unpersisted live updates or hidden reasoning.
• This module is query-only. It registers no Action for creating a session, sending a message, deleting a session, or canceling a Run.

9. AI Model Configuration Management (9 Actions)

Only administrator and super-administrator seats can access this module. It reuses the Admin Console model services.

Configurable values include the display name, icon source or file, model type (chat, embedding, or image), capability codes (the current Schema exposes image), context window, input/cached/output Credits rates, and enabled state. Rates are strings.

This module manages model configurations only. It currently registers no Action for creating providers, managing provider credentials, or assigning models to Roles. admin.model.list-role-options only reads candidate options.

10. User and Temporary Credits Management (8 Actions)

Only administrator and super-administrator seats can access this module. Existing user services continue to enforce restrictions for the target user.

Boundaries:

• User update does not change the login name or password. Omitted optional fields remain unchanged.
• credits is a positive numeric string. scope supports period, daily, and both.
• This module manages temporary grants; it does not provide plan management, billing management, or arbitrary Credits configuration.
• There is currently no standalone admin.user.get or user enable/disable Action.

11. Project Creation (1 Action)

Projects are created only for the calling user. name allows up to 100 characters and must not be empty after trimming; description allows up to 500 characters.

12. Super-administrator Session and Run Queries (4 Actions)

Only super-administrator seats can access this module. An explicit target userId is required.

Boundaries:

• Find users through paginated admin.user.search calls, then query each user separately. No Action returns all messages for all users in one call.
• The target session or Run must belong to the target userId; this field does not change the caller's identity.
• Session creation-time filtering, message pagination, business Run IDs, and persisted traces follow the same rules as user-level session queries.

13. Action Discovery, Execution, and Authorization

The standard call flow is:

1. The agent searches for the specific function with workbench_action_search.
2. Runtime calls the AOS Work internal Action search interface.
3. Search returns the Action documentation and input Schema the caller is allowed to discover.
4. The agent uses the exact actionKey returned by search and builds arguments according to the input Schema.
5. The agent calls workbench_action_execute.
6. AOS Work validates the current registered Schema, Run authorization, and the user's current seat before invoking the business service.
7. The agent checks the execution result and nested business response to confirm whether the Action actually completed.

Search again after a Schema or version change; do not reuse stale parameters. Pagination also differs by module. Resource discovery, administrator model, and user queries usually default to page=1,pageSize=10 with a Schema maximum of 1000. Session and scheduled-task queries usually default to page=1,pageSize=20 with a maximum of 100. Always follow the latest search Schema and business validation. Business IDs are strings.

actionVersion / schemaHash are optional compatibility metadata for older clients; execution uses the current registered Schema. Runtime injects trusted runId and toolExecutionId values, which are not business parameters supplied by the agent. When querying a target Run, arguments.runId is still supplied according to that Action's Schema.

Authorization and identity boundaries:

• The calling Run must exist and be in QUEUED, STREAMING, or WAITING_HUMAN state.
• The Run's persisted request Manifest must authorize the corresponding search or execution Tool.
• User identity is resolved from the Run and cannot be switched by passing an arbitrary user ID. A userId in an administrator Action is the business-operation target only.
• access=user operates only on the calling user's own data. Invoking these Actions as an administrator does not automatically grant access to other users' data.
• access=admin requires an ADMIN or SUPER_ADMIN seat and remains subject to business-layer permission checks.
• access=super_admin requires a SUPER_ADMIN seat and uses an explicit target userId to query that user's sessions, messages, and Runs.
• Discovering an Action, accepting an execution request, or queueing a Run does not establish that the business operation completed.

14. Completion Criteria

• The Runtime's 10 System Tools and AOS Work's 43 business Actions are treated as separate capability layers.
• File edits and deletion use the current SHA-256, and process management uses a real process ID returned by exec.
• Before each business execution, search confirms the exact actionKey, and arguments conform to the current input Schema.
• The current Run state, Tool authorization, user identity, access level, and business permission have been checked.
• A write or high-risk operation is not considered complete merely because it timed out, was queued, or its outer call succeeded.
• Scheduled tasks and Run queries use the correct Workspace, model, runtimeRunId, or runId.
• Resource installation is not confused with third-party authorization, and the shared third-party entry point is not treated as arbitrary API access.
• The current Runtime is not described as providing file-upload, browser, network-request, or direct-database tools.