For AI service providers · Guide
How to choose an AI platform for your agency
Choose an agency AI platform with a fixed client acceptance case. Compare client access, tools, review, delivery, cost and handoff before deciding. Use vendor documentation to shortlist, then verify the intended plan in a trial. A workflow builder, conversation platform and client service-delivery platform may solve different parts of the job.
By Agentic Workers Team · Published · Updated
Responsibilities and evidence
Agree on the owner and retain a safe evidence reference for each responsibility.
- Service scope
- Provider drafts; client accepts. Evidence: agreed output and stop conditions.
- Account ownership
- Client and provider confirm owners. Evidence: account inventory without secret values.
- Configuration
- Provider sets up the intended workspace and agent. Evidence: reviewed settings.
- Action review
- Named reviewer checks supported actions. Evidence: request and decision.
- Acceptance
- Client or delegated reviewer checks the result. Evidence: accepted artifact.
- Exit
- Account owner and provider remove access. Evidence: handoff and denied-access check.
1. Define the client question
Choose a report, support conversation or app workflow the client needs. Write the input, expected output, reviewer and destination. Decide which capabilities are required and which are optional before reading comparison rankings.
2. Collect dated evidence
Record each claim with its source, checked date and evidence type. Distinguish documentation from a demonstration and from your own test. Unknown means not established; it does not mean a vendor lacks the capability.
3. Test the uncomfortable case
Try a missing input, a rejected action and a disconnected account. Use two fictional clients to check separation. Compare the accepted output and support effort, then document the exit process and current plan costs.
Example provider workflow. Adapt it to the client’s agreed scope.
- 01
Step 1: Define the client question
- 02
Step 2: Collect dated evidence
- 03
Step 3: Test the uncomfortable case
Fit and limitations
- Good fit
- Providers applying this process to an agreed client service.
- Poor fit
- Treating this checklist as an automatic product feature or a substitute for a client agreement.
- Known limits
- These are operating recommendations. Test each supported product path in the target workspace and plan. Examples are not performance, pricing or security benchmarks.
Sources and evidence
Documentation establishes the scope of a claim. It does not replace an acceptance test in your client’s environment.
| Source | What it supports | Checked |
|---|---|---|
| Team workspace setupProduct documentation | Teams organize agents and connected tools by workspace. Verify membership and the active workspace before setup. | |
| Agent tools and review guidanceProduct documentation | Supported tool actions can require approval. Test the exact tool and runtime; coverage is not universal. | |
| Read an agent run recordProduct documentation | Inspect available tool calls and execution details within the relevant workspace. A completed run is not proof of an accepted result. |
Questions providers ask
Who is responsible for the result?
The provider names an operator; the client names the person who can accept the deliverable. The platform does not replace those responsibilities.
What evidence should we retain?
Keep the source date, workspace and agent, expected output, review decision and artifact reference. Exclude credentials and unnecessary personal data.
When should we stop and review?
Stop when the account, recipient, output or permissions differ from the agreed scope, then resolve the exception before continuing.
Set up one client service
Set up the client workspace, connect its tools and review the first deliverable. Use a tested delivery path, such as Telegram, so the client can receive work in chat. Track operating costs and review effort before pricing a recurring service.
Sign up now