Configure and test your first Agent

Use a source-first setup sequence, test realistic scenarios, and create a clear launch decision for the team.

A first Agent should solve a small, verified set of shopper jobs before it attempts every possible journey. Start with trusted content and catalog data, add explicit behavior and support rules, then test the whole response in isolated surfaces.

This guide provides a practical implementation order and an acceptance gate. It is designed for a real store, where inaccurate policy or product information is more damaging than an incomplete optional feature.

How this fits into Humind

AI Agent is the configuration space for the customer-facing assistant. Knowledge and Catalog provide facts; Guidance shapes response behavior; Tools add actions; Escalation defines human support; Test surfaces let you review the result before deployment.

Changes can affect many conversations, so test representative buying and support scenarios after each meaningful update. A visually correct chat is not enough: verify the answer, product context, available action, and handoff behavior together.

Before you start

Access: An administrator or custom role with write access to Agent configuration, Knowledge, and Catalog should own initial setup. Other teammates can review according to their section permissions.

  • Choose the correct company and market and connect the intended catalog source.
  • Collect approved policies, brand rules, support destinations, and launch domains.
  • Name an owner for content, catalog, Agent behavior, operations, and storefront deployment.

Step-by-step workflow

  1. Define the first supported journeys

    Select a manageable group of journeys such as product discovery, product detail, delivery or returns, and human support. For each journey, write the expected source, acceptable answer, unavailable-data behavior, and escalation outcome.

    Include one case the Agent should decline or route elsewhere. Clear boundaries make testing meaningful and prevent a broad launch promise from hiding known gaps.

  2. Prepare Knowledge and Catalog

    In Knowledge, create or import one authoritative source for each supported policy. Use folders for maintainability, public and published states for customer content, and snippets for short private guidance. In Catalog, verify representative products, variants, visibility, collections, promotions, and useful filters.

    Resolve contradictions before proceeding. Do not add a Guidance rule that tells the Agent to ignore an incorrect product value or duplicate policy.

  3. Configure behavior and actions

    In Guidance, choose personality, answer length, language behavior, rules, and moderation. In Tools, enable only actions with tested dependencies. In Escalation, configure supported channels, handoff criteria, pre-handoff questions, operator step-in, and satisfaction behavior.

    Review autosave or save feedback after each change. Ask operators to confirm Inbox access and availability before enabling a customer promise of live help.

  4. Customize the interface and entry point

    Use Chat interface for the avatar, colors, contrast, bubble and button styling, optional Agent name, and home text. Use Entry point for launcher type, position, size, page rules, and desktop or mobile behavior.

    Preview every rule and ensure the launcher does not hide navigation, consent, cart, or checkout controls. Keep the first launch simple enough to verify reliably.

  5. Run the acceptance suite

    Use Playground for exploratory conversations, Test product for product-focused behavior, and Batch testing for a repeatable dataset. Review facts, selected products, actions, language, moderation, and support state together.

    Classify each failure by source, make one focused correction, and rerun the failed and neighboring cases. Approve launch only when critical journeys pass and remaining limitations are documented.

Permissions and important caveats

  • A visually polished interface does not compensate for unverified Knowledge or Catalog data.
  • Tools and support integrations may have prerequisites outside the Agent page.
  • Playground does not validate live storefront installation or domain configuration.
  • New catalog or filter data may need time to synchronize before final testing.

Verify the result

Use this checklist before considering the work complete:

  • Every launch journey has an owner, source, expected result, and fallback.
  • Critical questions pass in a fresh Playground session and repeatable dataset.
  • Operators can receive, take over, and return an escalated conversation.
  • A storefront smoke-test plan and rollback owner are ready before deployment.

Troubleshooting

The Agent setup feels inconsistent

Return to the journey list and identify which source owns each fact or action. Remove duplicated authority, then retest one journey at a time instead of adding broader instructions.

A tool is enabled but unavailable in conversation

Open Tools and check whether Humind marks missing configuration or points to another settings page. Verify the underlying catalog, order, appointment, or support dependency before testing again.

Tests pass for one person but not another

Compare active company, market, language, conversation history, product context, role, and test time. Use the same fresh scenario and current configuration for a controlled comparison.

Related guides

Was this article helpful?