Documentation Index
Fetch the complete documentation index at: https://docs.benchgen.com/llms.txt
Use this file to discover all available pages before exploring further.
What Is a Topic?
A Topic is a single, well‑bounded job your agent can perform. It groups: a clear name, a short classification description to catch the right user intents, a scope that sets boundaries, a list of atomic instructions that guide decisions, and the Actions (tools) allowed while the Topic is active. Keep Topics small, outcome‑focused, and non‑overlapping so the agent routes reliably.
Below are the only five things you must get right—nothing extra.
Parts of a Topic
A topic includes a name, classification description, scope, instructions, and actions.
Name
Plain‑language job label (2–3 words) that a real user might naturally say.
Do:
- Pick the concrete outcome (“Subscription Upgrade”, “Device Pairing”).
- Use words users will type—not internal acronyms.
- Keep versions out unless making a breaking change later.
Avoid:
- Generic catch‑alls (Help, Info, GeneralSupport).
- Stuffing multiple jobs (“Billing and Shipping and Returns”).
Fast test: If two different real user messages both match the whole meaning of the name but expect different result types, your name is too broad.
Example Topic Names
| Less Effective | More Effective |
|---|
| SupportTicket — Too generic and includes technical terminology that provides no context about what specific support this topic handles. | Order Tracking — Clearly describes the specific task using language customers naturally use when checking their shipments. |
| DataManager — Uses internal technical language and doesn’t indicate what data management tasks users can actually request. | Export History — Specifies the exact user outcome in plain language that matches how customers would naturally ask for this feature. |
Classification Description
1–3 tight sentences (or one crisp line) listing the kinds of user requests that should trigger this Topic. Its job: maximize correct routing, not explain policy.
Formula idea: Handle <problem / task keywords>: <phrase variant 1>, <phrase 2>, <phrase 3>; include <variation set>.
Use real verbs + objects users actually say (upgrade plan, connect device, resend activation). Skip internal codes and long storytelling.
Checklist:
- Mentions 3–6 concrete scenario phrases.
- Includes common synonyms (upgrade / change plan, connect / pair device) if they materially differ.
- Excludes execution steps (those belong in instructions) and hard rules (those belong in scope).
Example Classification Descriptions
| Less Effective | More Effective |
|---|
| ”Handle product inquiries and stuff.” — Uses vague language that doesn’t provide specific keywords or phrases that users actually say. | ”Answer questions about product features: what does it do, how it works, compatibility requirements; include feature comparisons and specifications.” — Lists concrete scenarios with specific phrases users actually say. |
| ”Process customer data updates.” — Uses internal terminology and doesn’t explain what types of requests should trigger this topic. | ”Help customers update personal information: change email, update phone number, modify address; include profile picture changes.” — Clearly describes specific user requests with concrete examples. |
Scope
Defines boundaries: what the agent is allowed to accomplish here and what it must decline or escalate. Without explicit negatives, models drift.
Write it as four short lines:
Your job is to …
You can …
You must … (critical invariant)
You cannot … / Never …
- Start with the primary outcome: “enable a paid plan upgrade” or “complete first‑time Bluetooth pairing”.
- List only supporting tasks essential to success (e.g., confirm current plan, surface price delta).
- Include at least one hard exclusion (e.g., cannot issue refunds, cannot alter hardware firmware, cannot change ownership).
- If an exclusion triggers escalation, state it (“Escalate if user requests account deletion”).
Example Scope Definitions
| Less Effective | More Effective |
|---|
| ”Manage customer accounts.” — Provides no specific guidance about capabilities, limitations, or expected behavior. | ”Your job is to help customers download their data export. You can generate export files, check export status, and resend download links. You must verify account ownership before starting any export. You cannot modify what data gets exported or delete account data—escalate those requests.” |
Instructions
Atomic, imperative rules the model follows while the Topic is active. Each line = one decision aid. They clarify sequence, required info, branching, and when to ask vs act.
Characteristics of a good instruction:
- Starts with a verb (Ask / If / When / After / Always / Never / Use / Do not).
- Refers to Actions by exact name when tool choice matters.
- Contains a single conditional path; split if there are two “ifs”.
- Avoids vague nouns (“details”, “stuff”); be concrete (“current plan name”, “device model”).
Convert vague to precise:
- Vague: “Get user info before upgrade.”
- Clear: “Before showing upgrade options, retrieve current plan via
GetCurrentSubscription and confirm it matches the user’s expectation.”
Example Topic Instructions
| Less Effective | More Effective |
|---|
| ”Check the customer’s current status.” — Doesn’t specify when, how, or what “status” means. | ”When a customer asks about their membership, use GetMembershipStatus to retrieve tier information and display current benefits before answering questions." |
| "Help customers with their questions.” — Lacks timing and method details. | ”For questions about return eligibility, first ask for the order number and purchase date. Then use CheckReturnPolicy with those details to provide accurate return window information." |
| "Follow up when needed.” — Doesn’t indicate when to follow up or provide context. | ”After completing a data export request, always ask if the customer needs help downloading the file or has questions about the export format.” |
Actions
Actions are the only tools this Topic may call. Keep the list minimal—each should directly support a step in your instructions.
Selection Rules:
- Include only what appears in at least one instruction.
- One Action per distinct external operation (fetch current plan, submit upgrade, start pairing).
- Inputs must be simple, named clearly (
plan_id, device_model).
- Outputs should be structured so the agent can reference fields directly (
status, price_delta, capability_list).
Action Set Examples:
- Subscription Upgrade:
GetCurrentSubscription, ListUpgradeOptions, SubmitUpgradeOrder.
- Device Pairing:
FetchDeviceStatus, StartPairingAction, FetchDeviceCapabilities.
If an Action is never called in logs for this Topic after launch, remove it or move it to the Topic where it actually belongs.
How Topics Work
When an agent receives a user request, it evaluates the input against all assigned topic names and classification descriptions. The agent then selects the most relevant topic based on the best match with the user’s question and recent conversation context.
Once a topic is selected, the agent uses the topic’s scope to understand its boundaries, follows the instructions to determine the appropriate sequence of actions, and utilizes the available actions to complete the task or gather necessary information.
Example Topic Implementation
Let’s examine a Product Return topic to understand how each element guides agent behavior:
| Element | Content |
|---|
| Name | Product Return |
| Classification Description | Help customers return items: start return, check return policy, get return label, refund status; include exchanges and damaged products. |
| Scope | Your job is to help customers initiate returns for eligible products. You can check return eligibility, generate return labels, and provide return instructions. You must verify order details and product condition before processing returns. You cannot approve returns outside policy window or process refunds directly—escalate those requests. |
| Instructions | 1. Ask for order number and which item they want to return. 2. Use CheckReturnEligibility to verify the product qualifies. 3. If eligible, ask for reason and use GenerateReturnLabel. 4. Explain return process. 5. After generating label, ask if they need help with exchanges. |
| Actions | CheckReturnEligibility, GenerateReturnLabel, GetOrderDetails |
Best Practices
- Keep scope narrow (one primary outcome per Topic).
- Separate intent categories into separate Topics.
- Test with both positive and negative user prompts to validate routing.
- Remove unused instructions after launch to reduce model confusion.
Next Steps
