myaiforone 1.0.0

package/agents/platform/gym/programs/agent-building/program.json

@@ -0,0 +1,160 @@
+{
+  "id": "agent-building",
+  "slug": "agent-building",
+  "title": "Agent Building",
+  "description": "Design, create, and configure specialized AI agents tailored to your real work.",
+  "difficulty": "intermediate",
+  "tier": "free",
+  "isPublic": true,
+  "isMarketplaceListed": false,
+  "dimensions": ["craft", "knowledge"],
+  "estimatedTime": "50-70 minutes",
+  "prerequisites": [],
+  "trainers": ["alex", "jordan", "morgan", "riley", "sam"],
+  "modules": [
+    {
+      "id": "anatomy-of-an-agent",
+      "title": "Anatomy of an Agent",
+      "order": 1,
+      "agentInstructions": "Ground the learner in the building blocks before they start building. Use the platform's own agents as examples — point them to real agent configs they can examine. Make the abstract concrete.",
+      "steps": [
+        {
+          "id": "what-makes-an-agent",
+          "title": "What makes an agent",
+          "order": 1,
+          "type": "knowledge",
+          "content": "An agent on this platform is built from five core components, and understanding how they fit together is the key to building agents that actually work well.\n\n**Workspace** is the agent's home directory — the folder it can read from and write to. A coding agent pointed at `/Users/you/projects/my-app` can see every file in that project. A general agent pointed at `~` has broad access but no deep context. The workspace determines what the agent can see and touch, so choosing the right one is your first and most important decision.\n\n**System prompt (CLAUDE.md)** is the agent's identity. It defines the agent's role, expertise, behavior rules, and constraints. A 2-sentence system prompt creates a generalist. A 200-line system prompt creates a specialist who knows your project's architecture, coding conventions, and communication preferences. The system prompt runs before every conversation, so everything in it shapes every response.\n\n**Tools** are the agent's capabilities. The platform offers Read, Write, Edit, Bash, Glob, and Grep. A code reviewer might only need Read, Glob, and Grep (read-only). A builder agent needs all of them. Restricting tools is a feature, not a limitation — it prevents accidents and keeps agents focused.\n\n**Memory** comes in two forms. Basic memory is the conversation history within a session. Advanced memory (`advancedMemory: true`) gives the agent long-term recall across sessions — it maintains daily journals and can search past interactions using vector similarity. Wiki learning (`wiki: true`) lets the agent extract and store facts in `learned.md` for persistent knowledge.\n\n**MCP integrations** connect the agent to external services — Slack, GitHub, databases, APIs. An agent with the GitHub MCP can create pull requests. An agent with the Slack MCP can post updates to channels. MCPs are what turn a smart text generator into a connected team member that can take action in the real world.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "An agent keeps hallucinating file paths that don't exist in a project. Which component is likely misconfigured, and how would you fix it?",
+            "You want an agent that monitors a codebase for issues but can't accidentally modify anything. Which tools would you enable and which would you disable?"
+          ]
+        },
+        {
+          "id": "agent-audit",
+          "title": "Agent audit",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Before building your own agent, let's study one that already exists. Go to the **Org** page (/org) and click on any agent to open its detail panel.\n\nExamine each component:\n- **Workspace**: What directory is it pointed at? Is it broad (like ~) or focused (like a specific project folder)?\n- **System prompt**: Read the CLAUDE.md. How detailed is it? Does it define a clear role? Does it have constraints?\n- **Tools**: Which tools does it have access to? Are there any that are disabled? Why might that be?\n- **Memory**: Does it have advanced memory or wiki learning enabled?\n- **MCPs**: Are any external integrations configured?\n\nIf you only have one agent (the hub), that's fine — the hub agent is actually a great case study because it has a detailed system prompt, specific tools, and MCP integrations. Study how its system prompt defines its role as the platform's primary conversational interface.\n\nTake note of what makes this agent effective (or what could be improved). You'll use these observations when building your own.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "new-agent-exists"
+        }
+      ]
+    },
+    {
+      "id": "your-first-specialized-agent",
+      "title": "Your First Specialized Agent",
+      "order": 2,
+      "agentInstructions": "This is where the learner creates something real. Push them toward a genuine use case from their work — not a toy example. Help them think through what problem this agent solves and who it serves. The creation itself should feel purposeful.",
+      "steps": [
+        {
+          "id": "choosing-a-purpose",
+          "title": "Choosing a purpose",
+          "order": 1,
+          "type": "knowledge",
+          "content": "The best agents solve a specific, recurring problem. Before you create one, let's find the right use case from your actual work.\n\n**Look for these patterns in your day:**\n- Tasks you do repeatedly that follow a similar pattern (weekly reports, code reviews, email drafts)\n- Projects where you need a dedicated assistant that remembers context across sessions\n- Workflows where you constantly context-switch between tools or information sources\n- Areas where you have expertise that could be encoded as instructions for an AI\n\n**Good agent candidates:**\n- A project-specific coding assistant pointed at your repo, with your coding standards in its system prompt\n- A meeting notes agent that summarizes recordings in your preferred format every time\n- A research assistant for a specific domain (legal, financial, medical) with domain terminology and constraints\n- A content writer with your brand voice, style guide, and audience profile baked in\n\n**Poor agent candidates (for now):**\n- Tasks you do once and never again — just use the hub agent for ad-hoc work\n- Tasks that require real-time data from services you haven't connected via MCP\n- Tasks where you don't yet know what \"good\" looks like — start with the hub agent to figure it out, then create a specialist\n\nThe litmus test: if you'd spend 2+ minutes re-explaining context to an AI every time you do this task, it's worth encoding that context in a dedicated agent.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What recurring task from your own work would make a good specialized agent? Why is it better as a dedicated agent than using the hub?",
+            "Why would a one-time task be a poor candidate for a specialized agent?"
+          ]
+        },
+        {
+          "id": "create-and-configure",
+          "title": "Create and configure",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Time to build. Go to the **Org** page (/org), click **+ New Agent**, and create your specialized agent.\n\n**Name it clearly.** The name should tell you (and other agents) exactly what it does. \"Code Reviewer\" is better than \"Helper.\" \"Q3 Marketing Writer\" is better than \"Writer.\"\n\n**Set the workspace.** Point it at the specific folder for its domain. If it's a coding agent, point it at the project root. If it's a writing agent, point it at the folder where your documents live. Be as specific as possible — a narrow workspace means the agent has deep context on exactly what it needs.\n\n**Choose tools deliberately.** Start with the minimum set of tools the agent needs:\n- **Read-only agents** (reviewers, monitors, analysts): Read, Glob, Grep\n- **Builder agents** (coders, writers, editors): Read, Write, Edit, Bash, Glob, Grep\n- **Cautious builders**: Read, Write, Edit, Glob, Grep (no Bash — prevents running arbitrary commands)\n\nYou can always add tools later. It's harder to undo damage from an overpowered agent than to grant additional permissions.\n\n**Write a description.** This shows up in the Org page and helps other agents understand what your agent does. One clear sentence is enough.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "new-agent-exists"
+        },
+        {
+          "id": "first-conversation-with-your-agent",
+          "title": "First conversation with your agent",
+          "order": 3,
+          "type": "platform-check",
+          "content": "Your agent exists — now let's put it to work. Go to the **Chat** page (/ui), select your new agent, and have a substantive conversation. Don't just test it with \"hello\" — give it real work.\n\n**For a coding agent:** Ask it to review a specific file, explain a function, or suggest improvements to a module. Send follow-up questions to test how well it understands the codebase context.\n\n**For a writing agent:** Ask it to draft something in your domain. Then ask for revisions. Then ask it to adapt the same content for a different audience. Test whether the system prompt's tone and style guidelines are working.\n\n**For any agent:** After 3-4 exchanges, try asking it something slightly outside its specialty. A well-configured agent should either handle it within its domain framing or honestly acknowledge it's outside its scope (if you added that constraint).\n\nSend at least 5 messages. Pay attention to whether the agent feels like a specialist or a generalist. If it feels too generic, that's a sign the system prompt needs more detail. If it feels too rigid, the constraints might be too tight.\n\nThis first conversation is diagnostic — you're not just using the agent, you're evaluating whether its configuration matches your intentions.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "message-count-gte-5"
+        }
+      ]
+    },
+    {
+      "id": "writing-an-effective-system-prompt",
+      "title": "Writing an Effective System Prompt",
+      "order": 3,
+      "agentInstructions": "System prompts are the highest-leverage skill in agent building. Share real patterns and anti-patterns. If the learner's system prompt is too short or too vague, push them to add specificity. A good system prompt is usually 50-200 lines.",
+      "steps": [
+        {
+          "id": "system-prompt-patterns",
+          "title": "System prompt patterns",
+          "order": 1,
+          "type": "knowledge",
+          "content": "Great system prompts follow predictable patterns. Here are the building blocks you should include, roughly in order:\n\n**Identity block** — Start with who the agent is. \"You are a senior frontend engineer specializing in React and TypeScript. You work on the Acme dashboard project.\" This sets the expertise level, domain, and scope.\n\n**Behavior rules** — Define how the agent communicates. \"Always explain your reasoning before showing code. Use TypeScript strict mode. Prefer functional components over class components. When unsure, ask a clarifying question rather than guessing.\" These rules prevent the most common frustrations.\n\n**Domain knowledge** — Embed facts the agent should always know. \"Our API uses REST with JWT auth. The main database is PostgreSQL. We deploy via GitHub Actions to AWS ECS. The design system uses Tailwind with custom tokens defined in tailwind.config.ts.\" This eliminates repetitive context-setting.\n\n**Format preferences** — Specify output structure. \"When reviewing code, use this format: (1) Summary of changes, (2) Issues found with severity, (3) Suggestions. Keep code snippets under 20 lines — link to files for longer blocks.\"\n\n**Constraints and guardrails** — Define boundaries. \"Never modify files in /config or /infrastructure without explicit confirmation. Don't suggest dependencies not already in package.json without explaining why. Never run destructive bash commands.\"\n\n**Anti-patterns to avoid:** Don't write a system prompt that's just \"Be helpful and answer questions\" — that's the default behavior anyway. Don't include contradictory instructions. Don't make it so long that critical rules get buried — put the most important constraints near the top.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What are the five building blocks of a system prompt, and which one would you write first for a brand-new agent?",
+            "Why should critical constraints go near the top of a system prompt rather than the bottom?"
+          ]
+        },
+        {
+          "id": "write-and-iterate",
+          "title": "Write and iterate",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Open your agent's detail panel on the Org page and write (or substantially improve) its CLAUDE.md system prompt. Aim for at least 30-50 lines that cover all five building blocks.\n\nStart with the identity block — one paragraph that defines the role, expertise, and scope. Then add 3-5 behavior rules that address how you want the agent to communicate. Include at least one section of domain knowledge — facts about your project, your preferences, or your workflow that the agent should always know.\n\nAdd format preferences for the agent's most common output types. If it writes code, define your style. If it writes prose, define your tone. Finally, add 3-5 constraints — things it should never do.\n\nAfter saving the system prompt, test it immediately. Send the agent a request and check:\n- Does it use the right tone and format?\n- Does it demonstrate the domain knowledge you included?\n- Does it respect your constraints?\n\nIf any of these are off, iterate. Adjust the wording, add more specificity, or move critical instructions higher in the prompt. Most system prompts need 2-3 rounds of refinement to feel right.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "agent-has-custom-prompt"
+        }
+      ]
+    },
+    {
+      "id": "tools-and-workspace-setup",
+      "title": "Tools and Workspace Setup",
+      "order": 4,
+      "agentInstructions": "This is the practical finishing module. Help the learner think about security and scope — the principle of least privilege applies to AI agents just like it does to software systems. A well-scoped agent is safer, faster, and more focused.",
+      "steps": [
+        {
+          "id": "understanding-tools",
+          "title": "Understanding tools",
+          "order": 1,
+          "type": "knowledge",
+          "content": "Each tool on the platform gives an agent a specific capability. Understanding what each tool does helps you configure agents that are powerful enough to be useful but constrained enough to be safe.\n\n**Read** — Read any file in the workspace. Essential for almost every agent. A code reviewer needs to read source files. A writing agent needs to read reference documents. This is the most commonly enabled tool.\n\n**Write** — Create new files or completely overwrite existing ones. Needed for agents that produce artifacts — generated code, reports, documents. More destructive than Edit because it replaces entire files.\n\n**Edit** — Make targeted changes within existing files. Safer than Write because it modifies specific sections rather than replacing entire files. Ideal for code agents that need to fix bugs or refactor.\n\n**Bash** — Run shell commands. The most powerful and most dangerous tool. Enables running tests, installing packages, executing scripts, and interacting with the system. Only enable this for agents you fully trust with your system.\n\n**Glob** — Find files by pattern (e.g., \"find all .tsx files in src/\"). Enables navigation of large codebases. Low risk, high utility.\n\n**Grep** — Search file contents for patterns. Combined with Glob, this lets agents explore and understand codebases. Read-only and safe.\n\n**The principle of least privilege:** Give each agent only the tools it needs. A monitoring agent needs Read + Glob + Grep. A builder needs all six. An analyst might need Read + Glob + Grep + Bash (for running analysis scripts but not modifying code). When in doubt, start restrictive and add tools as needed.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "You're building an agent that generates weekly reports by analyzing log files. Which tools would you enable and why?",
+            "Why is Bash the most dangerous tool? Give a scenario where an agent with Bash access could cause problems."
+          ]
+        },
+        {
+          "id": "configure-tools-and-workspace",
+          "title": "Configure tools and workspace",
+          "order": 2,
+          "type": "self-report",
+          "content": "Return to your agent's configuration on the Org page and fine-tune its tools and workspace setup for a real project.\n\n**Workspace audit:** Is your agent pointed at the right directory? If it's a project agent, it should point at the project root — not your home directory, not a parent folder. The tighter the workspace, the more relevant the agent's file operations will be.\n\n**Tool audit:** Review each enabled tool and ask: does this agent actually need this? If you enabled Bash but your agent only reads and analyzes code, remove Bash. If you enabled Write but your agent should only suggest changes (not make them), switch to Read-only tools.\n\n**Test the configuration:** After adjusting, test edge cases. Ask the agent to do something that should be outside its scope. Does it handle it gracefully? Ask it to work with files in its workspace. Can it find what it needs?\n\nIf you have time, consider creating a second agent with a different tool profile — perhaps a read-only version of the same agent for review purposes, while the original keeps write access for building. Having multiple agents with different permission levels for the same project is a common and effective pattern.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "self-report"
+        }
+      ]
+    }
+  ],
+  "createdAt": "2026-04-09T00:00:00Z",
+  "updatedAt": "2026-04-09T00:00:00Z"
+}

package/agents/platform/gym/programs/automations-mastery/program.json

@@ -0,0 +1,129 @@
+{
+  "id": "automations-mastery",
+  "slug": "automations-mastery",
+  "title": "Automations Mastery",
+  "description": "Build autonomous workflows — scheduled goals, agent delegation, and systems that work while you sleep.",
+  "difficulty": "intermediate",
+  "tier": "free",
+  "isPublic": true,
+  "isMarketplaceListed": false,
+  "dimensions": ["orchestration", "application"],
+  "estimatedTime": "40-55 minutes",
+  "prerequisites": [],
+  "trainers": ["alex", "jordan", "morgan", "riley", "sam"],
+  "modules": [
+    {
+      "id": "goals-and-scheduled-tasks",
+      "title": "Goals and Scheduled Tasks",
+      "order": 1,
+      "agentInstructions": "Automation is the bridge between 'using AI' and 'having AI work for you.' Start with the concepts, make sure the learner understands the heartbeat/budget model, then guide them to set up something real. Emphasize safety — autonomous agents need guardrails.",
+      "steps": [
+        {
+          "id": "what-are-autonomous-goals",
+          "title": "What are autonomous goals?",
+          "order": 1,
+          "type": "knowledge",
+          "content": "An autonomous goal turns an agent from something you talk to into something that works independently on your behalf. When you set a goal on an agent, it wakes up on a schedule, does its work, and reports back — without you sending a single message.\n\n**How goals work:** A goal has three parts: the **objective** (what the agent should accomplish), the **heartbeat** (how often it runs — e.g., every hour, every day at 9am), and the **budget** (how many messages it can send per run to prevent runaway execution). When the heartbeat fires, the agent receives its objective as a prompt, works through it using its tools and MCPs, and posts a status update.\n\n**The budget is your safety net.** An agent with a goal of \"review all open PRs\" and a budget of 20 messages will process what it can within 20 messages, then stop. Without a budget, a misconfigured goal could run indefinitely, consuming API credits and potentially making unwanted changes. Start with conservative budgets (10-20 messages) and increase as you build trust.\n\n**Reporting** keeps you in the loop. When a goal runs, the agent sends a summary to its configured notification channel (usually Slack). You get a digest of what it did, what it found, and whether anything needs your attention. This is how you maintain oversight without micromanaging.\n\nGoals are the foundation of autonomous workflows. Once you're comfortable with a single agent running a single goal, you can compose multi-agent systems where one agent's output triggers another agent's work.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What are the three parts of an autonomous goal, and why is the budget important for safety?",
+            "How would you know if an autonomous agent completed its work or ran into problems?"
+          ]
+        },
+        {
+          "id": "cron-jobs-and-schedules",
+          "title": "Cron jobs and schedules",
+          "order": 2,
+          "type": "knowledge",
+          "content": "Cron expressions control when your automations fire. They look cryptic at first, but the pattern is simple: **minute hour day-of-month month day-of-week**.\n\n**Common patterns you'll actually use:**\n- `0 9 * * 1-5` — Every weekday at 9:00 AM (great for daily standup reports)\n- `0 */4 * * *` — Every 4 hours (good for monitoring tasks)\n- `0 9 * * 1` — Every Monday at 9:00 AM (weekly summaries)\n- `30 17 * * 5` — Every Friday at 5:30 PM (end-of-week reviews)\n- `0 0 1 * *` — First day of every month at midnight (monthly reports)\n\n**When to use scheduling:** Not everything should be automated. Good candidates are tasks that are predictable, repeatable, and time-based. Bad candidates are tasks that depend on unpredictable triggers or require your judgment before proceeding.\n\n**Good automation targets:**\n- Daily code quality scans of your repo\n- Weekly project status summaries posted to Slack\n- Morning briefings that aggregate your calendar, tasks, and unread messages\n- Nightly data backups or log analysis\n\n**Poor automation targets (for now):**\n- Responding to customer complaints (needs human judgment)\n- Making financial decisions (too much risk)\n- Tasks that vary wildly each time (no repeatable pattern)\n\nThe platform's cron system uses standard cron syntax via node-cron. You configure schedules in the agent's settings or via the API. Each cron job specifies the agent, the message to send, and the schedule.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "Write a cron expression for a task that should run every Tuesday and Thursday at 10:00 AM.",
+            "Give an example of a task that's a good automation candidate and one that's a poor candidate. Explain why for each."
+          ]
+        },
+        {
+          "id": "create-your-first-automation",
+          "title": "Create your first automation",
+          "order": 3,
+          "type": "platform-check",
+          "content": "Time to set up a real automation. Go to your agent's settings and create either a goal or a cron job — whichever fits your use case.\n\n**Option A: Create a goal.** Pick an agent with a specific purpose and set an objective it can work toward autonomously. Example objectives:\n- \"Review the git log for today's commits and summarize what changed\"\n- \"Check for any TODO comments in the codebase and list them with file locations\"\n- \"Read the latest entries in the project log and draft a status update\"\n\nSet the heartbeat to something reasonable (daily or every few hours) and the budget to 10-15 messages.\n\n**Option B: Create a cron job.** Set up a scheduled message that fires on a regular basis. Examples:\n- A Monday morning message: \"Summarize what happened last week and what's planned for this week\"\n- A daily check: \"Scan the error logs and report anything unusual\"\n- An end-of-day recap: \"List all files that were modified today with a brief description of changes\"\n\nStart simple. You can always make it more sophisticated later. The important thing is to experience the loop: set it up, let it run, review the output, and iterate on the instructions.\n\nAfter creating the automation, verify it's active in the platform. You should see it listed in the agent's configuration or on the admin dashboard.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "automation-exists"
+        }
+      ]
+    },
+    {
+      "id": "agent-to-agent-delegation",
+      "title": "Agent-to-Agent Delegation",
+      "order": 2,
+      "agentInstructions": "Multi-agent coordination is where the platform's real power shows up. Keep it conceptual first — the learner needs to understand routing and @mentions before designing complex chains. Use concrete examples from their agent roster if possible.",
+      "steps": [
+        {
+          "id": "how-agents-work-together",
+          "title": "How agents work together",
+          "order": 1,
+          "type": "knowledge",
+          "content": "A single agent is useful. Multiple agents working together are transformative. The platform supports several patterns for agent-to-agent coordination.\n\n**@Mention routing** is the simplest form. When one agent's response includes `@agentname`, the platform routes that message to the mentioned agent. This enables chains: your hub agent can say \"Let me hand this to @codereview for analysis\" and the code review agent receives the task. The response flows back through the hub to you.\n\n**Group agents** coordinate multiple specialists under one interface. A group agent doesn't do the work itself — it routes subtasks to the right specialist based on the request. Think of it as a project manager that delegates to team members.\n\n**Hub orchestration** is the default pattern on this platform. The hub agent (@hub) is your primary interface. It knows about all other agents and can delegate work to them. When you message the hub with a complex request, it can break it down and route parts to different specialists.\n\n**Cross-agent sessions** let agents share context. When Agent A delegates to Agent B with a `targetAgentId`, Agent B receives the conversation context and can respond in the same thread. This prevents the \"telephone game\" problem where context gets lost in handoffs.\n\nThe key insight is that agents don't need to be individually brilliant — they need to be well-coordinated. A team of focused specialists, each with a narrow workspace and deep system prompt, will outperform a single generalist agent trying to do everything.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "Describe a scenario where agent-to-agent delegation would be more effective than using a single powerful agent.",
+            "What's the 'telephone game' problem in multi-agent systems, and how do cross-agent sessions help solve it?"
+          ]
+        },
+        {
+          "id": "design-a-delegation-chain",
+          "title": "Design a delegation chain",
+          "order": 2,
+          "type": "self-report",
+          "content": "Let's design a multi-agent workflow on paper before building it. Think about a complex task from your work that involves multiple steps or multiple types of expertise.\n\n**Example workflow — weekly project review:**\n1. @projectbot scans the repo for recent changes and creates a change summary\n2. @codereview analyzes the changes for code quality issues\n3. @writer drafts a stakeholder-friendly update combining the summary and review findings\n4. The hub agent delivers the final update to you (or posts it to Slack via MCP)\n\n**Your turn.** Design a 3-4 step delegation chain for your own use case. For each step, define:\n- Which agent handles it (existing or one you'd create)\n- What input it receives\n- What output it produces\n- Where the output goes next\n\nDon't worry about implementing this yet — the goal is to think in terms of agent teams rather than individual agents. Consider: where are the handoff points? What context needs to transfer between agents? What happens if one agent in the chain fails?\n\nReflect on your design. Is there a step where a human checkpoint would be valuable? (Hint: there usually is, especially in the early days.) Building in human review points is a sign of maturity, not weakness.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "self-report"
+        }
+      ]
+    },
+    {
+      "id": "while-you-sleep",
+      "title": "While You Sleep",
+      "order": 3,
+      "agentInstructions": "This is the capstone — putting it all together. The learner should leave with a mental model for end-to-end autonomous workflows. Encourage them to think big but start small. The best autonomous workflows start as manual processes that get gradually automated.",
+      "steps": [
+        {
+          "id": "autonomous-workflows",
+          "title": "Autonomous workflows",
+          "order": 1,
+          "type": "knowledge",
+          "content": "An autonomous workflow combines everything you've learned: scheduled goals that fire on a cron, agents that delegate to each other, and reporting that keeps you informed. The result is a system that works while you're away and presents you with results when you return.\n\n**The anatomy of an autonomous workflow:**\n1. **Trigger** — A cron schedule or event that kicks things off (e.g., every morning at 8am)\n2. **Execution** — One or more agents work through their objectives, potentially delegating to specialists\n3. **Reporting** — Results are posted to a notification channel (Slack, Telegram, etc.)\n4. **Human review** — You review the output, approve actions, or provide feedback\n5. **Iteration** — Based on your feedback, you refine the agents' instructions and constraints\n\n**Monitoring is essential.** Autonomous doesn't mean unsupervised. Check your notification channels regularly, especially in the first week. Look for:\n- Tasks that ran but produced poor results (refine the system prompt)\n- Tasks that exceeded their budget (increase budget or narrow the scope)\n- Tasks that didn't run at all (check the cron expression and agent status)\n- Tasks that produced unexpected side effects (tighten constraints and tools)\n\n**The trust ladder:** Start with low-stakes, read-only automations (monitoring, reporting, analysis). As you verify the output quality, gradually add write capabilities and expand scope. Don't jump straight to \"agent autonomously deploys code\" — build up to it through a series of increasingly trusted automations.\n\nThe goal is to reach a state where your agents handle the predictable work, escalate the exceptions to you, and continuously improve through your feedback.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What's the 'trust ladder' approach to autonomous workflows, and why is it important?",
+            "Name three things you should monitor in the first week after setting up an autonomous workflow."
+          ]
+        },
+        {
+          "id": "build-a-workflow",
+          "title": "Build a workflow",
+          "order": 2,
+          "type": "self-report",
+          "content": "Design a complete autonomous workflow for your real work. This is a capstone exercise that brings together goals, schedules, delegation, and monitoring.\n\n**Write out your workflow with these sections:**\n\n1. **Purpose**: What does this workflow accomplish? What problem does it solve?\n2. **Trigger**: When does it run? (Include the cron expression.)\n3. **Agents involved**: Which agents participate? What's each one's role?\n4. **Execution steps**: What happens in order? Who delegates to whom?\n5. **Reporting**: Where do results go? What format should the summary be in?\n6. **Safety guardrails**: What budgets, constraints, and human checkpoints are in place?\n7. **Success criteria**: How will you know this workflow is working well?\n\n**Start small.** Even if your ultimate vision is complex, describe a v1 that you could set up today with the agents and tools you currently have. You can always add complexity in v2.\n\nAfter writing out the workflow, reflect: what's the riskiest step? Where would you want a human checkpoint? What could go wrong, and how would you detect it? These questions are what separate a thoughtful automation from a reckless one.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "self-report"
+        }
+      ]
+    }
+  ],
+  "createdAt": "2026-04-09T00:00:00Z",
+  "updatedAt": "2026-04-09T00:00:00Z"
+}

package/agents/platform/gym/programs/getting-started/program.json

@@ -0,0 +1,124 @@
+{
+  "id": "getting-started",
+  "slug": "getting-started",
+  "title": "Getting Started",
+  "description": "Your first steps with AI agents — from your first conversation to creating your own specialized agent.",
+  "difficulty": "beginner",
+  "tier": "free",
+  "isPublic": true,
+  "isMarketplaceListed": false,
+  "dimensions": ["application", "knowledge", "craft"],
+  "estimatedTime": "30-45 minutes",
+  "prerequisites": [],
+  "trainers": ["alex", "jordan", "morgan", "riley", "sam"],
+  "modules": [
+    {
+      "id": "meet-your-ai",
+      "title": "Meet Your AI",
+      "order": 1,
+      "agentInstructions": "Start here. Make sure the learner understands what agents are conceptually before they start using them. Keep it conversational, not lecture-like.",
+      "steps": [
+        {
+          "id": "what-is-an-agent",
+          "title": "What is an agent?",
+          "order": 1,
+          "type": "knowledge",
+          "content": "An AI agent is more than a chatbot. It's a persistent assistant with its own memory, workspace, tools, and personality. On this platform, each agent has:\n\n- **A system prompt (CLAUDE.md)** — instructions that define who it is and how it behaves\n- **A workspace** — a folder or project it can read and modify\n- **Tools** — abilities like reading files, writing code, running commands\n- **Memory** — conversation history and learned facts that persist across sessions\n- **MCP integrations** — connections to external services (Slack, GitHub, databases, etc.)\n\nThink of agents like team members. Each one has a specialty, their own desk (workspace), and their own set of tools. You can have a coding agent, a research agent, a writing agent — each optimized for different work.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What's the difference between an agent and a regular chatbot?",
+            "Name two things that make each agent unique (hint: think about what they know and what they can do)"
+          ]
+        },
+        {
+          "id": "first-conversation",
+          "title": "Your first conversation",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Time to actually talk to an agent. Go to the **Chat** page (/ui), pick any agent, and have a real conversation. Ask it to help you with something — don't just say 'hello'. Give it a task:\n\n- Ask it to explain something you're curious about\n- Ask it to draft an email or message\n- Ask it to help you think through a problem\n\nSend at least 5 messages back and forth. Get a feel for the rhythm of working with an agent.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "message-count-gte-5"
+        }
+      ]
+    },
+    {
+      "id": "give-it-context",
+      "title": "Give It Context",
+      "order": 2,
+      "agentInstructions": "This module is about prompt quality. Emphasize the before/after difference — users should feel the improvement in output when they provide better input.",
+      "steps": [
+        {
+          "id": "what-makes-good-prompt",
+          "title": "What makes a good prompt?",
+          "order": 1,
+          "type": "knowledge",
+          "content": "The quality of what you get from AI is directly proportional to the quality of what you give it. Here's what makes a prompt effective:\n\n**Context** — Tell it what you're working on and why. \"I'm preparing a quarterly report for my board\" is better than \"write a report.\"\n\n**Specifics** — Be precise about what you want. Format, length, tone, audience. \"Write a 3-paragraph summary in plain English for non-technical stakeholders\" beats \"summarize this.\"\n\n**Examples** — When possible, show it what good looks like. Paste in a previous version, a competitor's approach, or a template.\n\n**Constraints** — Tell it what NOT to do. \"Don't use jargon. Keep it under 200 words. Don't make up numbers.\"",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What are the four elements of an effective prompt?",
+            "Why is 'write a report' a weak prompt? How would you improve it?"
+          ]
+        },
+        {
+          "id": "try-detailed-prompt",
+          "title": "Try a detailed prompt",
+          "order": 2,
+          "type": "self-report",
+          "content": "Now put it into practice. Go to any agent and send a prompt that includes:\n\n1. **Context** — what you're working on\n2. **Specifics** — exactly what you want\n3. **Constraints** — what to avoid\n\nCompare the result to a vague version of the same request. Notice the difference.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "self-report"
+        },
+        {
+          "id": "upload-a-file",
+          "title": "Upload a file to your agent",
+          "order": 3,
+          "type": "platform-check",
+          "content": "Agents can work with files you upload. Try it:\n\n1. Go to any agent's chat\n2. Click the 📎 attachment button\n3. Upload a document, spreadsheet, image, or any file\n4. Ask the agent to analyze, summarize, or work with the file\n\nThis is powerful — instead of copy-pasting content, you can hand the agent the actual file and let it work directly with it.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "file-upload-used"
+        }
+      ]
+    },
+    {
+      "id": "make-it-yours",
+      "title": "Make It Yours",
+      "order": 3,
+      "agentInstructions": "This is the capstone module. The learner should leave with a working specialized agent. Help them think about what's genuinely useful for their work, not just a toy example.",
+      "steps": [
+        {
+          "id": "create-specialized-agent",
+          "title": "Create a specialized agent",
+          "order": 1,
+          "type": "platform-check",
+          "content": "Now create an agent that's built for YOUR work. Go to the **Org** page (/org) and click **+ New Agent**. Think about:\n\n- **What's one recurring task** you do that AI could help with?\n- **What project** are you working on that needs a dedicated assistant?\n\nExamples:\n- A \"Meeting Notes\" agent that summarizes your meeting recordings\n- A \"Code Reviewer\" agent pointed at your project repo\n- A \"Content Writer\" agent with your brand guidelines in its system prompt\n\nCreate the agent, give it a clear name and description, and point its workspace at a relevant folder.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "new-agent-exists"
+        },
+        {
+          "id": "write-system-prompt",
+          "title": "Write a system prompt",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Your new agent needs instructions. Its CLAUDE.md file is its personality and expertise. Go to the agent's dashboard and write a system prompt that tells it:\n\n- **Who it is** — its role and expertise\n- **What it should do** — its primary tasks\n- **How it should behave** — tone, format preferences, constraints\n- **What it knows** — domain context, key facts\n\nA good system prompt is like onboarding a new team member. The more context you give, the better it performs from day one.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "agent-has-custom-prompt"
+        }
+      ]
+    }
+  ],
+  "createdAt": "2026-04-09T00:00:00Z",
+  "updatedAt": "2026-04-09T00:00:00Z"
+}

package/agents/platform/gym/programs/mcp-integrations/program.json

@@ -0,0 +1,116 @@
+{
+  "id": "mcp-integrations",
+  "slug": "mcp-integrations",
+  "title": "MCP Integrations",
+  "description": "Connect your agents to the outside world — APIs, services, and tools via Model Context Protocol.",
+  "difficulty": "advanced",
+  "tier": "free",
+  "isPublic": true,
+  "isMarketplaceListed": false,
+  "dimensions": ["orchestration", "craft", "application"],
+  "estimatedTime": "45-60 minutes",
+  "prerequisites": [],
+  "trainers": ["alex", "jordan", "morgan", "riley", "sam"],
+  "modules": [
+    {
+      "id": "what-mcps-enable",
+      "title": "What MCPs Enable",
+      "order": 1,
+      "agentInstructions": "MCPs are what make agents truly powerful — they break the wall between the AI and the real world. Start conceptual, but quickly ground it in real integrations the learner can see on their own platform. Check which MCPs are already configured and use those as examples.",
+      "steps": [
+        {
+          "id": "beyond-the-local-machine",
+          "title": "Beyond the local machine",
+          "order": 1,
+          "type": "knowledge",
+          "content": "Without MCPs, an agent can only work with local files and run local commands. That's powerful, but it's limited to what's on your machine. **Model Context Protocol (MCP)** servers break that wall — they give agents the ability to interact with external services, APIs, and data sources.\n\nAn MCP server is a small program that exposes a set of **tools** to the AI agent. When you connect the GitHub MCP, your agent gains tools like `create_pull_request`, `list_issues`, and `get_file_contents`. When you connect the Slack MCP, it gains `send_message`, `list_channels`, and `search_messages`. The agent calls these tools just like it calls Read or Write — but instead of operating on local files, they operate on external services.\n\n**Three transport types:**\n- **stdio** — The MCP server runs as a local process. The agent communicates with it via standard input/output. Most common for locally-installed MCPs. Fast and reliable.\n- **HTTP** — The MCP server runs as a web service (local or remote). Communication happens over HTTP requests. Good for shared MCPs that multiple agents or users access.\n- **SSE (Server-Sent Events)** — A streaming variant of HTTP. The MCP server pushes real-time updates to the agent. Used for event-driven integrations.\n\n**How agents use MCPs:** In the platform's config, each MCP is registered globally with a name, command, and arguments. Individual agents then reference MCPs by name — an agent's `mcps` array lists which integrations it has access to. When the executor spawns the agent, it generates a temporary MCP config file and passes it to Claude with `--mcp-config`. The agent sees the MCP's tools as part of its available toolkit.\n\nThis architecture means you configure an MCP once and share it across as many agents as you want. A Slack MCP configured once can be used by your hub agent, your project bot, and your reporting agent — each one able to post messages and read channels.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "What's the difference between an agent's built-in tools (Read, Write, Bash) and MCP tools? Why would you use one over the other?",
+            "Explain the difference between stdio and HTTP transport types. When would you choose each?"
+          ]
+        },
+        {
+          "id": "survey-your-integrations",
+          "title": "Survey your integrations",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Let's see what you're already working with. Check your platform's current MCP configuration by going to the **Settings** page or the **MCP Docs** page (/mcp-docs).\n\nFor each MCP that's configured, note:\n- **Name**: What's it called in the config?\n- **Transport**: Is it stdio, HTTP, or SSE?\n- **Tools**: What capabilities does it provide? (The MCP docs page lists each tool with its description and parameters.)\n- **Which agents use it**: Which agents in your roster have this MCP in their config?\n\nIf you have MCPs like Slack, GitHub, or Linear configured, you're already in good shape. If you only have the platform's built-in MCP (the one that provides agent management, gym, and project tools), that's fine too — you'll learn how to add more.\n\nPay attention to the tools each MCP provides. Understanding what's available is the first step to building workflows that leverage external services. Many users discover they already have MCP tools that could automate tasks they're currently doing manually.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "mcp-configured"
+        }
+      ]
+    },
+    {
+      "id": "connecting-your-first-mcp",
+      "title": "Connecting Your First MCP",
+      "order": 2,
+      "agentInstructions": "Walk through the actual setup process step by step. The learner should leave this module with a working MCP connection. If they get stuck on auth or config, help them debug — MCP setup is where most people hit friction.",
+      "steps": [
+        {
+          "id": "mcp-setup-walkthrough",
+          "title": "MCP setup walkthrough",
+          "order": 1,
+          "type": "knowledge",
+          "content": "Adding an MCP to your platform involves three steps: **register the server**, **configure authentication**, and **assign it to agents**.\n\n**Step 1: Register the MCP server.** In your `config.json`, add an entry to the `mcps` object. Each MCP needs a name, command, and arguments. For a stdio-based MCP:\n```json\n\"my-mcp\": {\n  \"command\": \"npx\",\n  \"args\": [\"-y\", \"@example/mcp-server\"],\n  \"env\": { \"API_KEY\": \"your-api-key\" }\n}\n```\nFor an HTTP/SSE-based MCP, you specify the URL instead of a command.\n\n**Step 2: Configure authentication.** Most MCPs need API keys or tokens. These go in the `env` field of the MCP config. **Never hardcode secrets in system prompts or agent configs** — always use the MCP's env field, which is read at runtime and not exposed to the AI.\n\n**Step 3: Assign to agents.** Add the MCP name to the agent's `mcps` array in their config. Only agents that explicitly list the MCP will have access to its tools. This is intentional — you don't want every agent posting to Slack or creating GitHub issues.\n\n**Testing your MCP:** After configuration, the fastest way to test is to start a conversation with an agent that has the MCP assigned. Ask it to use one of the MCP's tools (e.g., \"List my Slack channels\" or \"Show my GitHub repos\"). If it works, you'll see the tool call in the response. If it fails, check: (1) is the MCP command correct? (2) are the env variables set? (3) is the MCP listed in the agent's config?\n\n**Common gotchas:** MCP servers installed via npx may need a first-run download. Some MCPs require specific Node.js versions. Environment variables with special characters need proper escaping. When in doubt, test the MCP command manually in your terminal first.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "Walk through the three steps to add a new MCP to your platform. What could go wrong at each step?",
+            "Why should API keys go in the MCP's env field rather than in an agent's system prompt?"
+          ]
+        },
+        {
+          "id": "connect-an-mcp",
+          "title": "Connect an MCP",
+          "order": 2,
+          "type": "platform-check",
+          "content": "Time to connect an MCP to your platform. Choose one based on the services you use:\n\n**Popular MCP options:**\n- **Slack MCP** — Post messages, read channels, search conversations. Great if your team uses Slack.\n- **GitHub MCP** — Create issues, read repos, manage PRs. Essential for development workflows.\n- **Linear MCP** — Manage tasks and project tracking. Good for product/engineering teams.\n- **Filesystem MCP** — Extended file operations beyond the built-in Read/Write tools.\n- **Memory MCP** — Persistent key-value storage for agents that need to remember structured data.\n\nIf you already have MCPs configured, add a new one you haven't set up yet. If you're not sure which to pick, the **Filesystem MCP** or **Memory MCP** are good starting points because they don't require external service accounts.\n\nAfter adding the MCP to your config:\n1. Restart the platform to load the new MCP\n2. Assign the MCP to at least one agent\n3. Start a conversation with that agent and ask it to use one of the MCP's tools\n4. Verify the tool call succeeds\n\nIf you run into issues, check the platform logs for error messages. The most common problems are incorrect command paths, missing environment variables, and agents that don't have the MCP in their config.",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "platform-check",
+          "check": "mcp-configured"
+        }
+      ]
+    },
+    {
+      "id": "building-agent-workflows-with-external-apis",
+      "title": "Building Agent Workflows with External APIs",
+      "order": 3,
+      "agentInstructions": "This is the advanced capstone. The learner should think about combining MCPs with tools and multi-step logic. Push them to design something that creates real value — not just a demo. Error handling and fallbacks are key topics here.",
+      "steps": [
+        {
+          "id": "workflow-design-patterns",
+          "title": "Workflow design patterns",
+          "order": 1,
+          "type": "knowledge",
+          "content": "The real power of MCPs emerges when you combine them with agent tools and multi-step workflows. Here are the patterns that work best in practice.\n\n**Pattern 1: Gather → Analyze → Act.** The agent uses an MCP to gather data from an external service, uses its local tools to analyze it, then uses another MCP (or the same one) to take action. Example: Read GitHub PRs (GitHub MCP) → analyze code changes for quality issues (Read + Grep tools) → post a review summary to Slack (Slack MCP).\n\n**Pattern 2: Monitor → Alert.** A scheduled agent uses an MCP to check a service on a regular basis and alerts you when something needs attention. Example: Every hour, check Linear for overdue tasks (Linear MCP) → if any are found, send a notification to Telegram (Telegram channel) with a summary and suggested actions.\n\n**Pattern 3: Transform → Distribute.** The agent takes input from one source, transforms it, and distributes it to multiple destinations. Example: Read a project status document (Read tool) → format it as a weekly update → post to Slack (Slack MCP) and create a GitHub discussion (GitHub MCP).\n\n**Error handling matters.** External APIs fail — they timeout, rate-limit, return unexpected data, or require re-authentication. Build your workflows to be resilient:\n- Include fallback instructions in the system prompt: \"If the Slack MCP fails, save the message to a local file for manual posting\"\n- Use conservative budgets so a failing MCP doesn't burn through retries\n- Set up monitoring so you know when an MCP-dependent workflow fails\n\n**Composing MCPs:** An agent can use multiple MCPs in a single conversation. The system prompt should define when to use which MCP. \"Use GitHub MCP for code-related operations. Use Slack MCP for team communication. Use Linear MCP for task tracking. Never create GitHub issues for non-code tasks — use Linear instead.\"",
+          "isCritical": true,
+          "trainerVariations": {},
+          "verification": "knowledge",
+          "verificationQuestions": [
+            "Describe the Gather → Analyze → Act pattern with a concrete example from your own work. What MCPs and tools would be involved?",
+            "Why is error handling especially important for MCP-based workflows compared to local-only agent tasks?"
+          ]
+        },
+        {
+          "id": "end-to-end-integration",
+          "title": "End-to-end integration",
+          "order": 2,
+          "type": "self-report",
+          "content": "Design and describe an end-to-end workflow that connects at least one external API (via MCP) to agent actions. This is your capstone for the MCP program.\n\n**Your workflow design should include:**\n\n1. **The problem it solves:** What manual process are you automating or what new capability are you creating?\n2. **External services involved:** Which MCPs does it use and what data flows in/out?\n3. **Agent configuration:** Which agent runs this workflow? What's in its system prompt to guide MCP usage?\n4. **Step-by-step flow:** Walk through each step from trigger to final output. Be specific about which MCP tool is called at each step.\n5. **Error handling:** What happens when an MCP call fails? What's the fallback?\n6. **Trigger mechanism:** Is this on-demand (user-initiated), scheduled (cron), or event-driven?\n\nIf you've already set up an MCP in the previous step, try to incorporate it into this workflow. Even a simple workflow like \"Read Slack messages → summarize → save to a local file\" demonstrates the integration pattern.\n\nAfter designing the workflow, try running at least part of it. Start a conversation with the relevant agent and walk through the steps manually. Does the MCP respond as expected? Does the agent combine MCP data with local tools effectively? Use this test run to refine your design.",
+          "isCritical": false,
+          "trainerVariations": {},
+          "verification": "self-report"
+        }
+      ]
+    }
+  ],
+  "createdAt": "2026-04-09T00:00:00Z",
+  "updatedAt": "2026-04-09T00:00:00Z"
+}