Agents Platform operating model

The routine is the central entity for repeatable and autonomous operation on the Agents Platform. A routine owns the durable workflow: its steps, control flow, inputs, models, schedules, triggers, progress, results, and recovery boundary. Agents, skills, connectors, knowledge, and models exist to give those steps the capabilities they need.

Conversations still matter. Use them for ad-hoc work, discovery, prototyping, inspection, approvals, debugging, and reading run results. When a process must run reliably again—on another record, on a schedule, or after an event—promote it into a routine.

What supports a routine

Primitive	Its role in a routine-first system
Routine	The durable orchestration definition and unit of autonomous operation
Agent and model	The worker and model that execute each leaf step
Skill	Reusable instructions, scripts, and references used by an agent step
Connector or tool	Controlled access to an external system or a Sales Platform domain
Knowledge	Account-scoped context an enabled agent can retrieve while executing a step
Schedule or trigger	The activation rule for a validated routine
Conversation	The human-facing record for ad-hoc work, run progress, results, review, and debugging

An agent can still answer a one-off question without a routine. The routine becomes central when the work is a business process rather than a single conversation turn.

Configuration plane and runtime plane

For almost all non-trivial setup, use Claude Code or Codex as the configuration and prototyping plane. The external coding agent can spend the long, expensive setup session inspecting the account, configuring both platforms, authoring YAML, validating it, and running a bounded preview. MyChatBot remains the system of record and later runs the finished workflow with the selected production models.

Claude / Codex — configuration and prototyping plane
        │
        ├── Agents MCP → agents, skills, connectors, knowledge, routines
        └── Sales MCP  → assistants, clients, channels, CRM, knowledge
        │
        ▼
Validated, disabled routine
        │
        ▼
Agents Platform — production orchestration plane
        │
        ├── agents/models execute steps
        ├── skills implement reusable logic
        ├── connectors access external systems
        └── Sales connectors/MCP read or modify Sales Platform resources
        │
        ▼
Sales Platform — customer conversation and CRM runtime

In the current Agents MCP contract, saving the validated routine and activating it are separate concerns: newly created schedules and triggers are guaranteed disabled until a separate enable operation. The routine definition itself can also be turned off in the app when you need to prevent manual runs. In the diagram, “disabled routine” means this staged, non-automating state—not a claim that create_routine accepts an enable flag.

The external Sales-Management MCP is how Claude or Codex configures and tests Sales Platform primitives during setup. At production runtime, routine steps normally reach those same account-scoped primitives through an enabled Sales Platform connector/tool on the executing agent. This is one workflow and one set of records—not a second Sales configuration format.

From copilot to autopilot

Use this promotion lifecycle:

1. Describe the business outcome to Claude or Codex, including representative volume, allowed reads and effects, completion criteria, and desired cadence.
2. Inspect before writing. The coding agent reads the Agents inventory and the relevant Sales domains, then reuses existing agents, skills, knowledge, and connectors.
3. Prototype in the subsidized harness. Let Claude or Codex perform the lengthy setup, reason about the workflow, and test bounded Sales reads or controlled effects.
4. Author one canonical routine. Validate the YAML accepted by the MyChatBot editor and runtime; do not translate it into another workflow format.
5. Preview orchestration. Run a small, billed, tool-free preview to prove branches, loops, foreach, hand-offs, and output shapes.
6. Perform a narrow live check. Exercise real connector reads and only deliberately authorized effects against controlled data.
7. Stage automation disabled. Create its schedule or trigger disabled, then review the final routine, cost/volume bounds, cursor or idempotency state, and stop/recovery instructions.
8. Promote to autopilot. Enable its schedule or supported trigger so the Agents Platform runs it with the selected production agents and models.

The built-in YAML editor remains valuable for reading the executable definition and making small repairs. It is not the normal workspace for designing a complex routine from scratch.

The Sales Platform boundary

The Sales Platform remains the runtime for customer conversations and its native follow-ups. It owns customer channels, chats, clients, pipeline state, orders, and the native rules that keep an individual sales conversation moving.

The Agents Platform owns higher-level orchestration around those processes: periodic reviews, enrichment, batch processing, cross-system coordination, reporting, content, and controlled changes across many Sales records. Data and actions currently flow from an Agents routine into the Sales Platform through Sales tools. They do not natively flow back as an Agents trigger.

Agents routine ──read/write through Sales tools──▶ Sales Platform
Sales Platform ──no native event bridge today──X▶ Agents routine

This boundary does not prevent an Agents routine from reading customer replies or pipeline changes. It determines how the routine notices them.

Feedback loops today

Native Sales Platform events cannot currently start an Agents routine. External connector events—such as Stripe, Gmail, GitHub, Slack, or another supported connected app—can use app-event triggers. A service can also call a routine's secret webhook trigger.

For feedback that exists only inside the Sales Platform, use a scheduled polling routine:

1. Run on a deliberate cadence.
2. Read a bounded page of Sales records changed since a stored timestamp, cursor, or stable high-water mark.
3. Process each record with bounded foreach concurrency.
4. Record stable identifiers so a retry does not repeat an effect.
5. Advance the cursor only after the page is durably complete.
6. Continue through pages until the run reaches its explicit limit or no records remain.
7. Report partial failures so a later run can retry only unfinished items.

Do not simulate a Sales event trigger by requesting every chat or client in one unbounded call. Pagination and the total-record loop belong in the routine or its skill script.

A native Sales → Agents event bridge is a future capability

If that bridge is added later, qualifying Sales events will be able to activate a routine directly. Until then, documentation and designs must not imply that a new Sales chat, customer reply, lead-stage change, or order automatically fires an Agents routine.

Choose the right execution path

Need	Use
A one-off question, investigation, or repair	An agent conversation
A repeatable multi-step or batch business process	A routine
Customer-facing conversation and native per-lead follow-up	Sales Platform runtime
React immediately to a supported external app event	An app-event trigger
React to state that exists only in the Sales Platform	A scheduled polling routine

See also

• Build routines with Claude or Codex — complete configuration and promotion path
• Routines — running and operating the central workflow entity
• Routine workflow map — choose control-flow constructs
• Working with the Sales Platform — platform ownership and scenarios
• MCP surface map — separate Agents and Sales configuration surfaces
• Triggers — supported activation sources and the current Sales boundary