01 / Evaluation
Begin with one business action
An integration should serve a defined job, such as reading approved service information, preparing an enquiry or submitting a confirmed request. Listing a provider name does not establish that every action in that provider is available. Specify what the agent may read, what it may change and when a person must approve the next step.
Voxae connects approved knowledge and tools within configured conversational workflows. Ash Systems also scopes business-system integrations and structured data exchange as custom engineering. Evaluation confirms the connected systems, permissions and supported actions; no blanket integration availability is assumed.
Review checklist
- Name the action and the business reason for it.
- List the minimum information and permissions needed.
- Identify who authorises access and maintains the connection.
02 / Evaluation
Identify the authoritative source of truth
A scheduling system confirms an appointment. A stock system confirms availability. A payment provider confirms a transaction. The conversational layer should represent the outcome accepted by that system, not convert a proposed action into a claim of completion.
The same distinction matters across the portfolio. Nexo payment records are a ledger rather than payment processing. Restaurant AI's illustrative order summary is not a submitted kitchen order. Health Agent's structured intake is not a confirmed insurance eligibility decision. Specify the authoritative confirmation for each workflow.
03 / Evaluation
Review confirmation and consequential changes
Agree which actions need customer confirmation, which require a team member and which the agent must refuse. Review changed details before submission so a correction is carried into the proposed action. Keep the scope understandable to the people who will operate it.
Connected records can contain sensitive or commercially important information. Define the relevant access boundaries and the data needed for the specific task. A public website assistant should not inherit private company records or administrative tools simply because it uses the same model provider.
Review checklist
- Read-only access versus permission to change records.
- Customer confirmation and authorised human approval.
- Sensitive fields and minimum required context.
- Prohibited actions and unsupported requests.
04 / Evaluation
Test failure messages before success messages
Evaluate denied permissions, expired credentials, unavailable services and a rejected business action. Check the system's actual response and the message the customer receives. An agent should not announce a completed booking or transaction when the connection failed.
Where an outcome is uncertain, define a review path rather than retrying consequential work without knowing what the authoritative system accepted. Agree what the team can inspect and how unresolved requests become visible. The acceptance evidence should cover the actual configured connection.
Review checklist
- A successful authorised action with an accepted result.
- A denied action with a clear customer next step.
- An unavailable service or uncertain result routed for review.
- A customer correction carried into the final confirmed request.
05 / Evaluation
Keep demonstrations separate from private systems
A public demonstration needs its own approved information and limited capabilities. It should explain the operating model without exposing private records, credentials or unrestricted tools. Recorded product screens and illustrative workflows should remain labelled as such.
Share the systems involved, the proposed actions and a representative example through the Ash Systems contact form without sending passwords or confidential records. The evaluation can then define access, acceptance checks and release responsibilities for the engagement.