AI workflow automation for agencies: who owns what you built

An agency automating its own delivery is one thing. An agency building automation for clients is a different business with questions attached that do not arise elsewhere: who owns what was built, whose account it runs in, what happens when the engagement ends, and how something that keeps working is paid for.

Those questions are answerable and they need answering before the first build rather than during the first disagreement.

What we'll cover

• Two different propositions
• Ownership, which must be explicit
• Whose account it runs in
• Building it with CodeWords
• Multi-tenancy and client separation
• Billing something that keeps running
• Handover and the end of an engagement
• Automating the agency itself
• Selling it without overpromising
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Two different propositions

Automating your own delivery improves margin and is entirely within your control.

Building automation for clients is a product-shaped service with support obligations attached.

They need different agreements, different pricing and different operational arrangements.

Conflating them is the common mistake, usually by building client automation on the agency's internal tooling.

Decide which you are selling before the first proposal, since the commercial structure follows from it.

Both are legitimate, and the second is considerably more demanding than it appears from the first engagement.

Ownership, which must be explicit

Write it into the agreement rather than leaving it to be assumed.

Who owns the workflow definition — the logic you built — which the client usually assumes is theirs.

Who owns the data flowing through it, which is almost always the client's.

Who owns the account it runs in, which determines what happens if the relationship ends badly.

Reusable components across clients need explicit treatment, or you have either given away your method or taken something you should not have.

Clients will ask eventually, typically at renewal or during a dispute, and a clear answer then depends on a clear answer now.

Whose account it runs in

The client's account is the cleaner arrangement — they own it, they pay for it, and ending the engagement does not break it.

Your account is simpler to build in and creates a dependency that has to be unwound.

Never use personal credentials, yours or an individual client contact's, which breaks when anybody changes role.

Service accounts on the client side, wherever possible, with your access granted and revocable.

Document what access you hold, since an agency holding standing access to a client's systems after an engagement is a security problem for both.

Plan the revocation as part of the handover rather than as an afterthought.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the client's process, what is monitored, and who is notified.
3. Authorize the connections in the client's own account with scoped service credentials.
4. Describe the exceptions: a failure, a credential expiry, a system unavailable, an unusual volume.
5. Hand over the documentation and the monitoring alongside the automation itself.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Multi-tenancy and client separation

Never let one client's data reach another, which is the failure that ends an agency's reputation.

Separate accounts or workspaces per client, not shared ones with filtering.

Separate credentials, so a compromise is contained.

Be careful with shared components. A reusable template is fine; a shared runtime holding several clients' data is a risk you are taking on their behalf.

Confidentiality obligations vary by client and some are strict about where their data may be processed.

Audit who at your agency can access what, periodically, since access accumulates as people move between accounts.

Billing something that keeps running

A build fee does not cover maintenance, and maintenance is where the cost lives.

Decide the ongoing arrangement before delivery: a retainer, a support agreement, or an explicit handover with no obligation.

"We built it and we will fix it if it breaks" is an unbounded commitment made casually and is the most common commercial error here.

Define what maintenance means — monitoring, fixes, changes, upgrades — since clients assume it includes all four.

Platform costs need an owner. Whether the client pays the platform directly or through you changes the relationship materially.

Price the availability expectation, because a client whose process depends on something you built will expect a response when it fails.

Handover and the end of an engagement

Documentation is the deliverable, as much as the automation.

Write it for somebody who has not met you, since that is who will read it.

Include the failure modes and what to do about each, which is the part clients most need and least often receive.

Transfer ownership formally — accounts, credentials, definitions — with a record of what changed hands.

Revoke your access and confirm it, which protects both parties.

Offer a support period rather than an indefinite obligation, which is clearer for everybody.

Automating the agency itself

The other half, and the one with the fastest return.

Proposal and scope assembly, from reusable components with the commitments left blank.

Time and utilisation reporting, which most agencies do badly and which determines profitability.

Client reporting, assembled rather than compiled, which is a recurring cost on every account.

Onboarding a new client: access, systems, kickoff, documentation.

Invoice and payment chasing, which is the administrative task agencies most consistently postpone.

Capacity planning, since the difference between a profitable and unprofitable agency is frequently utilisation rather than rates.

Selling it without overpromising

Automation sells easily, which is the risk — the proposal is written before anybody has looked at the client's data, and the gap surfaces during delivery.

Scope a discovery stage separately, since you cannot price the build before seeing what the systems actually expose.

Say what it depends on. A client whose identifiers are inconsistent across systems has a data project before they have an automation project.

Quantify carefully. A saving claimed in a proposal is a number you will be measured against, and it was estimated before you saw the process.

Be explicit about the review queue, because every real implementation has one and a client who was not told expects none.

Name what stays manual, in the proposal, rather than discovering it together in week three.

Decline the ones that are not ready, since an engagement built on a data problem the client will not fix ends badly for both sides.

Making it survive

Monitor what you built for clients, or you will find out it broke when they do.

Alert yourself as well as them, particularly during any support period.

Keep the documentation current as you change things, which is the discipline that fails first.

Test after client-side changes, since their systems change without telling you.

Report the outcome to the client, so the automation's value is visible rather than assumed.

Limits worth knowing about

Client systems are outside your control, including their changes and their outages.

Access can be revoked without notice by a security review you were not part of.

Client staff turnover means the person who understood it leaves, and the documentation becomes the only record.

Platform changes affect every client at once, which is a concentration risk for an agency.

You cannot support what you cannot see, so monitoring is a precondition for any availability commitment.

What to build first

The documentation and monitoring template, before the next client automation. Every engagement needs both, they are what makes a handover clean and an obligation bounded, and producing them from a template costs a fraction of writing them at the end of a project when the budget is spent.

Two habits make the difference. Build in the client's own account with scoped service credentials, since that single choice resolves ownership, handover and the security question at the same time. And define what maintenance means in writing before delivery, because "we will fix it if it breaks" is an unbounded commitment that clients reasonably interpret as covering monitoring, fixes, changes and upgrades.

Frequently asked questions

What is different about building automation for clients?

It is a product-shaped service with support obligations attached, rather than an internal efficiency improvement. It needs its own agreement, pricing and operational arrangement, and conflating the two is the common mistake.

Who owns what an agency builds?

Whatever the agreement says, which is why it must say. The workflow definition, the data, the account it runs in and any reusable components all need explicit treatment — clients will ask, typically at renewal or during a dispute.

Whose account should it run in?

The client's, with scoped service credentials and your access granted and revocable. It resolves ownership, handover and security simultaneously, and it means ending the engagement does not break the automation.

How should client separation work?

Separate accounts or workspaces and separate credentials per client, not one shared environment with filtering. A reusable template is fine; a shared runtime holding several clients' data is a risk taken on their behalf.

How should ongoing work be billed?

Decide before delivery — retainer, support agreement, or explicit handover with no obligation — and define what maintenance means, since clients reasonably assume it covers monitoring, fixes, changes and upgrades.

What is the most common commercial error?

Saying "we built it and we will fix it if it breaks". It is an unbounded commitment made casually, and it is open-ended in both scope and duration.

What should a handover include?

Documentation written for somebody who has not met you, including the failure modes and what to do about each, formal transfer of accounts and credentials, and confirmed revocation of your access.

What should an agency automate internally first?

Proposal assembly, time and utilisation reporting, client reporting, client onboarding, and invoice chasing. Utilisation rather than rates is frequently what separates a profitable agency from an unprofitable one.

How should an automation engagement be scoped?

With discovery priced separately, since the build cannot be estimated before seeing what the client's systems actually expose and how consistent their identifiers are across them.

What should a proposal say explicitly?

What stays manual, that there will be a review queue, and what the automation depends on. A client who was not told to expect a queue expects none, and that expectation surfaces in week three.

Related reading

• Automating proposal generation
• AI workflow tools and what each layer does
• AI integration software