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.

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

Engineering

Engineering Agent (`engineering-agent`)

Best for: implementation, bug fixes, refactors, tests, PR-ready diffs.

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

Product

Product Agent (`product-agent`)

Best for: framing, prioritization, PRDs, initiative decomposition.

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

Marketing

Marketing Agent (`marketing-agent`)

Best for: campaign planning, content, messaging, channel sequencing.

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

Sales

Sales Agent (`sales-agent`)

Best for: qualification, outreach, competitive positioning, deal execution.

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

Design

Design Agent (`design-agent`)

Best for: UX specs, accessibility audits, design-system alignment.

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

Operations

Operations Agent (`operations-agent`)

Best for: runbooks, incident patterns, escalation and reliability loops.

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

Orchestrator

Orchestrator Agent (`orchestrator-agent`)

Best for: sequencing, delegation, and cross-domain handoff quality.

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

---

How Selection Works

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:

{
  "tool": "get_my_trust_context",
  "args": { "workspace_id": "ws_...", "agent_type": "engineering-agent" }
}

Start bounded autonomous execution:

{
  "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 cross workspace boundaries.

How the spend guardrail actually behaves

A cost cap is checked at accounting boundaries, not continuously.

1. Before dispatch. The run is priced conservatively and the estimate is compared against max_cost_usd and the workspace daily/weekly/monthly caps. An estimate over the line is refused before any provider call.
2. Between work items. Inside an autonomous session, accumulated cost is compared to the limit before each next item, and an item whose estimate would cross the cap is skipped.
3. After the run. Actual cost is reconciled against the cap.

Work that is already in flight is not interrupted, and the pre-dispatch check uses an estimate rather than the final bill. So the final billed cost for a crossing step can exceed the cap. When it does, the overage is not silent: the session closes with status budget_exceeded, and the run raises a budget_breach decision so the spend lands in the operator chronicle for review.

Treat max_cost_usd as a stop signal, not a hard ceiling on the invoice. The cap bounds what gets started; it does not truncate a step already running.

---

Next Steps

Decisions

See how approvals, escalations, and blocker resolution work.

Architecture

Understand how agents, MCP, and org graph execution fit together.