Operations¶

Agent Hub Ops ¶

It’s recommended to use a single project to host the Agent Hub webapp, separate from the project hosting the Enterprise Agents.

Testing should occur on a Design instance. When ready, the project containing Agent Hub should be bundled and pushed to production, along with projects containing agents intended for exposure within Agent Hub. After deployment, the WebApp will have to be reconfigured, i.e. the webapp admin will have to choose connections that are on the automation node and add relevant Enterprise Agents that are on the automation node.

Once on the automation node, the dependencies of Agent Hub can be updated without touching the Agent Hub project. This means that Enterprise Agents follow the classic CI/CD process. Once deployed, the Agent Hub project isn’t meant to be modified in the design node or re-deployed - that would replace the parameters with those from design.

Warning

Deploying an Agent Hub with Sharepoint Online features requires an automation node running Dataiku 14.7.4 or later.

Copying settings with a post-deployment hook ¶

Instead of reconfiguring the webapp by hand after each deployment, a post-deployment hook can copy the webapp admin settings (LLMs, connections, look and feel) from the Agent Hub webapp on the Design node to the deployed webapp on the Automation node. Once set up, every deployment of the project runs the copy.

Connection names are renamed according to the connection remapping of the deployment, so connection remapping must be enabled when deploying. The following settings are never copied and keep the value of the deployed webapp: uploaded images and CSS, the admin uploads managed folder, Guardrails, and the options that forward request headers, client IP and user agent in the agent context.

The hook skips the copy if the deployment failed. It can safely run several times, as nothing is written when the deployed webapp is already up to date. It fails, instead of writing unmapped connection names, when it cannot resolve the connection remapping.

Requirements:

The script post_deployment_hook_sync_agent_hub_config.py, provided in the resource/scripts folder of the Agent Hub plugin.
The project key and webapp id of both the Design and the Automation webapps. The webapp id is the short code in the webapp URL: for /projects/MY_PROJECT/webapps/aB3dE9f_agent-hub/view, the project key is MY_PROJECT and the webapp id is aB3dE9f.

In the script, APPS lists the webapps to copy:

APPS = [
    {
        "source": {"project": "MY_PROJECT", "webapp": "aB3dE9f"},
        "target": {"project": "MY_PROJECT", "webapp": "aB3dE9f"},
    },
]

Setup with a Deployer on the Design node¶

The Design node is also the Deployer. This setup needs one API key.

On the Automation node, create a global API key. Skip this step and the next one if the Automation node is already connected to an infrastructure.
On the Design node, create an infrastructure in Deployer > Infrastructures and connect the Automation node to it with this API key.
Open the infrastructure and set Run hooks as. In Settings > Deployment hooks, add a post-deployment hook and paste the script.
In the script, fill in APPS with the project keys and webapp ids of the source and target webapps.
Build a bundle, publish it to the Deployer, select the target infrastructure, enable connection remapping and deploy.
Open the result of the hook in the deployment and check that its status is synced.

Setup with a remote Deployer¶

The Deployer is a separate node: the bundle goes from the Design node to the Deployer node, then to the Automation node. This setup needs one global API key per node. Skip the steps that connect the nodes if the remote Deployer and the infrastructure are already set up.

On the Automation node, create a global API key.
On the Design node, create a global API key.
On the Deployer node, create a global API key. On the Design node, add the remote Deployer in Administration > Settings > Deployer with this key.
On the Deployer node, create an infrastructure in Deployer > Infrastructures and connect the Automation node to it with the Automation node’s API key.
Open the infrastructure and set Run hooks as. In Settings > Deployment hooks, add a post-deployment hook and paste the script.
In the script, fill in APPS and set SOURCE_NODE_URL to the URL of the Design node.
Signed in as the Run hooks as user on the Deployer node, save the Design node’s API key as a credential named agent_hub_source_api_key in Profile > My Account > Other credentials.
On the Design node, build a bundle, publish it to the Deployer, select the target infrastructure, enable connection remapping and deploy.

Deleting conversations and messages ¶

Overview ¶

Agent Hub and Agent Chat store conversations and messages in the webapp’s database — either the built-in SQLite storage in the webapp’s workload folder, or a remote SQL database, depending on the Data storage backend setting. See the “Extracting data” section of each page for how this database is set up and accessed.

Deleting conversations ¶

From the left panel, users can delete their own conversations.

Whether this removes the underlying data depends on the Permanently delete messages setting, configured by the webapp admin:

Off (default): deleted conversations and messages are hidden from the interface but kept in the database.
On: deleted conversations and messages are removed from the database.

There is no built-in way for a user or admin to bulk-delete conversations across users, or to purge conversations/messages older than a given date — deletion is always per-conversation, from the interface.

Cleaning up data directly in the database ¶

An instance administrator may need to purge old conversations directly in the database — for example to enforce a retention policy or respond to a data deletion request.

The relevant tables are conversations, messages, message_attachments, and derived_documents. messages has a foreign key to conversations with no cascading delete configured at the database level, so rows must be deleted in dependency order: attachments and derived documents, then messages, then conversations. (A fifth table, message_agents, does cascade automatically when its related messages row is deleted, except on SQLite — see the note below.)

Important

On SQLite, the message_agents cascade only works if foreign key enforcement is enabled. Run PRAGMA foreign_keys = ON; on the same connection, before the DELETE statements. Without it, orphaned message_agents rows are left behind. This setting applies per connection, so it must be repeated each time you open the database.

If the webapp’s storage is configured with a table prefix or a database schema, qualify the table names accordingly (for example agenthub_conversations or my_schema.conversations) — see the Data storage backend setting.

Warning

These statements permanently delete data and cannot be undone. Back up the database and test on a non-production instance first.

-- Adjust the retention window here.
-- PostgreSQL: now() - interval '90 days'
-- MS SQL:     DATEADD(day, -90, GETDATE())
-- SQLite:     datetime('now', '-90 days')  (run PRAGMA foreign_keys = ON; first, see above)

DELETE FROM message_attachments
WHERE message_id IN (
    SELECT m.id
    FROM messages m
    JOIN conversations c ON c.conversation_id = m.conversation_id
    WHERE c.last_modified < now() - interval '90 days'
);

DELETE FROM derived_documents
WHERE conv_id IN (
    SELECT conversation_id
    FROM conversations
    WHERE last_modified < now() - interval '90 days'
);

DELETE FROM messages
WHERE conversation_id IN (
    SELECT conversation_id
    FROM conversations
    WHERE last_modified < now() - interval '90 days'
);

DELETE FROM conversations
WHERE last_modified < now() - interval '90 days';

conversations.last_modified reflects the conversation’s last activity (including new messages), so it is a reasonable basis for an age-based retention cutoff.

Removing a webapp’s data entirely ¶

Deleting an Agent Hub or Agent Chat webapp does not delete its underlying database.

For the built-in SQLite storage, the database file remains in ${DATADIR}/workload-folders/webapps/<project_key>/<webapp_id>/ after the webapp is deleted. An instance administrator must manually delete this folder from the DSS data directory to fully remove the data.
For a remote SQL database, deleting the webapp does not delete or drop its tables; they must be cleaned up directly in that database.

Operations¶

Agent Hub Ops¶

Copying settings with a post-deployment hook¶

Setup with a Deployer on the Design node¶

Setup with a remote Deployer¶

Deleting conversations and messages¶

Overview¶

Deleting conversations¶

Cleaning up data directly in the database¶

Removing a webapp’s data entirely¶