Should Clay run in our own workspace or the agency's?

The question usually comes up in the first ten minutes of a call, and it rarely comes from the person who booked the meeting.

It comes from IT. Or from the RevOps director who has been burned before. Elastic Path asked it on our very first call: "Can we use our Clay?" And right behind it, the real question: if we part ways, do we keep the data and the workflows?

That second question is the one that matters. Everything else on this page follows from it.

Why does it matter whose Clay workspace runs the enrichment?

It matters because the workspace is where the work lives. The tables, the waterfall logic, the prompts, the run history and the connection to your CRM all sit inside one workspace. Whoever owns the workspace owns the asset, and whoever holds the keys controls the data.

Here's what you actually build in a Clay project:

• Tables that hold your accounts, contacts and enrichment results.
• Waterfalls that try one data vendor after another until one finds the value.
• AI prompts that research, classify and write, tuned to your market.
• Rules that decide which records run, when, and what syncs back to your CRM.
• History of what was found, when, and from which source.

If all of that lives in an agency's workspace, you're renting it. The day the contract ends, you either negotiate to get it back or you rebuild it. I've seen teams pay for the same waterfall twice for exactly this reason.

What do you get by running Clay in your own workspace?

You get ownership, cost control and a clean security story. Your own workspace means your own vendor contracts and AI keys, so you see every cost directly. It means your IT team controls access. And it means anything a partner builds stays with you after the project ends.

Chaos put it in one sentence on our first call: "I want to enrich the data in our system." They wanted to use their own Clay and their own vendor contracts, with a vendor mix that changed by region. That's how we built it, inside their workspace, from day one. The full build is described on our Clay partner page.

Three things change when the workspace is yours:

• Costs are visible. When you connect your own vendor and AI keys, Clay stops charging Data Credits for those calls, and your providers bill you directly. On Chaos, running their own model keys gave the same enrichment for about one-tenth of the price. We break down the full cost picture in what a Clay waterfall enrichment project costs.
• Access is governed. Your admins decide who can see and edit which tables. Esko's team wanted us working inside their Clay with their own identities and their SOC 2 controls, so every action traced back to a named login they managed.
• The data stays put. Records never have to be exported to a partner's account and imported back. That's simpler for IT, and it removes a whole category of questions from the security review.

There's a data licensing angle too. A company we spoke with learned that their contact database provider restricts resale of its data. When a partner enriches records in its own workspace and hands them over, you have to ask whose license covered that data. When the vendor contract is yours and the workspace is yours, the answer is simple.

When does it make sense to use the agency's Clay workspace?

There are two good reasons: a short pilot before you've bought Clay, or a bridge while budget and approvals catch up. Both should come with a written plan for moving the tables and workflows into your own workspace, with a date on it.

A pilot to prove the data exists. Before you buy anything, it's fair to ask whether the data you need is even findable for your accounts. A partner can run a sample in its own workspace and show you the match rate and the cost per record. If the answer is good, you buy Clay and the build moves over. If it's bad, you saved yourself a subscription.

A bridge while budget catches up. Esko is a good example. Their Q4 money had to be spent as a one-time project, and their own Clay setup was planned for the following year. So the plan was explicit: RevOps Shop infrastructure in 2026, their own Clay in 2027, with the work built so it could move. The data project itself, about 25,000 net-new accounts with 90% or better valid emails, was scoped at 30 to 45 days.

What doesn't count as a good reason: "it's easier for the agency." Easier for whom?

How do you move Clay work from an agency's workspace into your own?

Ask for a handover plan before the project starts, not after it ends. The plan should list every table, waterfall, prompt and CRM connection, say how each one moves, and name the date. Then rebuild the vendor and AI connections with your own keys and run a sample to prove the results match.

A clean handover has five steps:

1. Inventory. Every table, every waterfall, every prompt and every sync rule, written down.
2. Accounts and keys. Your Clay workspace, your vendor contracts and your AI keys set up first, so nothing runs on borrowed credentials.
3. Rebuild or copy. Move the tables and workflows, then point each step at your own keys.
4. Sample and compare. Run the same sample through both and compare match rates before you switch.
5. Train the owner. Someone on your team should be able to change a prompt or add a vendor without calling the partner.

That last step is the one most teams skip. Elastic Path's team told us honestly, "I got lost in Clay." A workspace you own but can't operate isn't really yours either. Training is part of the build, not an extra. It's also why we price builds as fixed plays you can see on Implement Clay Today: you know exactly what you're getting and what you'll own at the end.

What should IT ask before a partner touches your Clay workspace?

IT should ask four questions: whose logins will the partner use, what can they see, where do the vendor and AI keys live, and what happens to access when the project ends. Good answers are named user accounts, the minimum access needed, your own keys, and access removed on the last day.

The best partners welcome these questions. We build in the client's own infrastructure on purpose: their Clay, their AI keys, their CRM, their governance. Nothing that could hold them hostage. That's not a slogan; it's the reason IT teams sign off faster.

A short checklist for your security review:

• Named logins for each partner user, never a shared account.
• Access limited to the tables the project needs.
• Vendor and AI keys owned by your company, stored in your workspace.
• A written list of every CRM field Clay can write to.
• Access removed, and keys rotated, when the engagement ends.

If you're starting a RevOps build on Clay, our Clay for RevOps page shows what we build inside your workspace and how the handover works.

Frequently asked questions

Does it cost more to run Clay in our own workspace?

Usually not, and often it costs less. You pay for your own Clay plan, but with your own vendor and AI keys you pay providers directly instead of buying Data Credits. On Chaos, their own model keys gave the same enrichment for about one-tenth of the price. The bigger saving is never paying to rebuild the work when a contract ends.

Can a partner build in our workspace without seeing all our data?

Yes. Give the partner named logins with access only to the tables the project needs. Keep the vendor and AI keys in your workspace under your company's accounts. Your admins can see every change, and you can remove access the day the project ends. Esko's team required exactly this, with their own identities and SOC 2 controls.

What if we already pay for a contact database?

Keep it and connect it. A waterfall can call your existing provider first and only fall through to other vendors when it finds nothing. Check your contract's terms on resale and sharing before a partner enriches records outside your workspace, because some providers restrict how their data can be passed on.

What should we own at the end of a Clay project?

Every table, waterfall, prompt and sync rule, running in your workspace on your keys, plus a person on your team trained to change them. If any piece only works through the partner's account or credentials, you don't fully own it yet. Ask for the handover list on day one so there are no surprises.

Is a partner's workspace ever the right long-term answer?

Rarely. It can make sense for a team with no one to own Clay at all, for a short pilot, or for a dated bridge while budget catches up. Even then, write the plan for moving into your own workspace into the contract, with a date, so the decision is yours and not the partner's.

Sources

• Chaos, Clay enrichment build, 2025 to 2026: "I want to enrich the data in our system," their own Clay and vendor contracts, a vendor mix by region, and their own model keys at about one-tenth of the price. See our Clay partner page.
• Elastic Path, first call, December 2025: "Can we use our Clay?", whether they keep the data and workflows if we part ways, and "I got lost in Clay."
• Esko, data intro and Q4 project, September 2026: working inside their Clay with their identities and SOC 2, RevOps Shop infrastructure in 2026 and their own Clay in 2027, about 25,000 net-new accounts with 90% or better valid emails, and a 30 to 45 day scope.
• RevOps Shop discovery work, 2026: a contact database provider that restricts resale of its data.
• Clay, Actions and Data Credits documentation: connecting your own API keys removes the Data Credit cost for those calls, and your provider bills you directly.
• Clay, waterfall enrichment: how a waterfall checks providers in order until one returns a match.
• RevOps Shop, Implement Clay Today and Clay for RevOps.