> ## Documentation Index
> Fetch the complete documentation index at: https://koreai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# How to define clear responsibilities for each enterprise agent

Use this guide when an agent is becoming too broad, too vague, or difficult for customers, builders, and support teams to reason about.

## Concept

An agent responsibility is a contract. It says what the agent owns, what it can do, what it must not do, what information it needs, and when it should stop, hand off, or escalate.

Clear responsibilities make routing safer. A supervisor can only route well when every specialist has a distinct job.

| Surface       | What it defines                                                           |
| ------------- | ------------------------------------------------------------------------- |
| `GOAL`        | The business outcome the agent owns.                                      |
| `PERSONA`     | How the agent communicates.                                               |
| `LIMITATIONS` | What the agent should not claim or attempt.                               |
| `GATHER`      | Information the agent must collect.                                       |
| `CONSTRAINTS` | Conditions that must be true before proceeding.                           |
| `TOOLS`       | External capabilities the agent can use.                                  |
| `HANDOFF`     | When another agent should take ownership.                                 |
| `DELEGATE`    | When another agent should provide a result while this agent stays active. |
| `COMPLETE`    | When the agent can finish the interaction.                                |

Limitations guide the model. For hard enforcement, pair them with tools, constraints, guardrails, permissions, and handoff boundaries.

## Decision guide

| Use this design choice             | When it fits                                                                                    |
| ---------------------------------- | ----------------------------------------------------------------------------------------------- |
| Keep one agent                     | One business owner, one data boundary, one tool set, and one success definition cover the work. |
| Split into specialist agents       | Different owners, permissions, policies, tools, or completion criteria are involved.            |
| Add handoff boundaries             | Another agent should own the rest of the customer journey.                                      |
| Add delegate boundaries            | The current agent needs a subtask result but should remain the active conversation owner.       |
| Add constraints, guardrails, tools | A limitation must be enforced rather than only described.                                       |
| Add human escalation               | Verification, safety, policy, or customer frustration requires a person.                        |

## Responsibility worksheet

Before writing the agent, answer these questions:

| Question                                   | Example answer                                                            |
| ------------------------------------------ | ------------------------------------------------------------------------- |
| What business outcome does this agent own? | Recover account access after identity verification.                       |
| What must it never do?                     | Bypass verification or answer billing questions.                          |
| What information must it collect?          | `account_id`, `verification_method`.                                      |
| Which tools or data can it use?            | Identity verification tools, account recovery tools.                      |
| When should it hand off?                   | Billing request, human request, verification cannot continue.             |
| How does it complete?                      | Required identity context is present and the next recovery step is clear. |

## Minimal working example: account-security specialist project

This example is a project-level set. The responsibility boundary is visible in the account-security agent, and the handoff targets are defined in the same project.

`agents/account-security-agent.agent.abl`

```yaml theme={null}
AGENT: Account_Security_Agent
GOAL: "Verify identity and help users recover account access"

PERSONA: |
  Security-conscious account support specialist.
  Explains verification steps clearly.

LIMITATIONS:
  - "Cannot bypass identity verification"
  - "Cannot answer billing questions"

INTENTS:
  billing: "Billing, invoices, payments, or subscription charges"
  human_help: "User asks for a person or verification cannot continue"

GATHER:
  account_id:
    prompt: "What is your account ID?"
    type: string
    required: true
  verification_method:
    prompt: "How would you like to verify your identity?"
    type: string
    required: true

CONSTRAINTS:
  - REQUIRE account_id IS SET
    ON_FAIL: "I need your account ID before I can continue."

HANDOFF:
  - TO: Billing_Support_Agent
    WHEN: intent.category == "billing"
    PASS: [account_id]
    SUMMARY: "Customer needs billing support"
    RETURN: false
  - TO: Live_Agent
    WHEN: intent.category == "human_help"
    PASS: [account_id]
    SUMMARY: "Customer needs a human agent or cannot continue verification"
    RETURN: false

COMPLETE:
  - WHEN: account_id IS SET AND verification_method IS SET
    RESPOND: "I can continue account recovery for {{account_id}} using {{verification_method}} verification."
```

`agents/billing-support-agent.agent.abl`

```yaml theme={null}
AGENT: Billing_Support_Agent
GOAL: "Answer billing questions after account-security handoff"

GATHER:
  account_id:
    prompt: "What account should I review?"
    type: string
    required: true

COMPLETE:
  - WHEN: account_id IS SET
    RESPOND: "I can continue billing support for {{account_id}}."
```

`agents/live-agent.agent.abl`

```yaml theme={null}
AGENT: Live_Agent
GOAL: "Transfer customers to a human support specialist"

COMPLETE:
  - WHEN: true
    RESPOND: "I will connect you with a human support specialist."
```

The account-security agent owns identity verification and recovery. Billing and human assistance are outside that responsibility and are represented as handoff boundaries.

Since neither `HANDOFF` entry above declares `HISTORY`, each target now receives the full conversation history by default (the current platform default when `HISTORY` is omitted). Also, because each `WHEN` here is a single-field comparison (`intent.category == "billing"`), an unset field simply makes the comparison evaluate `false` — no error, and the trace shows your literal source text.

## How to write strong goals

Weak goal: "Help customers with account stuff."

Strong goal: "Verify identity and help users recover account access."

A strong goal names the business outcome, the user, and the scope. It should be narrow enough that an owner can say whether the agent succeeded.

## How to write useful limitations

| Limitation                            | Why it helps                                        |
| ------------------------------------- | --------------------------------------------------- |
| `Cannot bypass identity verification` | Prevents unsafe account recovery.                   |
| `Cannot approve refunds`              | Separates policy explanation from financial action. |
| `Cannot provide medical diagnosis`    | Draws a regulated-domain boundary.                  |

For regulated or high-risk actions, do not rely on limitations alone. Add hard boundaries through tools, constraints, guardrails, permissions, or human handoff.

## When to split an agent

Split an agent when it has more than one business owner, more than one permission model, conflicting limitations, different tools by topic, or different success criteria by request type.

Keep one agent when the same owner, policy, tools, data, and success criteria apply across the conversation.

Use `DELEGATE` instead of splitting when the active agent only needs a subtask result and should keep the user conversation.

## Verification

1. Validate the account-security agent and its handoff targets together.
2. Send: "I need to recover my account." Confirm `account_id` and `verification_method` are gathered.
3. Send: "I have a billing question." Confirm the route goes to `Billing_Support_Agent` and passes `account_id`.
4. Send: "I want to talk to someone." Confirm the route goes to `Live_Agent`.
5. Inspect trace/debug output for selected handoff target, passed context, and final active agent.

## Production readiness checklist

* Each specialist has one primary business owner and one primary outcome.
* Required fields are gathered or otherwise populated before tools, handoffs, or completion need them.
* Sensitive or regulated actions are enforced with tools, constraints, guardrails, permissions, or human handoff.
* Out-of-scope intents have handoff routes.
* Success, out-of-scope, human escalation, and failure paths have test utterances.
* Trace/debug output shows clear ownership transitions.

## Common mistakes

| Mistake                                  | Why it happens                                                   | How to avoid it                                                                  |
| ---------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Writing vague goals                      | The builder starts from a department name instead of an outcome. | Name the exact business outcome.                                                 |
| Treating limitations as hard enforcement | Limitations are easy to write and read.                          | Add constraints, tools, guardrails, permissions, or handoff for hard boundaries. |
| Creating overlapping specialists         | Teams define agents by org chart instead of user outcomes.       | Use distinct goals and test ambiguous requests.                                  |
| Handing off without context              | The boundary is defined, but the target lacks state.             | Pass only the fields the target needs and verify they are populated.             |

## Troubleshooting

| Symptom                               | Likely cause                                                      | What to check                                                                   |
| ------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| A specialist answers outside its area | Goal or limitations are too broad, or no handoff boundary exists. | Tighten `GOAL`, add specific `LIMITATIONS`, and add `HANDOFF` routes.           |
| Required fields warn or appear unused | The agent collects fields but never consumes them.                | Use the fields in completion, tools, memory, handoff, delegate, or constraints. |
| Supervisor routing is inconsistent    | Specialist responsibilities overlap.                              | Revisit each specialist's owner, outcome, and out-of-scope routes.              |