Jeff Brokaw

Your Agency’s AI Tool: What Does the Client Get?

Jeff Brokaw · Chief AI and Marketing Officer · · Agency AI series, part 3 of 5

Before you sell access to the AI tool your team uses, hand it to someone who didn’t build it. See whether they can finish the job without calling its creator.

Your team might configure software the client already owns, use an internal tool to deliver the work or give the client access to a system you operate. Before you price any of it, decide what you’re agreeing to deliver.

What should an agency include in an AI tool or service offer?

State whether the client is buying finished work, configuration of existing software, access to an agency tool or a system they will operate. Explain the agency’s contribution, the outside software required, where the work runs, who approves consequential actions and who maintains it. Identify what the client receives at handover and test that it works in the intended environment.

A client can own its content while subscribing to someone else’s application. A workflow can run in the client’s account while still depending on an agency’s code or an outside model. Spell out which arrangement you’re selling.

My October agency research includes 128 named product and offering records: platforms, modules, workflows and client implementations. I also documented 34 relationships between broader offerings and their components. Treating every name as a separate proprietary product would inflate the count.

For an agency leader planning 2027, the useful question is which of those things you should sell, who will use it and what you can keep delivering when a supplier changes something underneath it.

The research overview explains the selected 350-brand roster and the separate offer and client-work populations. This article examines its product and dependency findings. The full report remains private. Earlier articles cover AI-related agency offers and client AI systems and ongoing support.

What can an agency sell with AI?

Before you price a platform, decide which job you want your agency to own.

Offer What the client gets What your agency needs to deliver
Buy and configure existing software An existing product set up for a specific job Suitable settings, connected data, acceptance checks and people who can use it
Use an internal agency tool Finished work produced with your tool Reliable delivery and review; client access to the tool only if it is part of the offer
Sell access to a managed system A working service your agency operates Access, customer support, supplier costs, monitoring and a way to handle failures
Build a client-operated system A system deployed where the client will run it The agreed implementation, documentation, working connections and an operating handover

These can coexist inside one engagement. Buying a model API and writing custom retrieval around it is a build. Configuring an existing product can involve substantial specialist work. An internal tool can improve delivery without ever becoming a separate subscription business.

The mistake is pricing one row while promising another. A tool your staff understand may still require onboarding, permissions, billing and support before a client can use it. If those jobs have no owner, your proposed software business is still an internal tool with a login page.

The build-versus-buy guide asks whether a capability deserves a build at all. Here, the decision is what your agency will deliver once it chooses a route.

What did the 128 records show?

The product catalog has 21 records examined in depth and 107 reviewed at catalog level. That unequal depth limits the conclusions. It isn’t a census of 128 independent software businesses, and a branded name doesn’t establish original engineering or ownership.

For each record, the review asked seven questions about data, outputs, application code, models, operating control, exit and maintenance. Seven questions across 128 records produced 896 checks. The public material left 568 unanswered, or 63.4%.

Those are unanswered public-evidence checks, not a failure rate or proof that clients lack those rights. I didn’t inspect private agreements or test exports.

If you sell one of these offers, explain what the client gets before procurement has to drag the answers out of you. Name the software, the work your team adds and who keeps it running.

PUSH configured Claude for a recurring translation job

PUSH’s translation case describes a Claude Skill working inside The Stress Management Society’s own Claude organization. It takes text from a Canva training deck, translates it and puts translations through local-trainer review before they reach the deck.

The agency describes brand references for two audiences and a workbook where trainers can adapt individual lines. It also describes training the client’s team. The case says the workflow has been live since August 2026.

The contribution is easy to understand: applying the client’s language and brand requirements to a recurring production job, with the people who know the material reviewing it. The client doesn’t need to buy a new foundation model to get that work done.

PUSH published this account. I haven’t independently tested the workflow; the page doesn’t settle prompt ownership or report a revenue return.

An agency considering a similar offer should be able to demonstrate an approved example, an awkward source deck, a rejected translation and the correction process. Sell the completed job at the required standard. A list of models will not tell the buyer whether the team can deliver it.

Brafton describes a managed operation, not a standalone software purchase

Brafton AI Studio combines its contentmarketing.ai platform with strategists, editors and client participation. Its current FAQ explicitly says AI Studio is not positioned as a standalone product a client buys and runs alone.

That distinction makes the offer easier to assess. The buyer is evaluating the work and people delivered through the system, alongside the software. The named virtual specialists describe roles in that operation; their labels do not establish separate software platforms.

For an agency with useful internal tooling, this is an alternative to becoming a software vendor. Keep the tool inside a managed service if that is where it creates value. Price the work the client receives and the staff required to deliver it.

I’d ask a different set of questions before selling that same tool on its own. Can a client configure it without your best operator sitting beside them? Can they recover from a mistake? Does someone own support when three clients need help during the same deadline week?

A managed service can absorb judgment and exceptions through its team. A self-service product needs a deliberate way to handle them.

Outside models can sit underneath valuable custom work

At the electrical-distribution platform where I served as Chief AI Officer, the product had to turn emails, bills of materials and technical documents into quote candidates drawn from hundreds of thousands of products. Google Document AI helped parse manufacturer specification sheets. Retrieval, filtering and model routing determined what reached the language model. I added prompt caching so repeated calls could reuse shared context.

The commercial work included deciding how those pieces fit, writing the rebuild roadmap and setting pricing around customer usage. The engineers implemented the rebuild and cloud migration. The case study explains the product and workload results.

Google’s software was a dependency. The system still needed electrical attributes, common terminology, product filtering and review. Choosing an outside component did not remove those decisions.

For an agency, that is where a custom system can earn its place. Identify the business rules, connections and accepted output that the available products do not provide as required. Explain what your team added and how it will keep working. Using a familiar model doesn’t make the implementation trivial. To claim original engineering, show what your team added behind the branded interface.

Which AI tools could an agency buy or configure?

Use the client’s existing stack as the starting point. The options below illustrate different purchases, not a ranking or a hands-on comparison.

Job Option to investigate What the agency still has to establish
A repeatable assistant task using client materials Claude and a scoped skill or configuration The approved inputs, access, review and task-specific behavior
Customer-support automation Intercom Fin Which questions it may answer, how it hands off and how the client checks outcomes
Moving information and proposed actions between systems n8n The trigger, connections, approval step, retry behavior and operating owner
Building and operating a configurable AI application Dify The application, knowledge sources, model accounts, hosting and permitted commercial use

Fin is a useful example of why the billable unit deserves attention. Intercom’s outcome documentation lists different events, including resolutions, procedure handoffs and sales qualifications. Its listed qualification charge is different from the standard resolution charge. A supplier’s billable outcome may also differ from the client’s definition of a successful support interaction.

Run a trial with the mix you expect. A headline starting price can’t tell you the cost of the service you intend to run. Subscription seats, usage, channels and other required components belong in the estimate where applicable. Verify the selected plan with the supplier before quoting the client.

For automation, n8n’s License FAQ for the Community License (Sustainable Use License) distinguishes services that create and maintain workflows from hosting arrangements that let outside users build or configure workflows. It permits specified consulting and behind-the-scenes uses while placing restrictions on other commercial arrangements. Check the intended delivery model against the current terms before promising a white-label product.

Dify has its own source license. Read the license for the particular version and intended use; a public repository is not permission for every resale or hosting arrangement. Code availability, a paid cloud subscription and an agency’s implementation service are different purchases.

Your proposal should name the account holder and the supplier charges the client needs to keep paying. That helps the buyer compare the full service, and helps your team avoid quoting a fixed fee around an unbounded usage bill. The AI cost-per-customer guide goes deeper into the economics.

What should the client receive at handover?

“An export” needs an object attached to it. Exported content, a workflow definition, source code and a running application require different things.

n8n documents workflow export and import. It also warns that exported JSON can contain credential names or authentication headers. Treat the export as something to inspect before sharing, then reconnect the destination safely.

Dify’s app export documentation lists material left behind, including linked knowledge bases, credentials, logs and certain tools. An exported application package alone does not establish that the destination has everything needed to run the job.

An agency can make the handover concrete without handing over every piece of its business. Name what the client receives and demonstrate the promised operating arrangement. For a client-operated system, that means testing it with the intended administrator and accounts. For a managed service, it means showing how the client gets its agreed work and information without depending on one employee’s laptop.

Use these questions on a single workflow:

  • Which account holds the application and who can administer it?
  • Where are the approved source materials, instructions and business rules?
  • Which outside connections and subscriptions are required?
  • What can the client retrieve in a usable form, and what needs rebuilding or reconnecting?
  • Who handles a rejected output, failed connection or supplier change?

Put those answers in the proposal so the buyer can assess the arrangement before signing.

A one-week test before you turn the tool into an offer

Choose one recurring job a client would pay to have completed. Write down the input, accepted output, reviewer and operating arrangement. Pick an existing product or your current internal tool and run a small, authorized sample through that job.

For example, a proposed lead-review service could use HubSpot for the records, n8n to collect a permitted change and Claude to draft an explanation against agreed criteria. The reviewer would receive the source, proposed classification and reason. Approval would be required before a CRM change. A missing source would hold the record; bounded retries would alert the owner on failure and avoid duplicate writes. This is a proposed workflow, not a result from the agency study.

The reviewer’s daily action is to accept or reject the pending records and record why. At the end of the week, count accepted records, corrections, review time, failed runs and the full operating cost. Sales must define an accepted handoff. My AI lead-qualification article explains why a tool’s “qualified” label isn’t enough.

If you intend to sell a client-operated version, add a handover test: someone outside the build team runs the agreed sample in the destination environment and handles a failure using the instructions. Record the missing knowledge and connections before making the offer.

That gives you evidence about delivery and support. It does not prove a revenue lift in a week. Use the test to decide whether to keep the tool internal, sell a managed service or fund the additional work required for client operation.

What I’d fund for 2027

I’d fund a specific client job with a repeatable delivery process before funding a general-purpose agency AI platform. Let successful work reveal which configuration, code and operational knowledge is worth repeating.

My prediction is that an agency can compete with a configured product when it takes responsibility for a difficult job the client still needs done. That’s a commercial judgment, not a result measured by this review. On November 5, 2027, I’d test it against paid adoption, accepted work, repeat purchases and contribution after software, review and support costs. More named tools on agency websites would not settle it.

Before you put the tool in the proposal, have someone outside the build team try to use it. Price the work needed to get them through the job without calling its creator.

Frequently asked questions

Does an agency need proprietary AI software to sell AI services?

No. An agency can configure existing software, connect systems, prepare usable data or operate a managed service. Explain its contribution and the work it will deliver. A tool name or vendor badge does not establish what the agency built.

What is the difference between an internal AI tool and a client AI system?

An internal tool helps the agency perform its own work. A client system is used by the client’s staff or customers. Giving the client access introduces requirements such as onboarding, permissions, support and operating instructions that an internal tool may not yet satisfy.

Who owns an AI workflow built by an agency?

It depends on the object and the agreed arrangement. Client content, configuration, custom code, third-party software and model access can have different terms. Account administration alone does not establish ownership of the underlying software. Ask what the client receives and can operate.

Can an agency resell an AI tool it found on GitHub?

That depends on the actual source license, dependencies and intended use. Public source code does not automatically permit unrestricted resale, white-labeling or multi-client hosting. Check the particular version and get permission where the license requires it.

Can an agency white-label n8n or Dify?

Check the license for the version and delivery model first. n8n’s self-hosted Community License permits specified consulting and behind-the-scenes uses but prohibits offering n8n as-is with its branding removed, and restricts outside users building workflows. Dify’s source license requires written authorization for multi-tenant use and restricts changes to its frontend branding. Ask the supplier about commercial terms before promising a branded product.

What did the 63.4% unanswered finding measure?

The review ran 896 checks: seven questions across 128 named catalog records. Public material left 568 unanswered. It measured gaps in reviewed public evidence, not missing capabilities, absent client rights or a product failure rate. Only 21 records received deep review.

How should an agency test a client AI system before selling it?

Use an authorized sample with a defined accepted output. Measure corrections, review effort, failures and operating cost. Test the intended account arrangement, a human approval step and a failure recovery. For a client-operated system, have someone outside the build team complete the handover test.

Method and sources

The October 15 to 20, 2026 public-evidence review covered 350 selected agency brand/domain records, including marketing-technology specialists. The separate product catalog contains 128 named records, 21 examined deeply and 107 at catalog level, with 34 supported offering/component relationships. Seven questions produced 896 checks, with 568 unanswered. This is a selected, uneven-depth review of public material; it does not establish industry prevalence, private agreements or tested portability. See the public research method for the broader review.

Current product pages and documentation checked November 5, 2026: