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
-
Open Agents and select Create agent.
-
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 -
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.
Connect a gateway
To connect a new gateway, register it and select this agent during registration.
To connect a gateway that is already registered:
- Open the agent and select the Gateways tab.
- Select Link gateway.
- Select a gateway in the same region. If the gateway already has an agent, the new link replaces that agent.
- 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
| Tab | What it shows |
|---|---|
| Overview | Agent ID, resource name, owner, team, endpoint, configuration, and status |
| Monitoring | Allowed, blocked, escalated, and redacted traffic for a period |
| Context | Saved Context Fabric data and statistics |
| Gateways | Linked gateways, with controls to link and unlink them |
| Tags | Resource tags for grouping and access policies |
| Audit | Changes 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:
- Stop the traffic of the application.
- Find application tokens, budgets, automation, and control manifests that refer to the agent.
- 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
- Gateway Fleet: register and monitor gateways.
- Configurations: deploy a configuration to the agent.