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

# Agents

> Canonical OrgX agent domains, selection logic, and why specialist routing improves outcomes.

OrgX runs a **specialist agent system**: one orchestrator coordinates six domain agents.\
This is deliberate. It reduces context loss, improves output quality, and gives you clearer control over approvals.

## Questions This Page Answers

* Which OrgX agents are real and supported right now?
* What each agent is best at, and when it should be selected
* Why specialist routing beats a single generic assistant
* How autonomy, trust, and budget controls affect agent execution

## Why Specialist Agents Win

* **Higher quality per domain**: Engineering, product, design, sales, marketing, and operations have different success criteria.
* **Less rework**: The orchestrator routes tasks to the right specialist first instead of letting one model guess.
* **Faster review loops**: Decision cards are easier to approve when the right agent produced the artifact.
* **Safer autonomy**: Trust and budget controls are applied per agent capability, not as one global “on/off.”

***

## Canonical Agent Domains

<Tabs>
  <Tab title="Engineering">
    <Card title="Engineering Agent (`engineering-agent`)" icon="code">
      **Best for**: implementation, bug fixes, refactors, tests, PR-ready diffs.
    </Card>

    | Capability       | What It Produces                  |
    | ---------------- | --------------------------------- |
    | Code remediation | focused fixes with rationale      |
    | Test hardening   | unit/integration coverage updates |
    | Refactor slices  | scoped structural improvements    |
    | PR artifacts     | commit-ready change narratives    |
  </Tab>

  <Tab title="Product">
    <Card title="Product Agent (`product-agent`)" icon="clipboard-list">
      **Best for**: framing, prioritization, PRDs, initiative decomposition.
    </Card>

    | Capability         | What It Produces                                |
    | ------------------ | ----------------------------------------------- |
    | Problem framing    | clear user/job-to-be-done definitions           |
    | Plan decomposition | IWMT-ready work slices                          |
    | Priority rationale | risk/impact tradeoff summaries                  |
    | PRD scaffolds      | measurable requirements and acceptance criteria |
  </Tab>

  <Tab title="Marketing">
    <Card title="Marketing Agent (`marketing-agent`)" icon="bullhorn">
      **Best for**: campaign planning, content, messaging, channel sequencing.
    </Card>

    | Capability         | What It Produces              |
    | ------------------ | ----------------------------- |
    | Campaign design    | launch plans and briefs       |
    | Messaging variants | channel-specific copy         |
    | Funnel support     | CTA and conversion narratives |
    | Brand alignment    | voice-consistent drafts       |
  </Tab>

  <Tab title="Sales">
    <Card title="Sales Agent (`sales-agent`)" icon="handshake">
      **Best for**: qualification, outreach, competitive positioning, deal execution.
    </Card>

    | Capability              | What It Produces                   |
    | ----------------------- | ---------------------------------- |
    | Qualification structure | MEDDIC-style scorecards            |
    | Personalized outreach   | context-aware sequences            |
    | Pipeline risk detection | next-best-action cues              |
    | Competitive response    | objection handling and battlecards |
  </Tab>

  <Tab title="Design">
    <Card title="Design Agent (`design-agent`)" icon="paintbrush">
      **Best for**: UX specs, accessibility audits, design-system alignment.
    </Card>

    | Capability               | What It Produces                 |
    | ------------------------ | -------------------------------- |
    | Interaction specs        | implementation-ready UI behavior |
    | Accessibility checks     | WCAG findings and fixes          |
    | Token/component guidance | design-system-consistent updates |
    | UX rationale             | tradeoff documentation           |
  </Tab>

  <Tab title="Operations">
    <Card title="Operations Agent (`operations-agent`)" icon="gauge-high">
      **Best for**: runbooks, incident patterns, escalation and reliability loops.
    </Card>

    | Capability            | What It Produces                 |
    | --------------------- | -------------------------------- |
    | Incident analysis     | root-cause and remediation plans |
    | Operational playbooks | repeatable response workflows    |
    | Guardrail checks      | SLA/budget/status governance     |
    | Cadence reporting     | execution health summaries       |
  </Tab>

  <Tab title="Orchestrator">
    <Card title="Orchestrator Agent (`orchestrator-agent`)" icon="sitemap">
      **Best for**: sequencing, delegation, and cross-domain handoff quality.
    </Card>

    | Capability                 | What It Produces                        |
    | -------------------------- | --------------------------------------- |
    | Task routing               | right agent, right order                |
    | Dependency handling        | queue-safe handoff plans                |
    | Dispatch lifecycle control | start/pause/restart/resolve transitions |
    | Cross-domain synthesis     | unified progress narrative              |
  </Tab>
</Tabs>

***

## How Selection Works

```mermaid theme={"dark"}
flowchart TD
    A[Task Arrives] --> B{Analyze Scope, Labels, Constraints}
    B -->|implementation| C[engineering-agent]
    B -->|planning| D[product-agent]
    B -->|go-to-market| E[marketing-agent]
    B -->|pipeline/revenue| F[sales-agent]
    B -->|ux/a11y/spec| G[design-agent]
    B -->|reliability/ops| H[operations-agent]
    C --> I[orchestrator-agent validates handoff]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I
```

### Multi-Agent Patterns (Common)

* `product-agent` → `engineering-agent`: plan first, then implement.
* `design-agent` → `engineering-agent`: spec clarity before code.
* `marketing-agent` + `sales-agent`: aligned narrative from top funnel to close.
* `operations-agent` + `orchestrator-agent`: unblock and stabilize stalled execution.

***

## Governance: Trust, Autonomy, Budget

| Level        | Behavior                  | Best Use                             |
| ------------ | ------------------------- | ------------------------------------ |
| `shadow`     | Suggest only              | onboarding and evaluation            |
| `tutor`      | Suggest + explain         | policy training                      |
| `supervised` | execute with approval     | default production mode              |
| `autonomous` | execute within guardrails | trusted repetitive workflows         |
| `full_auto`  | no review gates           | low-risk, tightly bounded flows only |

Check trust state:

```json theme={"dark"}
{
  "tool": "get_my_trust_context",
  "args": { "workspace_id": "ws_...", "agent_type": "engineering-agent" }
}
```

Start bounded autonomous execution:

```json theme={"dark"}
{
  "tool": "start_autonomous_session",
  "args": {
    "max_cost_usd": 5.0,
    "max_receipts": 50,
    "scope": ["workstream_123"]
  }
}
```

***

## What Agents Do Not Do

* They do not access tools you have not connected.
* They do not bypass your decision policy unless you explicitly allow it.
* They do not spend beyond configured guardrails.
* They do not cross workspace boundaries.

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Decisions" icon="check-circle" href="/docs/platform/decisions">
    See how approvals, escalations, and blocker resolution work.
  </Card>

  <Card title="Architecture" icon="diagram-project" href="/docs/platform/architecture">
    Understand how agents, MCP, and org graph execution fit together.
  </Card>
</CardGroup>