# Three Agent9 Managed Evidence Tools ## Boundary ```text Jira event | v Auto-oncall: authorization, exact ticket, Investibook preflight | v Agent9 Agent Sandbox | +---- clinic evidence tool ----> isolated Tool Sandbox | | | v | internal Clinic connector ----> Clinic API | +---- manus evidence tool ----> isolated Tool Sandbox | | | v | internal Manus connector -----> Manus | +---- wetech evidence tool ---> isolated browser Tool Sandbox | v internal Wetech connector ----> Wetech ``` The Agent Sandbox and every Tool Sandbox are separate. Tool Sandboxes receive no Agent workspace, prompt, chat history, or Skill directory. Agent9 owns Tool execution, concurrency, timeout, scaling, and audit. Clinic, Manus, and Wetech are package-internal provider connectors, not a model-selectable provider abstraction. Agent9 exposes three independent Tool package identities. There is no generic Tool with a model-authored `provider` argument. Each Tool has its own Auth binding, network policy, process, audit stream, and installation lifecycle. ## Decisions - Jira is not an Agent Tool. Auto-oncall already fetches the exact ticket, paginated comments, and attachments before the Agent run and performs the final internal-comment write. This is the row-level authorization boundary. - Investibook remains Auto-oncall preflight/enrichment, not a model-selected Tool. - The Agent can call only the separately installed Clinic, Manus, or Wetech evidence Tool. Provider selection is therefore an installation and routing decision, not a Tool argument. - Clinic uses Agent9 `restricted` network to the exact Clinic host. Its credential is injected only into the Clinic Tool Sandbox. - Manus and Wetech require Agent9 `restricted` network because they use multi-step sessions and, for Wetech, a browser. Their egress must be exact host allowlists, never unrestricted internet. - Network isolation does not authorize data. Package arguments and trusted policy must still bind each call to the provider/account/cluster selected by Auto-oncall's canonical ticket classification. ## Current implementation state - Agent9 supports reviewed multi-file packages, with every file and the normalized manifest covered by the package digest. - The catalog contains exactly three independent package identities: `managed_auto_oncall_clinic`, `managed_auto_oncall_manus`, and `managed_auto_oncall_wetech`. None accepts a `provider` argument. - Agent9 binds secret values to one exact package digest and injects them only into the fresh Tool Sandbox. Secret output, including decoded browser-state cookie/local-storage values, fails closed. - Wetech runs in the browser-capable Agent9 template. Its browser storage state is a Tool secret; the Tool does not mount the Agent Sandbox profile or an operator profile. - The first Wetech package locks provider, ticket, cluster, query ID, and time range to trusted catalog policy before browser startup. - Provider scripts remain inside their Managed Tool packages. They contain no credentials and read only the environment variables injected into the Tool Sandbox by the package's Agent9 Auth binding. - Auto-oncall now owns a separate Manus package. It locks provider, ticket, exact `vida` or `monica` target, operation, and time range before network access. The Agent may author PromQL freely against that bounded target; the Tool is restricted to `query_range` and returns compact sanitized results. - Manus instance addresses are converted into encrypted Tool references. The Agent may pass a returned reference to a later bounded query, but cannot read or edit the underlying address or reuse it for the other target. - Historical read-only validation for `APID-29213` queried `SaaS01` TiDB CPU for `2026-07-21 21:50–22:05 UTC+8` through Agent9/E2B. The exact package returned 56 series with a 22.84-core top-instance peak and left zero running Tool Sandboxes. - The dedicated Auto-oncall Agent has memory, session recall, and knowledge base disabled. It has the six diagnosis/transport Skills installed and pins the exact Clinic v3, Manus v2, and Wetech v2 Managed Tool revisions. Clinic v2 remains registered but uninstalled as a bounded rollback package. - A read-only `ST-2865` replay on 2026-08-05 loaded the Clinic and latency diagnosis Skills, completed two Clinic v3 Managed Tool calls, and used the returned values in its answer. Run `838ec682-db69-4730-82d3-d4936df04fb9` and Agent9 session `sess_d5b46e72cf9943cba6bf80dd285b645a` queried the bounded 60-minute window, returned 261 series, and found a `MemAvailable/Total` peak of about 78.64%. A second TiKV-specific query returned no series and was kept unverified rather than interpreted as zero. Evidence acquisition was `complete` and provider capability was verified. No Jira, database, evaluation, or Feishu write was requested. - Agent9 operation success alone is not treated as provider success. A Managed Tool result with `details.status=error` is mapped to a failed Tool item. The Clinic Tool exposes a safe HTTP 422 query-rejection signal so the Agent may correct or simplify its freely authored PromQL once without changing the authorized identifiers or time window. ## Remaining before provider cutover - Define deployment ownership and rotation for the Wetech credentials and browser storage-state Secret, and for the Manus provider credentials and opaque-reference key. - Deliver ticket-derived policy to each Tool call through trusted Agent9 runtime context. It must not come from model-controlled Tool arguments. - Replace the current per-installation static test policy with trusted, per-request policy delivery before allowing arbitrary ticket replays. The model must never supply or widen this policy. - Live-validate Manus `vida` and `monica` and Wetech through representative read-only replays before enabling provider cutover. - Keep the deployment passive until the remaining providers and the trusted policy handoff have rollout evidence. Do not remove the current production provider path yet.