Adding Agents

A guide for getting Claude to build automation agents for you — like "every morning, count tomorrow's checkouts and post to Slack." Describe your idea in a sentence and Claude investigates, asks questions, and plans it with you. Also clarifies what only humans can do (approve, activate).

What is this?

The platform can run automation agents: small jobs that run automatically on a schedule — like "every morning, count tomorrow's checkouts and post the number to Slack."

Your part is to describe the automation in plain words and hand it to Claude. Claude then builds it by following the /add-agent-to-platform skill. A few steps, though, are deliberately human-only (so nothing goes live on its own).

Symbols on this page:

• 🤖 = a step you hand to your Claude (copy-paste the prompt)
• 👤 = a step you do by hand
• 🛠 = a step only an admin / owner can do (ask one if you can't)

This assumes Claude is already connected to the platform via MCP. If not, do Connect Claude (MCP) first.

What can an agent do? (three output types)

There are two ways it runs (the "route"). Usually DSL (follows fixed steps; normally no extra AI cost); only when judgment is needed does it use an LLM agent (token cost). You don't have to choose — Claude decides by looking at the task (when in doubt, DSL wins).

If you only want to move an existing app job onto the platform's schedule (the logic already lives in the app), Claude can use a minimal setup called trigger — almost no new code.

Before you start (prerequisites)

Adding an agent is not "one prompt and done." It's usually two tracks: a code change (PR) and governance setup. Claude writes the code; you review/merge it via the normal Minor Changes flow.

Step 1 — Plan it together with Claude 👤 → 🤖

You don't need to write a finished spec up front. Describe what you want to automate in a sentence or two, and Claude will (1) update the repo to the latest, (2) read the /add-agent-to-platform skill, (3) investigate this monorepo's conventions, the real data visible via MCP, and existing agents worth referencing, and (4) come back with feasibility and spec questions for you. You answer, and the implementation plan takes shape through the conversation.

Starting in Claude Code's Plan Mode lets you review and adjust the plan before any code or PR is written.

A one- or two-line idea is enough for "Automation I want to build." Three common shapes:

• Notify — every morning, tell staff on Slack how many rooms check out tomorrow
• Propose — auto-draft next month's shifts for a manager to approve and confirm
• Report — summarize last week's handover notes into key points

Notify vs. propose: notify just tells you in Slack and stops. Propose creates a draft that only takes effect after a human approves it in the console (nothing in production changes until then).

From here Claude asks its questions, folds in your answers, and settles the implementation plan (route / output / write_policy / data / schedule / how personal info is handled). Once you agree, it writes code and opens a PR (if needed) and drafts the instruction. The next section clarifies how much Claude can do and where the human's job begins.

Step 2 — What Claude (MCP) can do vs. what humans must do 🤖👤🛠

This is the key distinction. Claude (via MCP) can go as far as "draft and configure," but it cannot "approve" or "activate" — those are deliberately human-only for safety.

Why are approve and activate human-only? They're the safety valve that keeps an agent from going live on its own. Claude does the "prep"; a human always gives the GO. If you're not an admin, ask one for these two.

Step 3 — Test → schedule → Slack (finishing up)

Once the code (PR) is merged and the instruction is registered, three finishing steps remain.

① Test it first (Run now) 🛠 / 🤖

Don't jump straight to daily. Run it once by hand and check the result. A console admin does this with "Run now" (🛠). You can also have Claude check the result:

"0 results" can still be a success. By design it doesn't notify when there's nothing to report, so "nothing in Slack" doesn't always mean "broken." Check the run result first.

② Put it on a schedule 🤖 / 🛠

If the test looks good, set the run time. You can ask Claude (or use the console Schedule editor, 🛠):

For scheduled runs, the owner must have the worker turned ON (RUNNER_WORKER_ENABLED=true) (🛠). If it's set but not running, check this first.

③ Set the Slack channel 🛠 (console)

Decide which channel the notifications go to. The easiest way is to pick the channel from the list on the instruction page in agent-console — you choose it by name (no ID hunting; it's resolved to the correct ID under the hood).

Setting it via MCP (Claude) currently needs the channel ID (C… / G…) — MCP has no name→ID lookup yet. Get the ID from Slack's channel details → "Copy channel ID." To choose by name, the console picker is easier.

To post to a private channel, the owner must invite the bot to that channel (🛠). Public channels usually don't need this. If it's set but nothing arrives, suspect a missing invite.

Troubleshooting

Quiz

What's next

Once your agent is live, you'll eventually want to tune or fix it — "only flag it when the signal is strong," "run it earlier," "post somewhere else." That's a different (but just as Claude-guided) flow: see Modifying Agents.