Example: a request to change onboarding
A customer asks to move an onboarding session. A proposed agent workflow could read the request, match the customer record, check permitted calendar information, and prepare the change for review.
The reviewer sees the proposed time and customer message before either is committed. An ambiguous customer match or conflicting date goes back for clarification. If a calendar update succeeds but the message fails, the workflow should show that partial result rather than silently start over.
This is an illustrative design pattern. It is not a claim of a deployed customer system, and the required connections must be checked for your tools.
What should be in the scope
See the delivery process and handoff inventory.
- The workflow owner, trigger, expected volume, and definition of completion.
- The sources the agent can read and the specific actions it can request or perform.
- Human approval points, prohibited actions, and exception handling.
- Integrations, account prerequisites, test environments, and vendor limitations.
- Acceptance cases, release responsibilities, and a way to pause the workflow.
- Documentation, access handoff, ownership terms, and support exclusions.
Test the actions that should not happen
A successful demonstration is only one test. The evaluation should also include a duplicated request, missing information, unavailable tools, conflicting source records, and a request outside the agent's authority.
Confirm that approval happens before the protected action, not after it. Check the actual tool result before marking work complete. Begin with an isolated, read-only, or reviewed workflow as appropriate; broader permissions require a separate decision.
Separate the build from its running costs
Implementation fees cover the agreed delivery work. Model usage, hosting, third-party licenses, ongoing support, and new feature work should be identified separately. Expected volume, source quality, integration access, and review requirements affect the scope.
Timing also depends on access, requirements, and acceptance testing. We do not promise a standard launch date before reviewing those dependencies.
Common questions
Which model should our agent use?+
Model choice follows the task, data restrictions, required tools, cost, and evaluation results. Writing a useful draft, extracting a field, and selecting a tool action can have different requirements. A model name alone does not establish that the complete workflow is reliable.
Can an agent connect to any business application?+
No blanket compatibility is promised. We check available connections, licensing, permissions, and the actions your account supports. If access is unavailable or too risky, the scope may need a manual handoff, another integration approach, or no build.
Who owns the code and accounts?+
Ownership is defined in the agreement. Customer-controlled accounts and infrastructure are preferred where feasible. Rights to custom deliverables, reusable components, and third-party software are different; underlying models and platforms remain licensed.
Can you take over an existing prototype?+
An existing agent or prototype can be reviewed for fit. Share a description of its workflow, architecture, current limitations, and the access you can authorize. Do not send credentials through the inquiry form.
Does implementation include ongoing support?+
Only the support explicitly included in the agreement. Monitoring, response targets, maintenance, and additional features need named owners and a defined scope.