Main site

Telecom AI agent · Number porting

Onboarding & Number-Porting AI Agent

Collect the standard fields for a port in or out, run the configured checks, and hold — a provisioning person decides anything that would delay the port, and the one-business-day clock keeps running.

Typical delivery
4–6 weeks
Deployment
Your stack
Desk release
Interval-bound
After launch
Agent Care

What this agent does

Does the order work, not the hold decision

In

  1. 01

    Ingesting the port request and the account record from supported ordering, CRM or LSR sources.

  2. 02

    Normalising the number, account number and zip code into the form the LSR requires, and stamping the interval.

Reason

  1. 03

    Assembling only the simple-port fields 47 CFR 52.36 permits, plus a passcode where the customer was assigned one.

  2. 04

    Applying the carrier's configured onboarding, market and due-date rules to the order.

  3. 05

    Binding each field to the record it was read from, and marking what the account leaves unresolved.

Decide

  1. 06

    Recognising a request that may be a line separation, and routing it to trained staff without scoring it.

  2. 07

    Routing anything that would delay or reject a port to the provisioning desk.

Out

  1. 08

    Retaining the request, the fields it carried, the timestamps and the release.

  2. 09

    Executing write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent prepares and tracks the order; a provisioning person decides any hold, and the carrier remains the party the interval binds.

Example workflow

One port, request to release

  1. 1Port request receivedOrder portal, retail or care system, or an inbound LSR from the gaining provider
  2. 2Fields assembledThe standard simple-port fields, an assigned passcode where there is one, and the received timestamp
  3. 3Order preparedValidated fields, due date and confidence
  4. 4Controls appliedField-set checks, interval timing, line-separation detection and confidence threshold

No human action required

Stages 1 to 4 run unaided and none of them pauses the interval — the agent is preparing the order, and the desk's lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the provisioning desk to release.

Low confidence

Adds a porting-desk check first.

Provisioning release

The order is held with its fields, its flags and the time left in the interval.

Release · Correct · Send to fraud review

Released — order sent

  1. 6Order systems updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedInterval performance, desk corrections, rejections and ports put right after release

Corrections

Every desk correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Holding a port, or delaying one past the interval.
    • Requiring any field outside the closed standard set.
    • Surfacing an account balance inside the port flow.
    • Actioning a line-separation request from a survivor.

  • Automation boundary

    Agent acts unaided

    • ✓Collect the standard simple-port fields the rule permits.
    • ✓Validate the fields for form, and carry each source forward for the named owner.
    • ✓Run the checks the carrier has configured for the market.
    • ✓Flag what a person must decide, stop there, and show the time left.

    Any write happens inside the boundaries agreed at implementation, never ahead of a release.

    • Standing in as the third-party verifier of a change.
    • Placing any offer on the authorisation screen.
    • Returning a rejection to the gaining provider.
  • Changes to field, interval or authorisation rules.

Example output

One port order, annotated

Everything the agent puts on the order is attached to the record it was read from.

Port-order output · single request

Illustrative example
Order
Simple port-out
Request
Number, account number and zip code taken from the account record
Due date
Next business day
Field set
Standard fields only
Confidence
94%
Authorisation
Separate LOA screen

As received

Taken from the account record and the inbound LSR — nothing on this side is supplied by the agent.

Fields used

  • Account record match
  • Assigned passcode
  • Received timestamp

Why these fields

The rule closes the list and a person still decides and it is logged..

What the score decides

Below the configured threshold the order picks up a desk check before anyone releases it.

Action

ReleaseCorrectSend to fraud review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every port request

From the order or the LSR

03Preparation

Build from the record

Use the account record, the closed standard field set and the carrier's configured market and interval rules.

01Approved path

Port on the clock, not on a hunch

Routine simple ports arrive validated and already inside the interval.

02Human review

Send the desk to what needs deciding

Flagged orders and low-confidence requests are marked, so the desk's time goes where a decision is actually owed.

04

Build an evidence trail

The request, the fields it carried and the person who released it stay on the order.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Porting and numbering

    • LSR gateway
    • NPAC feed
    • ATIS LSOG order formats

  • BSS / OSS

    • Amdocs
    • Netcracker
    • CSG
    • Optiva
    • in-house billing

  • CRM and care

    • Salesforce
    • Dynamics 365
    • Zendesk
    • ServiceNow

Agent

Onboarding & number porting

  • Reads the record
  • Builds the order
  • Stops for release

  • Identity and authorisation

    • LOA capture
    • e-signature
    • Independent TPV
    • IVR authorisation

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the port order

Controls stack inward. What the stack does not catch is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to preparing and reporting when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, field-rule and interval-configuration changes.Track
L4TraceabilityRecord the request, the fields, the timestamps, the flags and the release.Record
L3Provisioning releaseA person decides any hold; it governs who decides, not whether the hold was justified.Gate
L2Field-set guardrailsTest the order against the closed field set and the configured rules; a failure returns the order.Restrict
L1Confidence thresholdsRoute low-confidence orders to a desk check; confidence is not a reading of intent.Require review
Model coreOrder prepared — validated fields, due date, interval position and confidence
L1 – L2
Test whether an order may stand
L3
Puts the release in a person's hands
L4 – L5
Keep the request and the fields it carried
L6
Narrows to status reporting when signals degrade

How Nestack evaluates it

Evaluate the whole porting workflow — not only the completed port.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the order the customer sees

  1. E1Final-output evaluationDid the order carry only the fields the rule permits?
  2. E2Step-level evaluationDid the agent read the right account, market rules and interval configuration?
  3. E3Tool evaluationDid it read and write the correct order and the correct field?
  4. E4Confidence calibrationDo low-confidence orders actually attract more desk corrections?
  5. E5Slice evaluationHow does performance change across specific order types?
  6. E6Business outcomeHow many orders needed a desk correction, and how many were put right after release?

Floor — whether the number arrived on time

Failure modes

Where each failure originates in the agent

Seven failure modes, placed at the stage each one originates.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • VP-03

      Stale account record

      Passcode or account number read from a superseded record.

    Stage gathers

    Account record, assigned passcode

  2. 02 · Reasoning

    2 modes

    • VP-04

      Survivor read as attacker

      A line-separation request scores as a port-out fraud signal.

    • VP-06

      Interval consumed by review

      Verification work eats the business day the rule allows.

    Stage proposes

    The order, its fields and the confidence

  3. 03 · Tool / write

    2 modes

    • VP-02

      Balance surfaced in the flow

      An outstanding balance appears inside the port conversation.

    • VP-05

      Authorisation voided by offer

      An inducement lands on the authorisation screen.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • VP-01

      Unauthorised required field

      The order asks for something outside the closed standard set.

    Stage returns

    The order the desk releases and the gaining carrier sees

  5. 05 · Change / Version

    1 mode

    • VP-07

      Silent interval regression

      A model or rule change slows the path to release.

    Stage tracks

    Model, prompt, field rules and interval config

  • Sev-1 · a port is delayed
  • Sev-2 · an unpermitted field is required
  • Sev-3 · record degrades, order routes to the desk
See the complete Telecom failure-mode catalogue

Affected slices

Overall timing can hide one bad cohort

Survivors are the cohort no aggregate counts: a line-separation request is confidential by law, so it never appears in a fraud or retention report. Nestack reports the desk-correction rate by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Line-separation requests7.0%3.4×Review
Ports with a disputed balance4.5%2.2×Review
Non-simple and multi-line ports3.3%1.6×Watch
Standard simple ports1.2%0.6×Normal

Bar: desk-correction-rate lift vs. the all-orders baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

The cycle ends in a case, not a note

An apology does not close a cycle; a case the next release must pass does. That suite is what the next port through the desk is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Desk-correction rate rises in an order slice.

  2. 02

    Diagnose

    Within the same business day, the desk reads the orders behind the rise until the cause narrows to one.

  3. 03

    Improve

    The correction is versioned, with the orders that motivated it attached.

  4. 04

    Verify

    A failing case holds the release until it passes.

  5. 05

    Learn

    The case is added permanently, and the port rules move with it.

  6. Learn → Detect

    The return edge. The next cycle is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, order workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Porting workflow discovery and automation-boundary definition.Week 1
  2. 02Order and LSR source assessment.Week 1, Week 2
  3. 03Standard field-set and interval-rule mapping for each market.Week 1, Week 2
  4. 04Order ingestion and field normalisation.Week 2
  5. 05Validation logic and record binding.Week 2, Week 3
  6. 06Confidence scoring and desk routing.Week 3
  7. 07Provisioning release workflow.Week 3, Week 4
  8. 08Order-management and LSR integration.Week 5
  9. 09Port-interval and field cases.Week 4, Week 5
  10. 10Guardrails and authorisation controls.Week 4
  11. 11Order-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne market, one order pathProductionProduction order systemsAdvancedMultiple markets / brands
Introduced at Pilot
Order preparation on your rules✓✓✓
Provisioning release✓✓✓
Port-completion baseline✓✓✓
Introduced at Production
Reporting by order type—✓✓
Desk workflow in your systems—✓✓
Approved write-back—✓✓
Order-management integration—✓✓
Introduced at Advanced
Multi-market interval rules——✓
Multi-stage provisioning approvals——✓
High port volume——✓
Multi-market porting controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your order intake fields and account record structure

    Order ingestion and field mapping

    Week 1

  2. 02Representative completed port orders

    Validation baseline, field-set extraction and record binding

    Week 2

  3. 03Your market rules and assigned-passcode policy

    Field-set, interval and market-rule mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Order and LSR assessment, then integration setup

    Week 2

  5. 05Ports you would not want delayed

    Interval cases and the evaluation suite

    Week 4

  6. 06What must reach a person before a port is held

    Confidence scoring, desk routing, guardrails and release controls

    Week 3

  7. 07Named provisioning staff to release orders

    Provisioning release workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Each band covers the weeks the work really takes, so week 5 carries evaluation and launch together.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Porting workflow discovery, field mapping and the automation boundary

W2Order and LSR integration and the validation baseline

W3Order workflow, confidence logic and release controls

W4Evaluation suite, interval checks and failure-mode testing

W5Order-system integration, pilot ports and targeted corrections

W6One porting cycle run under the provisioning desk, then handover

Reading the band
Each band spans only the weeks its work is named in. The fifth week genuinely carries two kinds of work.
At the end of W6
Validation finishes on live orders and Agent Care assumes monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Telecom AI agent

Build a porting agent around the interval you are already bound by.

Show us your order path, your field set and who releases a port. Get it wrong and the delay is itself the violation — so we map the boundary and name what stays with a person.

Typical delivery
4–6 weeks
Deployment
Your order stack
Desk release
Interval-bound
After launch
Agent Care available

Nestack Agents · Onboarding & number porting

AGT-TL-04 · Agent Care available after launch

Build a porting agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your ports

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.