Appearance

Build and test a routine with Claude or Codex ​

Describe the business outcome in plain language. Your coding agent inspects the account, writes and validates the workflow, shows you exactly what will be saved, and stages its schedule or trigger only after the routine is ready.

  • What you'll build — A custom MyChatBot routine using Claude Code or Codex and the account-scoped Agents MCP. The same process works for a two-step helper or a workflow that fans out across hundreds of records.
  • Who it's for — The person designing the process. You do not need to know YAML, agent slugs, connector schemas, cron syntax, or the available model aliases before you start.
  • Time & plan — About 20–40 minutes for a first useful version. You need an Agents balance; a preview calls models and is billed like an ordinary run.

Claude Code or Codex is the authoring workspace. MyChatBot remains the system of record and the runtime: its Agents MCP exposes the current routine contract and account configuration, while the saved routine runs on MyChatBot Agents.

This is the routine-first operating model: use the subsidized coding-agent session as the configuration and prototyping plane, stage a validated routine without active automation, then promote it to MyChatBot for durable production execution. The MCP guarantees that a new schedule or trigger starts disabled; you can also turn the routine definition off in the app to block manual runs. Conversations remain useful for inspection and debugging; the routine owns work that must repeat.

What Claude or Codex can set up ​

Through the Agents MCP, your coding agent can inspect and—after showing you the proposed change—configure:

  • custom and Library agents;
  • skills, including their instructions, scripts and references;
  • OAuth and Sales Platform connectors;
  • read-oriented Business Knowledge sources;
  • custom routine YAML;
  • disabled schedules and triggers, followed by a separate enable action.

The coding agent cannot receive connector secrets. An OAuth tool returns a consent URL for you to open; API keys and authenticated custom-MCP headers belong in the MyChatBot app. It also cannot use the Agents MCP to read your leads, emails, or other customer records.

1. Connect Claude Code or Codex ​

Open Agents, choose any Agent, open Tasks, and click Connect Claude or Codex. Create an access key and copy the setup for your client.

Claude Code:

bash
claude mcp add mychatbot-agents \
  "https://api.mychatbot.app/api/mcp/agents" \
  --transport http \
  --header "Authorization: Bearer mcp_YOUR_ACCESS_KEY"

Codex (~/.codex/config.toml):

toml
[mcp_servers.mychatbot-agents]
url = "https://api.mychatbot.app/api/mcp/agents"
http_headers = { Authorization = "Bearer mcp_YOUR_ACCESS_KEY" }
default_tools_approval_mode = "writes"

With writes, Codex can use discovery and validation tools automatically while asking before configuration changes, routine saves, billed previews, and cancellation.

Use the command generated for your account; do not paste the key into a prompt, document, repository, or screenshot. The key grants account-wide access to the narrow tools exposed by this MCP server. Revoke it through support if it is exposed.

2. Give the coding agent the outcome, not a guessed implementation ​

Start with the business rule, representative volume, allowed effects, and the definition of success. For example:

text
Build a routine that finds clients with no activity in 30 days, evaluates each
one, and produces an ordered action list. Expect 200–500 clients. It may read
Sales Platform data but must not message clients or change records in version 1.
Run it every Monday at 09:00 Europe/Kyiv, but leave the schedule disabled until
I approve the final result.

Use the MyChatBot Agents MCP. Inspect my existing setup before proposing new
agents, skills, knowledge, or connectors. Follow the complete routine authoring
and dry-run process, and explain any boundary the preview did not test.

This gives the coding agent room to reuse what already exists. Avoid prescribing an agent slug, model alias, or connector name unless it is a real requirement; the account inventory is the source of truth.

3. Make the coding agent inspect before it writes ​

It should perform this read-only discovery first:

  1. Call get_routine_authoring_context and read the Markdown URLs it returns, especially the complete Routine YAML reference.
  2. Call get_account_authoring_inventory.
  3. Call list_routines, then get_routine for anything it may reuse or change.
  4. Call get_agent or get_skill before proposing a full replacement.

The inventory lists effective agents and models, skill metadata, configured connector state, Business Knowledge metadata and trigger sources without returning credentials or contacting providers. The coding agent should prefer reusing these resources over creating near-duplicates.

A reusable starter prompt

The connection dialog includes a complete starter prompt with the required read-before-write, approval, validation and preview rules. The Agents MCP reference keeps the same prompt in copyable form.

4. Configure only what the routine needs ​

If something is missing, ask it to propose the smallest supporting change and wait for your approval before making it.

  • For OAuth, the coding agent calls start_connector_authorization; you open the returned URL and finish consent yourself.
  • For a Sales Platform domain, it can call connect_sales_platform_connector.
  • For a secret-bearing connector, it must direct you to the app. Never send the secret through an MCP argument or chat message.
  • A separately approved probe_connector performs a real connection handshake and lists tools. It does not invoke a tool or prove that customer data can be read or written.

Refresh the account inventory after a connection or configuration change.

When the workflow also uses the Sales Platform ​

Connect the Sales-Management MCP to the same Claude or Codex session for setup-time inspection and configuration of Sales assistants, clients, chats, channels, CRM, knowledge, outreach, and related primitives. Use the narrowest Sales area that fits; use the combined surface only for a genuinely cross-domain setup.

That external Sales MCP is part of the configuration plane. At production runtime, routine steps reach Sales through a Sales Platform connector or tool enabled on their executing MyChatBot agent. The Sales Platform continues to own customer conversations and native follow-ups. See Working with the Sales Platform.

5. Draft, validate and review the complete routine ​

The coding agent writes the same YAML accepted by the built-in editor. It should call validate_routine until valid: true, then show you:

  • the complete canonical YAML, not a summary or partial diff;
  • which Agent and model runs each leaf step;
  • the maximum static Agent-call estimate when calculable;
  • the effective foreach concurrency and nested parallel width;
  • every read, write, message, call, publication, schedule and trigger it expects;
  • any assumption it could not verify from inventory.

Approve create_routine or update_routine only after that review. The coding agent then calls get_routine_readiness and resolves every blocker before testing. Readiness checks references and configuration; it does not contact connector providers or inspect customer data.

6. Preview the workflow graph ​

Ask separately before the coding agent calls start_routine_dry_run. The preview is persisted in routine history, consumes Agents balance, and runs the real sequence, parallel, loop, condition, router, and foreach control flow—but AgentOS removes all tools, connectors, skills, Business Knowledge and account memory first.

Use the preview to test:

  • prompt hand-offs through {input} and {previous};
  • branch and route selection;
  • loop termination;
  • item aliases and result aggregation;
  • output shape and model quality.

Do not use it as evidence that Gmail, a CRM, Sales Platform data, or any external write works. A preview must have a statically calculable worst case of at most 25 Agent calls. For a dynamic batch, first save and preview the same routine with a two- or three-item literal foreach list, then update it to the real items: "{previous}" source and validate again.

7. Perform the narrow live check in MyChatBot ​

The Agents MCP deliberately has no “run live now” tool. When the preview looks right, open the routine in MyChatBot and run it once with the narrowest safe input that can exercise the real reads.

For a routine that will eventually write or message:

  1. keep the first live version read-only or draft-only;
  2. use sandbox/test data where the external provider supports it;
  3. inspect the routine history and connector results;
  4. add the explicit effect only after the read path is proven.

Routines never pause for approval

A routine that starts runs every step to the end. There is no approval card, no review pause, and no switch that turns one on — the mechanism was removed, not disabled.

approval, approval_message, requires_iteration_review and requires_output_review are still accepted so existing YAML keeps loading and saving, but none of them stops a run. If a routine of yours was written around a gate, treat that step as fully live and re-read its prompt.

So an owner-authored step does whatever its task says, including effects that reach real people — messages, calls, outreach, publication, deletion, live record changes. Writing the step is the authorization; there is no second checkpoint before a customer is contacted. Scope each prompt to exactly the action you want, and rehearse with a dry run (tools switched off) before you attach a schedule or trigger.

(Router requires_user_input is unrelated and still works: it supplies a branch choice the workflow needs, not permission to act.)

8. Stage automation, then enable it separately ​

Ask the coding agent to create the schedule or trigger only after the saved routine is ready. The MCP always creates it disabled, even if a prompt asks to enable it at creation time.

Review the staged resource:

  • correct routine and account;
  • cron and IANA timezone, or connector event and filters;
  • run message or event message template;
  • frequency and trigger rate limit;
  • live effects and expected cost at normal volume;
  • what the preview and live check did—and did not—prove.

Then give a separate approval for set_routine_schedule_enabled or set_trigger_enabled. Enabling a connector-event trigger may create a real subscription with the provider.

Sales-only state needs a schedule, not a trigger

Native Sales Platform events cannot currently start an Agents routine. If the business rule depends on a new Sales chat, customer reply, lead-stage change, or Sales order, stage a scheduled polling routine instead. Read bounded pages since a cursor or high-water mark, process them with bounded concurrency, and advance state only after durable completion. Supported external connector events and secret webhooks can still use triggers.

A good final handoff from the coding agent ​

Before you finish the authoring session, ask for a compact runbook:

text
Summarize the final routine, its agents and dependencies, validated limits,
expected calls per run, live effects, preview evidence, remaining untested
assumptions, schedule or trigger state, how to stop it, and how to retry only
failed batch items. Do not include credentials or secret URLs.

Keep that summary with the business owner. The routine YAML remains the executable source of truth in MyChatBot.

Pick an example ​

See also ​

Copyright © 2023–2026 MyChatBot