# Agent Organization

> Agent Organization

- Skill: `elophanto/agent-organization` (Agent Skill)
- Install (CLI): `npx skillmds@latest add elophanto/agent-organization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/elophanto/agent-organization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: elophanto (https://skillmd.com/u/elophanto)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/elophanto/agent-organization

---

# Agent Organization

## Description
Best practices for spawning, managing, and teaching persistent specialist
child agents (marketing, research, design, etc.) through the organization system.

## Triggers
- organization
- specialist
- marketing agent
- research agent
- design agent
- team
- delegate work
- spawn specialist
- child agent

## Instructions

### Organization vs Swarm
- **Organization** (this skill) — persistent EloPhanto clones for domain work (marketing, research, design, anything). Own identity, knowledge vault, autonomous mind. They learn from feedback and work proactively.
- **Swarm** — ephemeral external coding agents (Claude Code, Codex, Gemini CLI) for code tasks. No learning, no persistence.

If the task is domain expertise → organization. If the task is code → swarm.

### When to Spawn Specialists
1. **Domain-specific work** — marketing strategy, competitive research, design audits, content creation
2. **Recurring work** — tasks that will happen repeatedly (the specialist accumulates knowledge over time)
3. **Parallel domain work** — "research competitors AND draft marketing plan" → spawn both
4. **Proactive monitoring** — "keep an eye on competitor pricing" → specialist with autonomous mind

### When NOT to Spawn
- Quick one-off tasks you can handle directly
- Coding tasks (use swarm instead)
- Tasks that need your tools directly (browser, email, payments)

### Spawning a Specialist

Use `organization_spawn` with a clear role and purpose:
- **role** — short identifier: "marketing", "research", "design", "content"
- **purpose** — what this specialist does (becomes their identity)
- **seed_knowledge** — relevant knowledge files to copy from your vault

The specialist goes through first awakening, discovers its identity, and is ready to work.

If a specialist for the role already exists, it's reused (restarted if stopped). Don't spawn duplicates.

### Delegating Tasks

Use `organization_delegate` with either `role` (auto-resolves) or `child_id`:
- Be specific about the task — "Create a 5-post content calendar for next week targeting developer audience"
- Include constraints — "Focus on X and LinkedIn, keep posts under 280 chars for X"
- Reference context — "Use the brand guidelines in your knowledge vault"

### Reviewing Output

Always review specialist output using `organization_review`:
- **Approve with feedback** — reinforces good behavior, optional praise or refinement notes
- **Reject with specific reason** — the rejection becomes a correction file in the specialist's knowledge vault. Be specific about what went wrong and what the correct approach is.

Good rejection: "Post exceeded X's 280 char limit. Always check platform character limits: X=280, LinkedIn=3000, Mastodon=500."
Bad rejection: "This is wrong."

### Teaching

Use `organization_teach` to proactively push knowledge:
- Brand guidelines, style guides, platform rules
- Domain-specific knowledge the specialist needs
- Corrections that apply broadly (not tied to a specific task)

### Trust Scoring
- Trust = approved_count - rejected_count
- New specialists (trust < 10) — review all output
- Trusted specialists (trust >= 10) — eligible for auto-approve
- Low trust (negative) — may need re-seeding with corrected knowledge

### Anti-Patterns
- **Spawning too many specialists** — each is a full process with its own LLM budget. Respect max_children.
- **Vague delegation** — "do marketing" is too broad. Break into specific tasks.
- **Not reviewing output** — the feedback loop is how specialists learn. Skip review = no learning.
- **Rejecting without explanation** — "rejected" teaches nothing. Always include specific feedback.
- **Duplicating roles** — check `organization_status` before spawning. One specialist per role.

## Verify

- The intended other agent / tool / channel actually received the message; an ack, message ID, or response payload is captured
- Identity, scopes, and permissions used by the call were the minimum required; over-permissioned tokens are called out
- Failure handling was exercised: at least one retry/timeout/permission-denied path is shown to behave as designed
- Hand-off context passed to the next actor is complete enough that the receiver could act without a follow-up question
- Any state mutated (config, memory, queue, file) is listed with before/after values, not just 'updated'
- Sensitive material (keys, tokens, PII) was redacted from logs/transcripts shared in the verification evidence