Question: GCC/non-US numbers and consent-safe outbound flows

[alkhunizan]

Hi Sam / AgentLine team — I found the repo from your recent launch post. The "agent gets a real phone number" direction is very useful for agent workflows that need to leave the browser and talk to normal users.

One question from a non-US / compliance-heavy use case: are GCC/non-US numbers and explicit SMS/voice consent flows on the roadmap?

Concrete scenario:

• an agent needs to call or SMS a consenting user in Saudi/GCC
• the app wants to store an auditable opt-in record before the first outbound message/call
• transcripts should be clearly marked as agent-generated and easy to export/delete

If this is aligned with the roadmap, I think a small docs/compliance-and-regions.md page with supported regions, provider assumptions, and a minimal opt-in webhook/API example would make the project easier to adopt outside the US.

Happy to test a GCC-ish flow or review the doc if you add a rough version.

[Sameersribot]

Hey there! Thanks for pointing it out. As far as compliance outside of the US is concerned, for now we only have US and Canada phone numbers. We don't have phone numbers from Saudi or GCC countries, but we are taking into account what compliance in different countries is. We are looking into how we can probably increase our foothold in different countries, slowly, slowly complying with all the regulations.

As far as the talks of compliance and reasons are concerned, we will definitely add it when it's a great idea. The webbook example will also be added. Many examples are there in the docs, but not in these open-source docs. We will definitely add it here as well, so thank you.

[alkhunizan]

Thanks Sameer — that makes sense, especially starting with US/Canada numbers and expanding carefully.

One small follow-up from a GCC adoption angle: even before local numbers are supported, it may help to expose consent/compliance metadata in the examples (region, opt-in source, opt-out path, recording/transcription flag, retention window). Then builders can design the flow correctly before they ever touch Saudi/GCC traffic.

No need for legal advice in the docs, just a clear API/example shape would be useful. Happy to sanity-check the example once you add it.

[alkhunizan]

Quick follow-up after the August auth/billing updates.

Since non-US numbers are still a later expansion, one small thing that would help GCC adoption before local numbers exist: a provider-agnostic consent_profile in the examples / event payloads.

Something boring like:

{
  "region": "SA",
  "channel": "voice|sms",
  "optInSource": "web_form|inbound_call|manual_import",
  "optOutText": "...",
  "recordingDisclosure": "played|not_applicable",
  "retentionDays": 30,
  "providerCapabilities": ["inbound_voice", "outbound_voice"]
}

Even if SA/GCC is unsupported today, the API could reject outbound SMS/calls with a structured error that includes the missing consent/capability field. That lets agent builders test the safe path before they ever touch a live local number.

Not urgent — just the one metadata shape I would look for before piloting AgentLine outside US/Canada.