---
title: "Designing and Positioning Agent Identities for Specific Use Cases"
description: "Overview"
canonical_url: "https://help.brainfi.sh/articles/designing-and-positioning-agent-identities-for-specific-use-cases-4YMXmozjHT"
md_url: "https://help.brainfi.sh/articles/designing-and-positioning-agent-identities-for-specific-use-cases-4YMXmozjHT.md"
---
# Designing and Positioning Agent Identities for Specific Use Cases

## Overview

This article outlines how to design, position, and launch **agent identities** that are tailored to specific use cases. An "agent identity" is a packaged combination of behavior, tone, capabilities, and constraints designed to solve a clearly defined problem for a target audience.

Use this as a reference when planning, creating, and refining new agents.

## Objectives of Agent Identities

Design each agent identity to:

* Solve a **specific, well-defined use case**
* Be **clearly understandable** in a single sentence (who it is for and what it does)
* Provide a **consistent experience** (tone, scope, behavior)
* Be **easy to adopt** and discover within your product or organization

## Core Concepts

### What Is an Agent Identity?

An agent identity is a reusable configuration that defines:

* **Purpose**: The primary task or problem the agent solves
* **Audience**: Who should use it (role, team, seniority, etc.)
* **Behavior and tone**: How the agent speaks, decides, and prioritizes
* **Capabilities**: What tools, data sources, or workflows it has access to
* **Constraints**: What it must not do, which topics to avoid, and boundaries

### Why Design Around Use Cases?

Designing around concrete use cases ensures that each agent:

* Has a **clear value proposition** (no ambiguity about when to use it)
* Can be **measured** against specific success criteria
* Is **easier to explain** to stakeholders and users
* Reduces overlap and confusion between multiple agents

## Agent Identity Template

Use the following template when defining a new agent identity.

### 1. Agent Summary

* **Name**: A short, descriptive name (e.g., "Sales Playbook Coach", "Release Notes Drafter")
* **Tagline (1 sentence)**: Who it is for and what it does
  * Example: "A specialized assistant for customer success managers that turns call notes into structured QBR decks."

### 2. Target Use Case

Clearly define:

* **Primary use case**: The main job the agent performs
* **Secondary use cases (optional)**: Closely related tasks it can handle
* **Out-of-scope tasks**: What users should *not* expect from this agent

Example:

* Primary: "Turn raw discovery call notes into structured opportunity summaries."
* Secondary: "Draft follow-up emails based on the summary."
* Out-of-scope: "Do not generate pricing proposals or legal terms."

### 3. Target Audience

Specify who this agent is for:

* Role(s) or team(s)
* Level of expertise (beginner, intermediate, expert)
* Typical workflows or tools they already use

Example:

* Audience: "Account executives and sales development reps."
* Expertise: "Familiar with CRM workflows and basic opportunity stages."

### 4. Behavioral Guidelines

Define how the agent should act and respond:

* **Tone**: Formal/informal, concise/detailed, instructional/collaborative
* **Decision style**: Cautious vs. assertive, opinionated vs. neutral
* **Interaction style**: Ask clarifying questions vs. make assumptions

Example guidelines:

* Tone: "Professional but friendly; avoid jargon when possible."
* Style: "Be concise by default; offer detail on request."
* Interaction: "If notes are incomplete, ask 1–2 targeted questions before summarizing."

### 5. Capabilities and Tools

List what the agent can do and what it can access:

* Data sources (e.g., CRM, knowledge base, code repository)
* Tools (e.g., email composer, calendar, ticketing system)
* Allowed operations (e.g., "read-only", "create drafts", "update records")

Example:

* Data: "Can read contact and opportunity records from the CRM."
* Tools: "Can draft but not send emails via the email integration."
* Operations: "May update opportunity notes but never change stage or value."

### 6. Constraints and Safety Boundaries

Clarify what the agent must **never** do:

* Topics to avoid (e.g., legal, medical, HR-sensitive content)
* Actions to avoid (e.g., final approvals, publishing, deleting) without human review
* Data boundaries and privacy constraints

Example:

* "Do not provide legal or compliance advice."
* "Never send emails automatically; always create drafts only."
* "Do not export or summarize data that contains personal identifiers beyond what is visible in the current context."

### 7. Example Prompts and Interactions

Provide concrete examples so users understand how to use the agent:

* **Starter prompts**
* **Good vs. bad input examples**
* **Typical workflows**

Example prompts:

* "Turn these raw notes into a discovery summary with next steps and risks."
* "Draft a follow-up email based on the last opportunity summary."

## Designing Effective Agent Identities

### 1. Start from Real Problems

When proposing a new agent identity, answer:


1. **What recurring task is painful or slow today?**
2. **Who owns that task?** (role/team)
3. **What does a good outcome look like?** (artifact, decision, action)

Agents that succeed usually:

* Replace or accelerate an existing manual workflow
* Fit naturally into current tools and processes
* Have a clear “before/after” improvement (time saved, quality, consistency)

### 2. Keep Scope Narrow at First

* Focus on **one primary use case** rather than many loosely related ones.
* Document out-of-scope tasks so users know when to switch agents.
* If an agent keeps being used for a different purpose, consider splitting into two agents.

### 3. Optimize for Discoverability

Ensure users can easily find the right agent:

* Use **descriptive names** that match user language, not internal jargon.
* Write a **one-line description** that appears in lists and search.
* Tag agents by **team**, **function**, or **workflow**.

Example listing:

* Name: `Customer Support Triage Assistant`
* Description: `Categorizes new tickets, suggests priority, and drafts initial responses for support agents.`

### 4. Make Behavior Predictable

* Document **response formats** (e.g., headings, bullet structure).
* Specify whether the agent should:
  * Ask for confirmation before major actions
  * Automatically suggest next steps
  * Provide citations or links when referencing internal documents

Example behavior rule:

> Always answer with: **Summary**, **Recommended Actions**, and **Risks or Open Questions**.

### 5. Iterate with Real Usage

After launching an agent identity:


1. Collect examples of successful and failed interactions.
2. Refine behavior and constraints based on patterns.
3. Update documentation and example prompts as the agent evolves.

## Example Agent Identity: Release Notes Drafter

Below is a sample agent definition to illustrate how to apply these guidelines.

### Summary

* **Name**: Release Notes Drafter
* **Tagline**: Summarizes changes from engineering tickets and commits into user-facing release notes.

### Target Use Case

* Primary: Convert a list of merged pull requests or completed tickets into a structured release notes draft.
* Secondary: Suggest segment-specific notes (admin vs. end-user) from the same source list.
* Out-of-scope: Roadmap planning, effort estimation, or bug triage.

### Target Audience

* Product managers and technical writers preparing release communication.

### Behavioral Guidelines

* Tone: Clear, neutral, and user-facing; avoid internal code names.
* Style: Group changes by feature area; highlight impactful changes first.
* Interaction: If ticket descriptions are vague, ask for clarifications before finalizing.

### Capabilities and Tools

* Data: Read-only access to issue tracker and merged pull requests for a given release.
* Operations: Generate structured markdown with headings like `New`, `Improved`, `Fixed`.

### Constraints

* Do not mention internal ticket IDs or repository names in user-facing text.
* Do not speculate about future changes.

### Example Prompts

* "Generate release notes for version 2.4.0 from these JIRA tickets and Git commits."
* "Draft separate release notes for admins and end users based on this change list."

## Launching and Communicating Agent Identities

To successfully launch agent identity as a capability and individual agents within it:


1. **Document each agent** using the template above.
2. **Create a catalog** or directory where users can browse available agents by use case.
3. **Provide onboarding guidance**:
   * Short descriptions for each agent
   * Starter prompts
   * Expected inputs/outputs
4. **Set feedback channels** so users can report issues, request new behaviors, or suggest new agents.

## Suggestions for Expanding Agent Identity Coverage

Consider designing agent identities for:

* **Go-to-market teams**
  * Sales discovery summarizer
  * Proposal/quote explainer
  * Customer success QBR builder
* **Product & engineering**
  * Requirements clarifier
  * Test case generator
  * Incident timeline summarizer
* **Operations & support**
  * Ticket triage assistant
  * Macro and knowledge article suggester
* **People & HR**
  * Policy Q&A explainer
  * Interview feedback summarizer

For each new idea, run it through the template and ensure:

* The target use case is specific and high-value.
* The audience is clearly defined.
* Behavior, capabilities, and constraints are explicit.

## Next Steps

* Use this article as a baseline to write or refine your **agent identity draft**.
* Create a standardized form or document based on the template.
* Pilot a small set of high-impact agent identities before scaling to more use cases.