The Operator Model
Iron is operated, not self-served. The agency runs the system; clients get a curated portal into their own subaccount. This shapes how the platform is built and how you should think about the API.
Three kinds of principal
Section titled “Three kinds of principal”| Principal | What they do |
|---|---|
| Agency operators | Run the whole stack across all subaccounts — attribution, analytics, ads, coaching, telephony, funnels. Have access to agency-only endpoints (cross-account reports, rate cards, rebilling). |
| Client users | Log into a custom-fit portal scoped to their own subaccount. Their view is restricted by role and data-scoping flags. |
| Agents | Automated principals (the setter agent, voice agents, the MCP server) that drive CRM work programmatically. Every write they make is attributed. |
Actor attribution
Section titled “Actor attribution”Records carry actor attribution so you can always tell who (or what) created or changed them. The convention for the actor string is:
user:{uuid}— a human operator or client.agent:{name}— an automated agent (for exampleagent:setter).api:{id}— a programmatic API caller (for exampleapi:mcp).system— internal system actions.
Contacts, opportunities, and custom-object records carry created_by / updated_by; the
activity timeline carries an actor on each row. A caller cannot forge a user: identity — the
X-Actor override is only honored for api:* / agent:* / system actors.
Agents and the MCP server
Section titled “Agents and the MCP server”Iron ships a first-party MCP (Model Context Protocol) server that wraps /api/v1 for
agents. It is an HTTP client of the API — so it reuses the same multi-tenant auth and org
scoping rather than bypassing it (an agent cannot read another org; the API returns 403).
The MCP surface covers org-scoped reads (contacts, conversations, pipelines, opportunities, the timeline, appointments, tags, custom fields, staff, billing, reports, automations, setter config, snapshots) and safe writes (create/update/delete a contact, tag, custom field, note, opportunity, stage move, booking, subaccount). Live-action tools — sending SMS or email, sending a message in a conversation, inviting staff — fire real outbound and are gated behind an explicit allow flag so they don’t send by accident.
Safety gates
Section titled “Safety gates”Some live actions are deliberately gated off by default and require an explicit go to enable:
- Setter auto-replies (autopilot mode) are off; the setter writes suggested drafts a human sends.
- Cold-SMS campaign sends are paused until enabled.
- Live Stripe charges run in test mode until the live-billing flip.
- Outbound-voice volume is gated.
Shipping code is free; flipping these live-action flags is a separate, deliberate step.