01

Knowledge needs approval before it reaches the agent.

Manual and imported sources are reviewed before use. GitHub updates require fresh approval. Private repository access is restricted by a server-owned workspace allowlist, and sales knowledge is separated from support knowledge.

Knowledge is treated as source material rather than agent instructions. Approval controls the material available to the agent; it does not guarantee every generated answer is correct.

02

Credentials and call destinations stay on the server.

Provider secrets are kept server-side. Production founder access uses signed, expiring cookies. Management tokens are workspace-scoped, stored as hashes and revocable. Allowed website origins and one-use call tickets limit where conversations can start.

Phone destinations are selected from the configured workspace. Signed provider callbacks and call binding protect the handoff flow against arbitrary dialling.

03

Review how the pilot handles conversation data.

The voice product runs as one Node service on Railway with a persistent SQLite volume. It saves conversation transcripts, feedback, knowledge and usage records. The application does not store call audio recordings.

OpenAI processes voice conversations. Twilio is involved when phone testing or human handoff is configured. A generated handoff briefing uses an expiring private link. Product data processing, retention and deletion arrangements need to be agreed for each pilot before customer data is introduced.

04

Keep the evaluation within the current product scope.

Public customer account onboarding, account-specific identity checks, team permissions and configurable retention remain launch work. Start with general product guidance and a controlled set of callers. The human handoff page records which live conversation paths still need verification.

For a security question or to discuss your pilot’s data requirements, contact hello@tenhaw.com. Website enquiry handling is described separately in the privacy notice.