AgentDispatcher

See who uses AI, control what agents can access, and act when needed.

AgentDispatcher brings application LLM calls, scheduled workloads and supported coding-account usage into one browser dashboard. Compare applications, people, providers and models; inspect reported tokens; and track LLM spending against a workspace budget. The dashboard works on desktop and mobile.

What you can monitor

Workload	How it connects	What you see
Applications and scheduled LLM calls	Send supported requests through the Dispatcher gateway using a separate Dispatcher key per app	Requests, provider/model, reported input/output, cache and reasoning tokens, and calculated costs
Background jobs and other APIs	Add the Python SDK to report job events and API usage	Job runs, heartbeats, missing-job alerts, configured API prices and quotas
Coding-tool accounts	Install the collector on each participating device	Supported accounts' available usage, balances, limits and reset times

Gateway-routed LLM calls do not need an additional monitoring SDK. Your existing coding tools stay in use; the collector reads supported local account information. CLI account snapshots are shown separately from individual API request costs.

Start with one application

Follow the quick start for copyable SDK and YAML examples, optional feature labels, CLI setup and a first PII masking test.

1. In Settings → LLM providers, configure a provider and its available models.
2. In Applications → Application LLM calls, create a connection. Copy its gateway URL and Dispatcher key—this is not the provider's API key.
3. Configure your compatible LLM client to use that URL and key. Keep the application's model aligned with a configured gateway model.
4. Send an interactive request and a scheduled request, then check their attribution, tokens and estimated cost in Overview.

Use a separate connection for each application or environment. Send a user identifier with requests when you need per-user reporting; a shared application key cannot identify the individual person automatically. OpenAI-compatible clients and the native Anthropic SDK can use the same /llm base URL. Existing OpenAI /llm/v1 configurations continue to work. Grok, Gemini and DeepSeek work through an OpenAI-compatible client with a configured model; their native SDK protocols are not all exposed by the gateway.

Separate scheduled work from user queries

The connection key identifies the application. Add one optional feature label to separate its work, such as scheduler.classify and analysis.summary. You do not need to repeat the application name or add project or api_id.

Add this keyword inside an existing OpenAI-compatible call:

extra_body={"metadata": {"dispatcher_context": {"feature": "scheduler.classify"}}},

Native Anthropic calls use litellm_metadata in place of metadata. Your shared LLM helper can read the value from DISPATCHER_FEATURE or YAML; setting an environment variable alone does not send it. See the feature and YAML examples.

In Overview → Application usage, use Group by on the left of the charts. Select one or more dimensions, such as Application + Feature; both charts update immediately. When labels are present, the initial view uses Application + Feature. Expand Recent activity to see the Feature column and open Details for an aligned request dialog. Calls without a label remain attributed to the application. Labels cannot be inferred for historical requests. Optional user/session identifiers support finer breakdowns.

Coding-account usage

Create a device connection under Applications → CLI account usage, then download its configuration and OS installer. One collector and sync key handle multiple supported tools on that device. In Collector Tools, enable Codex, Claude Code or another supported reader, then start collection. After installing a new CLI, Refresh tools and enable its reader; readers are not automatically enabled.

The web Device tools section shows each device's latest reported tool status. Refresh status reads the latest report; change enablement in the collector itself. Upgrade older collectors to 0.3.2 for tool inventory. Account snapshots are not a complete session/request ledger or a record of messages. See the installation steps and macOS security note.

Protect sensitive input per application

Protection is optional. An installation administrator first configures Presidio for detection/masking and Open Policy Agent (OPA) for policy decisions. GLiNER is an optional recognizer. Installing Dispatcher alone does not start these services.

1. Open Data protection, or Applications → Manage data protection.
2. Select the application/environment, expand Protection services and select Check services.
3. Add rules, for example EMAIL_ADDRESS → Mask and CREDIT_CARD → Block.
4. Use Test draft policy with synthetic text. Preview does not call an LLM or enable scanning.
5. Select Enable data protection and Save policy.

For Contact alice@example.com, an email mask forwards Contact <EMAIL_ADDRESS>. Block stops the request; Observe sends the original text unchanged. All keys for the selected application/environment share the policy. Callers cannot disable it via metadata.

The first version checks supported gateway input text, including system text and streaming requests. It does not inspect model responses, direct provider calls or collector account snapshots. Protected applications reject images/files, tool calls/definitions, embeddings and server-stored conversation context. Detection-service failures also block protected calls. Test representative data: detection cannot guarantee every secret is found.

Decision history records application, action, policy revision and entity types/counts. It does not store prompts or matched sensitive values. Use individual CLI session telemetry when supported for session metrics; the account collector alone does not provide transcripts.

One place to review and manage usage

• Filter by application/device, provider, model and person with searchable multi-selects.
• Compare request share and time trends over 24 hours, 7 days, 30 days or all history.
• Review reported tokens, known usage cost and current LLM spending versus budget.
• Manage workspace access, provider credentials, application keys and model restrictions.
• Set a gateway-enforced total LLM budget and separate provider spending alerts.
• Expose authorized usage reporting to MCP clients.

Application usage and CLI account usage are separate expandable sections, both open initially. Usage data table and Recent activity start closed below the charts. The table pages through all filtered groups, including those combined as Other groups in the charts. The token strip shows input, output, cache and reasoning together on desktop; reasoning also shows how many LLM requests supplied a count. Zero and Not reported are distinct.

Each chart has its own Requests / Known cost / Reported tokens measure. Use the trend's Compare · right axis to compare another measure: solid lines use the left axis and dashed lines use the right, each with its own scale. Use the corner arrows to expand either chart across the row, then click again to restore both. Measures, currencies, comparison and layout are saved per user/workspace in this browser.

Recent activity supports 20, 50 or 100 rows per page and shows the last 7 days by default. Change the display window or leave days blank for all history within the report filters. This only hides older rows from the list; it does not delete database records or change chart totals. Preferences are saved per user/workspace in that browser.

The header shows each configured provider’s estimated remaining balance. Set a balance checkpoint using its edit icon; recorded spending after that checkpoint reduces the estimate, which can become negative. This is not an automatic bank or provider-balance sync.

PostgreSQL stores workspace-scoped usage and configuration. Dispatcher integrates maintained open-source engines for gateway execution, collection, detection and policy evaluation; its own integration layer provides application attribution and the shared product experience.

Control an AI agent's access

Use Agents when an agent needs to call models, enterprise tools or another agent. Each task gets an expiring key, an owner and an activity history.

1. Connect a system: in Agents → Setup, add an MCP server, an OpenAPI REST API or an A2A agent. Select its permitted tools and parameters. System credentials stay in the gateway.
2. Create a profile: choose allowed models and tools, a maximum task duration and optional spending and business limits. For example: allow transfers up to 100 per call and 500 per task, to approved beneficiaries.
3. Add an agent: set its name, version, owner, profile, default model and risk level.
4. Start a task: copy its one-time key into your application's secret environment.

OPENAI_BASE_URL=https://your-dispatcher-host/llm
OPENAI_API_KEY=<task key from Agents>
LLM_MODEL=<model allowed by the profile>

import os
from openai import OpenAI

client = OpenAI()
response = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Summarize today's invoices."}],
)

For tools, connect your MCP client to https://your-dispatcher-host/mcp with Authorization: Bearer <task key>. The client sees only permitted tools. No extra monitoring SDK is needed for gateway calls.

Review exceptions and stop work

A call above a business limit stops and appears in Agents → Approvals. Another workspace administrator can approve one exact retry for a limited time. Changed arguments or an expired approval require a new decision.

Activity combines LLM, MCP and A2A calls by task. Review decisions, results, latency, reported costs and simple calls-per-minute alerts. From Tasks, suspend, resume, close or revoke a task. Setup also provides controls for all agents of one definition or owner. These controls block subsequent requests; they cannot undo an action already running in another system.

Connected systems receive signed agent/task identity. The audit trail records lifecycle changes and access decisions, checks for changed records, and can export to a SIEM using OpenTelemetry. Full tool payloads are not retained in the audit trail. Installation administrators configure the signing key and optional SIEM endpoint.

How it fits beside AgentData

AgentData helps applications and AI clients query governed business data. AgentDispatcher monitors LLM/API usage and governs agents' access to models and enterprise tools. They solve different problems and can be used independently.

Share with your team

Download the one-page PDF · Open the shareable HTML overview

For security leaders — AgentDataMCP edition: authorization, application usage visibility and available response controls.

Download the security overview PDF · Open the security overview HTML

For a walkthrough, contact BiSkilled.

Availability and measurement

The current release is a testing preview. Validate your applications and device/account combinations before a wider rollout. Costs are calculated estimates, not provider invoices; missing prices or token measurements remain unknown. Collector coverage depends on the supported reader and local account authentication—it does not automatically cover every employee or every CLI. Gateway traffic alone cannot detect a job that never started; missing-job monitoring requires SDK job reporting.

Source availability

The development repository is currently private. After acceptance testing, the planned public release will contain the Apache-2.0 backend, SDK, collectors, integration layer and related documentation. The React dashboard will remain in the private product repository.

An open_sources/ workspace records upstream projects separately from Dispatcher adapters. Developers can reproduce recorded source commits or fetch newer candidates; production upgrades use reviewed versions and compatibility tests. Upstream projects retain their own licenses, copyright and required credits in the distribution’s third-party notices.