1. Start with an observable process
Name the trigger, the people involved, the current output and the point at which the work is complete. A goal such as “use AI in operations” is too broad to evaluate. “Prepare an enquiry for review and update the CRM after approval” gives the team something specific to inspect.
Collect representative examples, including exceptions. Ask the current process owner where information is copied, where work waits and which mistakes create rework. Do not send confidential examples through a public form.
2. Choose the least complex useful approach
An existing software feature, a better form or clearer rules may solve the problem. Use a workflow when its control flow can be specified. Consider a bounded agent when interpretation or planning is needed within explicit permissions.
Orchestration becomes useful when several components must share state, approvals and recovery. These categories can coexist. A workflow can call tools and include AI; tool use alone does not make a system agentic.
3. Check integration readiness
List the systems, available APIs, data formats, permission owners and vendor limits. Confirm that the business can lawfully grant access. An inaccessible application or unreliable source data can be a larger constraint than the model.
Record authentication, rate limits, duplicate handling and the route for a failed update. A proposal should distinguish confirmed connections from dependencies that still need investigation.
4. Write the acceptance checks first
Define what a useful output looks like, which sources must support it and what must happen when information is incomplete. Include edge cases and an acceptable handoff rather than measuring only easy successes.
For an agent, evaluate allowed actions, source use and refusal or escalation. For a workflow, evaluate completion, exceptions and recovery. For orchestration, evaluate the whole process, not just the individual components.
5. Separate stages and cost categories
An assessment determines feasibility and scope. A pilot produces evidence for a bounded use case. Production implementation adds operational controls, rollout and handover. Support maintains the agreed environment and changes.
Ask which fees cover design and build, which recur, and which are paid to software or model providers. Hosting, licences, API usage, monitoring, editorial review and change requests can affect the total operating cost.
6. Set ownership and human authority
Identify the person who can approve actions, accept delivery and operate the result. Specify code, prompts, workflows, integration configuration, account access, client data and third-party connector licences separately. Check connector export limits and transfer rights. Include documentation, export options and access revocation.
Customer-facing communications, spending and material record changes need an agreed action policy. A promise of autonomy does not establish who is accountable when something goes wrong.
7. Plan for change and failure
Source documents change, vendors update APIs and models can behave differently after a release. Ask for a versioned configuration, representative regression cases, useful monitoring and a clear incident owner.
Agree rollback or a manual fallback where the platform permits it. Support coverage, response expectations and new development should be distinguished. A public contact form is not an emergency support system.
8. Decide whether the evidence justifies the next step
Use actual task volume, handling time, review effort and exceptions to compare the pilot with the current process. Do not translate time released directly into cash savings without a realistic explanation.
Proceed when the evidence is useful, the remaining risks are understood and the business can operate the result. Re-scope when a smaller solution is enough. Stop when the prerequisites or commercial case are not there.