AstrosiaLabs Talk to the lab

AL-2026-03 · White paper

Numbers, KYC, and disclosure: operating voice agents in India

The operational sequence between deciding to deploy a voice agent and having one answer a call: what gets verified, in what order, and what has to be said on the line.

The engineering of a voice agent is largely independent of geography. Putting one on a live Indian phone number is not. This paper sets out the operational sequence we follow, so teams planning a deployment can schedule around it instead of discovering it.

Scope: this is an operational description of how we run deployments, written by engineers. It is not legal advice, and it does not substitute for your own counsel on obligations that apply to your business.

1. The number comes last, and it gates everything

The most common planning error we see is treating number provisioning as a final configuration step. It is not a configuration step, it is a verification process with a lead time, and nothing downstream can be tested on a real line until it completes.

An Indian virtual number is issued only after telecom KYC is filed in the company's name. In practice that means:

  • Certificate of Incorporation, or Udyam registration.
  • GST registration or PAN.
  • Documents in the name of the entity that will hold the number, not a director personally and not a parent company.

That last point causes more delay than the rest combined. A group that operates through several entities has to decide early which one holds the line, because a mismatch between the documents and the account is a restart rather than a correction.

2. A workable sequence

  1. Decide the holding entity. Before anything else, because it determines every document that follows.
  2. File KYC. Start this first; it runs in parallel with all engineering work.
  3. Build and test off-line. Agent behaviour, prompts, handoff rules, and CRM write-back can all be developed and tested without a provisioned number.
  4. Provision the number. Post-approval. ₹250 per month per number.
  5. Test on the real line. This is the first point at which carrier-leg behaviour is observable, and it will differ from your test environment.
  6. Go live on a narrow slice. One use case, one hour band, with a human path always available.

Steps 2 and 3 overlapping is the whole point of the sequence. Teams that serialise them add the KYC lead time to their project timeline for no reason.

3. Disclosure

Our operating position is that the agent identifies itself as automated, early and in plain language, in the language of the conversation. We do this because it is the right default, and because it materially improves calls: a caller who knows they are talking to a system adapts how they speak, and the conversation goes better.

Two practical points that are easy to get wrong:

  • Disclosure has to survive a transfer. When a call moves from an agent to a human, the caller should be told. The reverse case, human to agent, deserves the same treatment and is more often overlooked.
  • Disclosure must be in the right language. An English disclosure at the top of a conversation that then proceeds in Hindi has not disclosed anything to that caller.

4. Recording and the record

Recording policy and transcript policy are separate decisions, and conflating them is a common mistake. A deployment may need the transcript for CRM write-back while having a different, narrower policy for retaining audio.

The design consequence is that the pipeline should be able to produce a written outcome without retaining the recording it came from, which means transcription happens in the call path, not as a later batch job over stored audio. Teams that build the batch version first find that their retention policy and their product depend on each other, and cannot be changed independently.

5. What has to work before a real customer hears it

Our internal bar for putting an agent on a live line:

  1. A human path that always exists. The caller can reach a person, by asking in plain language, at any point. Not a menu option, but an intent the agent recognises.
  2. Graceful failure. If recognition, reasoning, or synthesis fails, the call transfers or takes a message. It does not sit in silence.
  3. The outcome is written back. A call that produces no record in the CRM is a call that did not happen, as far as the business is concerned.
  4. Tested on a bad line. Not the office wifi. See the turn budget note for why the network is where the failures come from.

6. Who does what

To be explicit about the division of responsibility, because it affects who you call when something breaks: voice is carried by licensed carrier partners. Voiceplix sells the agent, the number, and the minutes. Carrier-layer incidents are escalated through the carrier; agent behaviour and write-back are ours.

Keep reading

Working on something in this territory? The people who wrote this take the call.