Playbook: Onboarding a New Agent to the Fleet

Adding a new agent to the SIE fleet is not a matter of writing a prompt and pointing it at the Knowledge Core. Every agent is a new attack surface, a new source of potential hallucination, and a new contributor to the Human Correction Tax if poorly configured. This playbook ensures that every new agent is systematically validated before it operates autonomously.

Phase 1: Role Definition

Before writing a single line of configuration, define the agent’s purpose and boundaries in plain language. This definition becomes the foundation for every subsequent decision.

Step 1.1 — Define the Commander’s Intent. Write a one-paragraph statement describing what this agent exists to accomplish and why. The Commander’s Intent is the strategic directive that the agent uses to make judgment calls when its specific instructions don’t cover a situation. Example: “The Marketing Agent exists to generate draft social media content and email campaigns that align with the brand voice defined in the Knowledge Core. It should prioritize engagement metrics and always defer to the brand guidelines when creative choices conflict with performance patterns.”

Step 1.2 — Define the role boundaries. Specify what the agent does and does not do. Be explicit about the negative boundaries — what this agent must never attempt. Document these as Axiomatic constraints that cannot be overridden by prompt reasoning.

Step 1.3 — Identify the agent archetype. Based on the Hybrid Reasoning Architecture, determine which archetype this agent fits:
– General Contractor — Orchestrates workflows using RAG and tool calls. Broad knowledge access, moderate depth.
– Domain Expert — Deep knowledge within a specific domain via MCP. Narrow but authoritative.
– Master Craftsman — Specialized skill execution (e.g., code generation, data analysis). Task-focused, not knowledge-focused.

Step 1.4 — Document the role definition. Create a role definition file in the agent configuration directory. Include: agent name, Commander’s Intent, archetype, positive capabilities, negative constraints, and the specific Knowledge Core domains it needs access to.

Phase 2: Knowledge and Tool Configuration

Step 2.1 — Scope knowledge boundaries. Define exactly which Knowledge Core domains the agent can access via RAG retrieval. Use taxonomy-based scoping: specify which knowledge_topic or sie_topic terms the agent’s queries should be filtered to. An agent that needs access to everything is almost certainly scoped too broadly — revisit the role definition.

Step 2.2 — Configure tool access. List the specific tools the agent is authorized to use. For each tool, define the capability constraints:
– WordPress REST API: Which post types can it create/update? What status values can it set? (Always draft — never publish.)
– Search tools: Which indices or namespaces can it query?
– External APIs: Which endpoints, if any, can it call?

Step 2.3 — Embed governance protocols. The agent’s system prompt and tool configuration must include:
– The Iron Word Verification Loop requirements (Verification Ledger metadata format, confidence threshold, mandatory source citation)
– The draft-only constraint (hardcoded in the tool layer, not just in the prompt)
– The Steady Presence trigger conditions (what constitutes a failure that should generate an incident)

Step 2.4 — Configure audit logging. Ensure the agent’s actions are routed to the centralized audit log with the correct agent role identifier. Verify that log entries include all required fields: timestamp, agent role, action, confidence, reasoning, and outcome.

Phase 3: Graduated Testing

New agents are not deployed directly to production. They progress through three testing stages, each with increasing autonomy and real-world exposure.

Stage 1: Sandboxed Testing

The agent operates against a test Knowledge Core (or a scoped subset) with no connection to production WordPress or any external system.

• Run 5-10 representative tasks that cover the agent’s full scope of responsibilities
• Verify that every output includes a complete Verification Ledger
• Verify that the agent correctly refuses tasks outside its defined boundaries
• Verify that confidence scores correlate with actual output quality (high confidence = accurate, low confidence = appropriate uncertainty)
• Verify that source citations point to real documents that support the claims made

Gate criteria: All outputs include valid Verification Ledgers. No out-of-scope actions attempted. Confidence calibration is reasonable.

Stage 2: Supervised Production

The agent operates against the production Knowledge Core and can create drafts in WordPress, but every action is reviewed by the Fleet Commander before any downstream effects.

• Assign 3-5 real tasks from the production backlog
• The Fleet Commander reviews every output using the Track 2 (Agent-Generated Content) review workflow
• Track the time the Fleet Commander spends reviewing — this is the baseline for the agent’s Human Correction Tax contribution
• Log any corrections the Fleet Commander makes and categorize them: knowledge gap, prompt ambiguity, tool misconfiguration, or genuine hallucination

Gate criteria: Fleet Commander approval rate exceeds 80%. No critical errors (hallucinated facts, incorrect sources, out-of-scope actions). Review time is decreasing across the task series.

Stage 3: Autonomous Operation

The agent operates with standard Fleet Commander oversight — notification-based review rather than mandatory pre-approval for every output.

• The agent is added to the active fleet roster
• The Fleet Commander receives notifications when the agent completes tasks and reviews Verification Ledgers on a regular cadence
• Monitoring baselines are established: average confidence score, average review time, rejection rate

Gate criteria: The agent has been operating for at least one week without a critical error. Monitoring metrics are stable.

Phase 4: Production Deployment

Step 4.1 — Add to the fleet roster. Register the agent in the SIE fleet configuration with its finalized role definition, knowledge boundaries, and tool access.

Step 4.2 — Establish monitoring. Set up alerts for: confidence scores below threshold, Verification Ledger failures (missing metadata), error rates above baseline, and any attempted out-of-scope actions.

Step 4.3 — Schedule first review. Set a 30-day review checkpoint. At this checkpoint, the Fleet Commander reviews the agent’s performance metrics, audit logs, and any Steady Presence incidents. Based on this review, the agent’s knowledge boundaries or tool access may be expanded, narrowed, or left unchanged.

When to Skip Stages

Never. The graduated testing process exists because agent failures in production have compounding costs. A hallucinated fact that enters the Knowledge Core via an untested agent can propagate to other agents’ outputs, customer-facing content, and SEO-indexed pages. The cost of three days of graduated testing is negligible compared to the cost of a production incident caused by a poorly configured agent.