Skip to main content

Use Verdictan

Agents

An agent represents one application in Verdictan. It holds the configuration and the gateways for that application, and it gives the application an address to call. Verdictan sends each request that arrives at the agent address to one of the agent's connected gateways.

Use one agent for each application and environment. For example, support-assistant-test can use a gateway on your computer, and a production agent can use gateways on your servers with different settings.

The quickstart uses the default Assistant agent. You do not have to create an agent for it.

Create an agent​

  1. Open Agents and select Create agent.

  2. Replace the empty manifest with the name of your application:

    agent:
      name: support-assistant-test
      resource_name: support-assistant-test
      description: Test gateway for the support assistant
  3. Select Create agent.

The agent shows in the list. It cannot receive model requests until it has a configuration, a provider credential, and a connected gateway.

This manifest describes the agent in the Console. It is different from the gateway file policy-config.yaml and from a CLI control manifest.

To connect a new gateway, register it and select this agent during registration.

To connect a gateway that is already registered:

  1. Open the agent and select the Gateways tab.
  2. Select Link gateway.
  3. Select a gateway in the same region. If the gateway already has an agent, the new link replaces that agent.
  4. Save the link.

Then deploy a configuration to the agent, and make sure that the gateway can read its provider credential. A link does not start a stopped gateway.

Use the agent address​

The Overview tab shows the published endpoint of the agent. Copy that hostname and use it with an application token in your client. Do not build the hostname from the agent name.

If the tab shows Not published, link a gateway and deploy the active configuration.

Send one request through the agent address. Your application receives the model response, and the request shows in History when capture is on, or in delivered events.

The agent address forwards requests to your gateway. Keep the gateway running while you use it.

Detail tabs​

TabWhat it shows
OverviewAgent ID, resource name, owner, team, endpoint, configuration, and status
MonitoringAllowed, blocked, escalated, and redacted traffic for a period
ContextSaved Context Fabric data and statistics
GatewaysLinked gateways, with controls to link and unlink them
TagsResource tags for grouping and access policies
AuditChanges to this agent, with a link to each change in Trail

Monitoring counts traffic over a period. To investigate one request, use its request ID in the related event or History entry.

Edit or delete an agent​

Select Edit to change the manifest. A change to the configuration or the gateways changes the behavior of the application that uses the agent.

Before you delete an agent:

  1. Stop the traffic of the application.
  2. Find application tokens, budgets, automation, and control manifests that refer to the agent.
  3. Keep the audit evidence that you need.

Then delete the agent and find the operation in Trail. Bulk deletion does not delete the default agent.

Before production use, examine the owner, the access rules, and the deployed configuration. Then send a model request through the agent address. A healthy gateway process alone does not prove that requests complete.

Use the CLI​

With a signed-in CLI profile, list your agents and get the details of one:

verdictan agent list
verdictan agent get --agent-id <agent-id>

verdictan agent also creates, updates, and deletes agents, and links gateways.

Next steps​