Why source access matters when adding AI to messaging

Open source and source-available are different

The older RapidPro repository carries the GNU AGPL. The newer Temba upstream carries the Business Source License. Its additional use grant restricts commercial hosted messaging platforms; BSL explicitly states that it is not an open-source licence. Inspect the licence attached to the exact version you intend to deploy and establish any separate permission needed for your operating model.

Source availability lets you read implementation details. Permission to use, modify or provide a hosted service follows the applicable licence and agreement. Neither label tells you who has access to your running database, whether your backups restore, or how quickly an incident will be handled. For the broader deployment choice, start with what RapidPro does and when it fits.

Follow one delayed conversation

Imagine a participant asks a question. A flow calls an integration that requests an AI-generated answer, but the participant receives nothing. The following example is hypothetical; the components and evidence available will depend on your deployment.

RapidPro’s official hosting overview describes separate application, flow-processing, transport and data services. Use it as an architectural reference and check current requirements separately. Map the actual components and versions in your deployment before applying this investigation path.

1. Did the request enter the system?

Check the provider’s inbound event and the local receipt time. Use a message or correlation identifier to connect records without copying the participant’s full text into every log. If no event reached the local system, check provider delivery and the inbound endpoint before investigating flow execution.

2. Did the flow reach the integration?

Inspect the flow run and the work waiting to be processed. Compare queue age, worker errors and database behaviour around the same time. System access can help distinguish a flow branch that never made the call from a worker that could not progress. Source inspection can clarify an ambiguous error or retry path, but should follow the evidence rather than replace it.

3. What happened at the AI boundary?

Record whether the integration attempted a request, how long it waited, and which response or error it received. An operator can inspect the connector and its local network path. They cannot inspect the AI provider’s internal execution simply because RapidPro is self-hosted. Provider support, status information and contractual terms remain necessary.

4. Was a reply submitted and delivered?

A completed AI request is not proof of delivery. Check whether the result passed the integration’s validation, resumed the intended flow, and reached outbound transport. Then distinguish provider acceptance from any delivery receipt the channel supplies. Agree how to handle uncertain outcomes before retrying: repeating a send may produce duplicate participant messages.

Keep AI failures within a defined workflow

Design the conversation so an external call can fail without leaving someone stranded. Set a bounded wait, validate the returned data and provide a tested fallback route. That might be an approved response or an escalation to a staffed team; the programme owner must decide what is suitable and whether that team is available.

Keep record changes and outbound messages behind rules agreed by the programme team. Generated text should not authorise a new action on its own. Test empty replies, malformed output, slow responses and repeated requests alongside the successful case. These are design recommendations, not claims that every RapidPro release provides identical AI controls.

Inspect more without collecting everything

Useful diagnostics often need identifiers, timestamps, component versions, durations and error categories. They do not always need message bodies, prompts or personal details. Decide what may be logged, who can read it, how long it remains and how it is removed. Redact secrets and minimise participant data in support tickets.

Hosting location describes only part of the data path. Map what the integration sends to the AI provider, what that provider retains under your agreement, and which channel, backup and monitoring services receive data. Source access does not provide visibility into Meta, SMS carriers or an AI vendor’s internal systems, and it does not establish legal compliance.

Access creates work as well as options

A local patch may resolve a problem, but it also needs review, testing, deployment and a plan for future upstream changes. Direct database access needs controlled roles and an audit trail. Wider visibility is useful only when someone has the time and authority to act on it. A well-run hosted service can be the better choice when its evidence and support arrangements meet your needs.

• Before procurement: identify the exact release, licence, source-access rights and provider contracts.
• Before integration: define the data sent, timeout, fallback, logging and owner of each boundary.
• Before launch: rehearse a failed request and confirm the team can trace it without exposing unnecessary personal data.

Where BotFlow Host fits

BotFlow Host’s managed infrastructure service covers the dedicated platform’s operational lifecycle. Your team owns programme logic and content. Scope the responsibilities for any integration, its logs and its fallback before adding it; a third-party AI or channel provider still operates its own service. Bring a system diagram and one troublesome conversation path to a technical discussion so we can identify the control you actually need.