Agent governance.
Keep the seats your reps like.

You are the person who carries the RevOps title at a Series A or Series B SaaS company. The team is two to six people, sometimes overlapping with marketing operations, sometimes shared with the sales engineering function. You own the stack the revenue team runs on. The existing seats are paid up, the integration graph is already wired, and the rest of the team has muscle memory for the dashboards they use every day. Switching tools wholesale would be a quarter of work that nobody is asking for.

What you do not have is a clean place for the agents your reps started running last year. They live in Claude desktop, in custom GPTs, in n8n flows, and in a Slack bot someone built in a hackathon. The actions do not share one organization scope, lifecycle model, or set of approval boundaries. Coil provides that governed product surface without asking you to migrate the system of record. The wedge is controlled execution, not the enrichment graph.

Putting agents in front of your existing stack solves the bandwidth problem. It creates four new problems, all of which sit on the RevOps desk. Naming them is the first step to fixing them.

1. Surface fragmentation.

The agents your reps run today talk to half a dozen tools through half a dozen ad-hoc integrations. One person uses a custom GPT that hits Apollo. Another uses Claude desktop with a homegrown MCP server. A third just pastes CSVs into ChatGPT. There is no unified surface and no single place to ask “what did our agents do last week.” Coil's agent API is the shared seat. The dashboard and JSON CLI operate the same authenticated, organization-scoped API for every approved operator on the team.

2. Agent governance.

Every agent your reps run is one prompt away from an irreversible operation. Bulk delete a segment, push a draft sequence live, change a sender domain. The standard answer in 2026 is to gate those operations on a human role. Coil organization API keys map machine callers to org:member; DELETE on scrapes and automations requires org:admin, and the role check returns 403 from the API rather than relying on a UI hide. See the security page for the full list of gated routes.

3. Lifecycle visibility.

RevOps needs to know whether a source run is queued, running, completed, failed, or cancelled; which recipe revision was admitted; and whether a downstream delivery succeeded. Coil exposes typed lifecycle records for those supported operations. It does not currently attribute meetings, opener variants, or revenue forecasts.

4. Vendor lock-in worry.

Adding a sixth tool to the stack feels like the wrong direction. The mitigation is that Coil exports complete lead runs through the dashboard, API, and CLI using a documented CSV contract. Scrape, automation, and general activity exports are not shipped yet, so keep those source records in the systems that already own them. If the experiment fails, the prospect data you brought into Coil can leave in a standard format while your team keeps the Clay and Apollo seats they were never going to give up anyway.

The reference deployment for a RevOps team has Coil next to the existing seats, not on top of them. The reps keep Clay for enrichment, Apollo for the contact database they like, Smartlead for sending, and whatever CRM is the system of record. Coil holds the agent layer.

Issuing keys. Admins create Coil organization API keys (theak_... format) from Coil for a machine identity. Keys are org-scoped, and the authenticated API resolves that organization before running supported work. Admins can list and revoke those keys from the organization settings surface.

Running work. Reps use the dashboard or an approved runtime through Coil's authenticated API or JSON CLI. Those callers run the prospect skill or the Sales Nav scraper, save recipes for the segments your team owns. An admin can publish a reviewed webhook automation, and a configured SmartLead connection can receive supported handoffs. Inspect the webhook delivery result through the automations. Current per-org and per-key limits use shared durable PostgreSQL buckets, so multiple app instances receive one atomic admission decision.

Gated writes. Destructive deletion and publication operations are admin-only. Deleting a scrape or automation requires an org:admin role, as does publishing reviewed recipes and automations. Organization settings have their own authenticated route contract and are not described as admin-only here. Machine callers without the required role get 403 on the gated operations. Reps who try to delete a shared record from an agent prompt get a clear error back, which the agent can hand off to you instead of looping on a failure.

Reviewing. Inspect the typed state on source, recipe, automation, and delivery records. A queued or accepted request is not terminal success; use the corresponding lifecycle or delivery result before treating downstream work as complete.

Start with one bounded source, one reviewed recipe, and one configured destination. Confirm the role gates, provider-spend boundary, terminal status, and delivery result before expanding the workflow.

If your existing Clay and Apollo seats are paid up and your team genuinely likes them, and there is no agent layer to govern yet because nobody is running prompts against your stack, do not add Coil. The wedge here is the agent traffic. If the agent traffic does not exist, the seat that governs it has no job to do. Revisit when the first rep starts running ChatGPT against your CRM and the audit gap shows up.

If you need rigorous multi-region data residency or a fully on-prem deployment, Coil is not there yet. Keep those requirements with the systems that already meet them.

The category framing lives in the agent-driven lead gen pillar. The agent surface is documented on the agent API page; automations and the gated-write story on the automations page. Organization scoping and role gates are covered in detail on the security page.