AgentNexus Docs

What Tool Gateway does

Tool Gateway lets an AgentNexus-managed runtime ask the AgentNexus backend to perform approved tool work. The runtime gets a deployment-scoped runtime-scoped token, not provider API keys or user OAuth credentials.

The current default read surface includes cited web search, public GitHub repository read and import workflows, and Google Workspace read actions. Higher-risk write actions use separate approval paths.

Read tool boundaries

• Cited web search returns normalized citations and redacted error details.
• Public GitHub read and import workflows can inspect readable repository content with extension and plan limits; they do not execute repository code.
• Google Workspace Sheets read actions return redacted metadata such as source, range, row count, and column count for runtime-facing evidence.
• Managed Browser, Developer Mode, Channel Publish, Runtime Cron, Runtime Skills, and Runtime Memory remain approval-gated or production pilot surfaces.
• Raw shell, raw browser sessions, and sensitive write actions are not ordinary runtime tools.

Runtime flow

1. 1The managed runtime receives Tool Gateway URL and runtime token metadata during deployment.
2. 2The runtime calls the manifest route to discover the tools available for that agent and plan.
3. 3The runtime requests tool execution through AgentNexus, which applies auth, entitlement, scope, and redaction checks.
4. 4The chat surface renders the redacted tool result or direct answer when the result is already sufficient.

Related links

Capability levels

• Read actions can inspect approved Google Calendar, Sheets, and Drive context after OAuth authorization.
• Google Workspace Sheets read actions return readOnly redacted metadata for runtime evidence, including result type, source, range, row count, and column count.
• Calendar, Sheets, and Drive writes require an approval step, plan entitlement, the right OAuth scopes, and audit evidence.
• Gmail send is treated as an Enterprise-reviewed sensitive action, not a default runtime capability.
• Managed runtimes call AgentNexus for approved actions instead of receiving Google credentials.

Approval workflow

1. 1Connect Google Workspace with the minimum scopes needed for the workflow.
2. 2Run read-only checks first to confirm the agent has the right context.
3. 3For a write action, review the proposed target, payload summary, and business reason.
4. 4Approve or reject the action from the dashboard or API surface.
5. 5Review the audit record after execution, including redacted outcome details.

Sheets read evidence

Runtime-facing Sheets evidence should show that a bounded range was inspected without exposing spreadsheet contents. Public and runtime-visible summaries should prefer fields such as `readOnly`, `redacted`, `resultType`, `source`, `range`, row count, and column count.

A fresh runtime still needs an authorized Google Workspace connection before it can perform a live Sheets read. If the account is not connected, describe the route and redaction behavior without claiming a completed live read.

Plan guidance

Starter is appropriate for read-only Google Workspace review workflows. Advanced can request Calendar, Sheets, and Drive write approvals. Enterprise review is required for Gmail send, managed browser sessions, and Developer Mode live shell or browser access.

Related links

What you will create

A first agent should prove one workflow before it tries to cover every support, onboarding, or operations scenario. Start with a narrow job, attach approved knowledge, and test the conversation before choosing a launch channel.

First agent path

1. 1Open the builder and describe the customer or internal workflow the agent should handle.
2. 2Review the generated blueprint for audience, job, knowledge needs, and unsupported-answer behavior.
3. 3Create the agent, attach only approved starter knowledge, and run sandbox tests against real questions.
4. 4Choose widget, API, or managed deployment only after the owner and rollback path are clear.

Continue with

Configuration areas

• Agent name, audience, owner, and business job.
• Instructions, tone, and response boundaries.
• Knowledge source expectations and unsupported-answer behavior.
• Launch channel, review owner, and deployment readiness.

Builder workflow

1. 1Create or open an agent draft.
2. 2Confirm the agent job in one sentence.
3. 3Add the minimum knowledge needed for that job.
4. 4Save the configuration and move into sandbox testing.

Review before launch

Treat the builder output as a product artifact. Confirm the job, source material, escalation path, and allowed actions before the agent becomes part of a customer or teammate workflow.

Supported source types

• Written instructions for short policies or FAQs.
• Public URLs for product and support pages.
• Uploaded documents for approved reference material.

Good launch hygiene

Start with high-confidence material. Add broader sources only after sandbox tests show the agent needs them and the owner understands the maintenance burden.

What to test

• Common happy-path questions for the target workflow.
• Unsupported requests the agent should decline or escalate.
• Knowledge freshness and source coverage.
• Tone, formatting, and handoff clarity.

Testing workflow

1. 1Prepare five to ten realistic prompts from support tickets, onboarding tasks, or internal workflows.
2. 2Run them in the sandbox and record incorrect, unsupported, or vague answers.
3. 3Update knowledge or configuration, then rerun the same prompts.
4. 4Move to launch only when the owner can explain what the agent is ready to handle.

Evidence to keep

Keep the prompt set, expected behavior, and launch decision with the agent owner. This makes later changes easier to review and prevents silent scope drift.

Launch paths

• Widget for customer-facing website experiences.
• API for product or workflow integration.
• Managed deployment when a dedicated AgentC Runtime or Hermes runtime is required.

Before launch

1. 1Confirm the agent owner and intended workflow.
2. 2Review sandbox results and known limitations.
3. 3Choose the smallest launch channel that proves the workflow.
4. 4Confirm the runtime manifest, Tool Gateway URL, and allowed tool surface before production traffic.
5. 5Record rollback or cleanup expectations before enabling production traffic.

Managed runtime evidence

• Use a fresh runtime health check before treating a managed deployment as ready for customer traffic.
• Confirm the manifest shows the expected runtime, model alias, Tool Gateway configuration, and deployment-scoped token boundary.
• Treat runtime-native web search, public GitHub reads, Google Workspace Sheets review, Runtime Cron, Runtime Skills, and Runtime Memory as production pilot surfaces unless the account has a broader written approval.

Choose the interface

• Use the widget when the agent should appear on a website.
• Use API routes when a product or workflow needs authenticated integration.
• Use ancli when operators need repeatable terminal workflows.

CLI smoke command

ancli agents list -o json

Reference links

Authentication

Use authenticated dashboard sessions or approved API credentials. Never place private service keys in browser code or public documentation examples.

What credits cover

Credits represent product usage capacity for agent workflows. The dashboard should show current plan state, included credits, and credit-pack purchase paths where they are available.

Payment surfaces

• Plan subscriptions are handled through the approved billing checkout flow.
• Credit packs can be purchased from the billing surface when the account is eligible.
• Payment completion should be confirmed by signed webhook events before credits are applied.

Available safeguards

• Authenticated dashboard and API workflows.
• Tenant-aware application data access.
• Encrypted storage for user-provided integration secrets.
• Human review before high-risk operational changes.
• Tool Gateway execution so managed runtimes do not receive provider secrets.
• Redacted evidence bundle practices for launch review and demo artifacts.

Enterprise review

Enterprise requirements should be reviewed with the AgentNexus team so available controls, production pilot surfaces, roadmap items, and contractual terms are clear before launch.

Evidence bundle review

Evidence bundles should show what was tested, which capability boundary applied, and whether the result is generally available, approval-gated, or pilot-only.

Use redaction for runtime URLs, account identifiers, browser screenshots, raw tool payloads, customer data, and provider credentials. Public resources should summarize outcomes without exposing private run material.

Review questions

1. 1Which data classes will the agent process?
2. 2Which knowledge sources, integrations, and runtime surfaces are in scope?
3. 3Which capabilities are default read paths, approval-gated actions, or production pilot surfaces?
4. 4Which retention, deletion, and vendor-review requirements apply?
5. 5Which launch evidence should be reviewed before production traffic is enabled?