---
name: cortex-create
description: Provision a NEW Ninjo agent end-to-end via the cortex-gateway MCP — gather the brief, build the SDK (system prompt + v5Config), create the agent, deploy, and set up activation infrastructure (custom properties, data-gated follow-ups, terminal contact limit). Use when the user wants to create/build/onboard a new agent. Runs entirely through MCP tools on the full /mcp surface (the native OAuth connection exposes create_agent).
---

# cortex-create — provision a new agent (MCP-first)

Create a new Ninjo agent and deploy its first SDK through the cortex-gateway MCP. No scripts, no DB.

**Precondition:** `create_agent` lives on the full `/mcp` surface (the native OAuth transport uses
it). If `create_agent` isn't available, the gateway was connected
to the curated `/mcp/client` subset — point `CORTEX_GATEWAY_URL`'s `.mcp.json` entry at `/mcp` and
reconnect.

## 1. Identify the agent + influencer
- Agent name: `$ARGUMENTS` (kebab/handle). Confirm `agents/<name>/` does not already exist; if it
  holds only a brief (`meta.md`, `input/`), continue from step 3.
- Ask for the **influencer_id** (a CUID, not a UUID). If unknown, `list_agents` shows existing agents and their
  `influencer_id` for reference. The agent will be created under that influencer.
- **Multi-influencer token?** If `get_me` returns `scope: "multi-influencer"` (agency token), the connection is **unscoped**: pass this `influencer_id` on **every** cortex-gateway call in this flow — not just `create_agent`, but the `deploy_agent_sdk` / trigger / automation calls too (it must be one of `available_influencer_ids`). If the user names a creator by **@handle**, resolve it to the id via `get_me`'s `influencers` map. To stand up the same agent for another client, run the flow again with **that** client's `influencer_id`. Single-influencer tokens (`scope: "single-influencer"`) infer it from the JWT and ignore the param. See `knowledge/mcp-tool-reference.md` › Ground rules › **Influencer scope**.

## 2. (Optional) Pull creator data over MCP
If the influencer has self-serve / IG data, enrich the brief:
- `get_self_serve_data` — creator bio, program, IG posts/conversations already on file.
- `trigger_fetch_info` — kick off an IG data fetch if none exists yet (fire-and-forget).
Skip gracefully if unavailable — partial data is fine.

## 3. Collect & parse the brief
Gather creator docs / pasted text / self-serve data into structured fields: identity, voice,
conversation flow, resources (real URLs), program/pricing, happy-path examples, edge cases. Note
what's missing.

## 4. Pick a flavor
Everything is built on **`principles`** (`templates/principles.md`) — "fewer rules, more examples."
Then pick the **motion flavor** that matches the creator's `(vertical, ticket_tier)` and how they
close — load it alongside the base; it tunes Flow, Calibration, rapport technique, and target metrics:
- **`principles-express`** — low-ticket, keyword/quick entry, drop the resource fast.
- **`principles-consultative`** — mid-ticket, real discovery, link/booking mid-conversation, same-day.
- **`principles-deep-nurture`** — premium, empathy + video acuse, the DM closes (single session).
- **`principles-book-the-call`** — high-ticket, the call closes; DM only qualifies (link rarely in DM).

Confirm the parsed brief + chosen flavor with the user before building.

## 5. Build the SDK under `agents/<name>/sdk/`
Author the system prompt + the 8 v5Config fields, following the chosen template's section rules and
`knowledge/best-practices-top10.md`, `knowledge/prompt-antipatterns.md`, `knowledge/AGENTS.md`.
**All 8 are required — author the complete set, never keywords-only.** `system.md`, `examples.md`, and
`knowledge_base.md` must carry **real content**; the other five may be authored **empty** (`[]` for the
JSON files, minimal for prose) when they don't apply — but **at least one of `keywords.json` /
`program.json`** must be populated:
- `system.md` — Identity+Mission, Voice (5-6 REAL creator messages), Flow, ≤7 Principles, Tools.
  No hard-rule lists; examples teach tone/flow. (~1.5-2k tokens for `principles`.)
- `examples.md` — 10+ real/adapted conversations (the highest-leverage field).
- `objections.md`, `knowledge_base.md`, `personal_story.md`
- `keywords.json`, `resources.json`, `program.json`, `case_studies.json`
Cross-check: every URL in the prompt appears in `resources.json`; examples obey `system.md`;
keyword count matches.

## 6. Review gate (before deploy)
Self-review against the template + `best-practices-top10.md` (esp. BP-4 internal contradictions,
BP-5 cross-file contradictions, BP-7 unguarded actions). Fix CRITICAL/HIGH findings before
deploying. Present the agent to the user and wait for confirmation.

## 7. Create + deploy via MCP
1. `create_agent` → `{ name, prompt: <system.md>, description, mode: "INDIVIDUAL", set_on_conversation: false }`.
   Capture `agent_id`. Create it **inactive / unattached** by default.
2. `deploy_agent_sdk` → `{ agent_id, system, examples, keywords, knowledge_base, objections, personal_story, program, resources, case_studies }`.
   This dual-writes keywords and verifies. **If the report has `verified: false` or `partial: true`,
   the deploy did not fully succeed — call `restore_prompt_version` with `rollback_version_id`.**
3. `get_agent_config` → confirm the live config matches what you authored:
   - The config is **complete, not keywords-only**. `examples` and `knowledge_base` must come back
     **populated** (alongside the system prompt), and **at least one of `keywords` / `program`** must
     be present; the other sections may be empty (`[]` / minimal) but the config must not be just
     `{keywords:[…]}` — that's the **degenerate** (incomplete) state. If `examples`/`knowledge_base` are
     missing, redeploy the full SDK — do **not** leave a keywords-only agent that can go live.
     **Never** finish create by running `create_agent` + a keyword sync alone.
   - `keywords`, `program`, `resources`, `case_studies` came back as **objects/arrays, not
     JSON-encoded strings** (a string here means a double-encoded deploy; redeploy the parsed value).

## 8. Activation infrastructure (REQUIRED — the agent is not done without it)

A deployed prompt alone is an **incomplete system**. The recurring failure across MCP-built
agents (including agency builds) is: good prompt, but no contact limit, no data-gated
follow-ups, and ad-hoc custom properties — so booked leads get double-messaged, follow-ups
fire on non-leads, and "terminal" properties trigger nothing. Do not finish creation without
walking the user through these three, **in this order**:

1. **Custom properties** (`list_custom_properties` → `upsert_custom_property`).
   - Most signals already exist as auto-generated `ninjo_*` system properties (e.g.
     `call_booked`, `booking_link_sent`, `program_interest`, `phone_shared`). **Reuse those —
     do not hand-create duplicates** (a duplicate like `agendo_llamada` vs `call_booked` ends
     up disagreeing in production and gates nothing).
   - Only create a property when the offer needs a signal the system doesn't already emit.
     **Make terminal/gating properties booleans** (reliable, simple).
   - Reminder: the **external evaluator** sets properties from the transcript — the SDK never
     sets them. Define the property *so that* a contact limit / workflow can gate on it.

2. **Follow-ups** (`upsert_workflow` type `FOLLOW_UP`) — at least one, **gated by
   `propertyConditions`, not by prompt text alone**. A follow-up with empty `propertyConditions`
   fires on every quiet thread and relies on the LLM to self-censor (it leaks onto non-leads).
   Typical gate for a setter: `program_interest = true` AND `<booking_prop> ≠ true`.

3. **Contact limits** (`list_contact_limits` → `upsert_contact_limit`) — at minimum the
   **terminal-stop limit** wired to the terminal boolean (e.g. `call_booked = true` → stop the
   agent), so the agent goes quiet once its job is done. Without this there is **no
   platform-level stop** — the prompt is the only thing keeping the agent from re-messaging.

4. **(Optional) Booking/handoff notification** (`upsert_custom_notification` + a
   `CUSTOM_NOTIFICATION` workflow) so the creator is alerted on the terminal event.

Confirm each with the user before writing (these are live DB changes). If the user defers any,
say so explicitly in the handoff — an agent shipped without the terminal contact limit and
data-gated follow-ups is a known-incomplete system, not a finished one.

## 9. Record
Write `agents/<name>/meta.md` (influencer_id, agent_id, use case, vertical, template) and
`agents/<name>/changelog.md` (`v0 — created via cortex-create`). Tell the user next steps:
`/cortex-analyze` for a baseline, `set_agent_status`/activation when ready, `/cortex-iterate` on feedback.

## Notes
- PATCH semantics: `deploy_agent_sdk` only writes changed fields; omitted = untouched, never nulled.
- Custom properties are set by an external evaluator — the SDK controls messages only. Defining them (+ the follow-ups and contact limit that gate on them) is **step 8, not optional**.
- Start from `_TEMPLATE/` (it already includes the no-visible-reasoning Principle 1) and use `agents/sample-*` as worked references for a vertical/motion close to the brief.

## When a tool fails or a capability is missing
Follow `knowledge/self-sufficiency.md` — diagnose, retry idempotent reads, try alternate tools, then report cause + next action. Never deflect to "do it in Ninjo". Skill-specific: if `create_agent` appears missing, it's the connection surface, not your role (`/mcp` exposes it — re-auth via `/mcp`), not a `get_me` permission issue (`mcp-tool-reference.md`). If `deploy_agent_sdk` returns `verified:false`/`partial:true`, capture `rollback_version_id` and `restore_prompt_version` before retrying. If `get_self_serve_data`/`trigger_fetch_info` are unavailable, proceed with partial data — note what's missing.
