Telecommunications networks do much more than move data. They know whether a device is reachable, can help verify a phone number, and may be able to provide location or connectivity signals—with the right permissions and controls.
Historically, many of those capabilities have been difficult for ordinary business software to use. That is beginning to change through network application programming interfaces, or network APIs.
The CAMARA project is developing common APIs that expose selected network capabilities in a consistent way. Its published catalogue spans areas including authentication and fraud prevention, location services, device information, communication quality and network insights.1 Aduna, meanwhile, describes a model in which developers can access capabilities across multiple mobile carriers through one platform rather than integrating separately with each operator.2
There is also a newer ingredient: agentic AI—software that can plan and carry out multi-step tasks within defined limits. Put the two together and business applications could potentially respond to network conditions or identity signals without waiting for a person to interpret every event.
That is the opportunity. It is not, however, a licence to automate everything.
First, what is a network API?
An API is a controlled doorway between systems. A weather app uses an API to request a forecast; accounting software may use one to retrieve a bank transaction. A network API applies the same idea to an approved telecommunications capability.
Examples in CAMARA’s current catalogue include number verification, SIM-swap information, device reachability, location verification and quality on demand.1 Availability varies by carrier, market, access method and commercial arrangement. A standard API definition does not mean every function is live everywhere.
That distinction matters. CAMARA is helping create a common technical language. Aggregation platforms such as Aduna aim to simplify access across operators.2 Individual operators still decide what they expose, where, to whom and under what controls.
Telstra’s published network milestones record the launch of Number Verification and SIM Swap APIs on Aduna in November 2025.3 That is a concrete Australian example. The agentic applications discussed below are potential designs, and this article does not imply that Capti supplies mobile-network APIs.
What does “agentic” add?
A conventional automation follows a fixed instruction: if this happens, do that. An agentic system can be given a goal, select from approved tools, check results and decide its next permitted step.
Imagine a field-service platform trying to keep a technician connected. A traditional workflow might show an error and stop. A carefully designed agent could potentially:
- detect that the application is struggling;
- request an approved network or device signal;
- distinguish a device problem from a wider connectivity problem;
- change the job workflow, notify support or recommend a backup path; and
- record why it acted.
The word approved is doing a lot of work there. The agent should not receive unrestricted access to network data, customer records or purchasing authority. Useful automation needs boundaries.
Four practical possibilities for businesses
1. Stronger, smoother fraud checks
A bank, marketplace or account-recovery service might combine its usual security controls with network-derived signals. Number verification could reduce reliance on a user manually entering a one-time code in some workflows. A recent SIM-swap signal might prompt an additional check before a high-risk account change.
An agent could assess several permitted signals and route only unusual cases to a human. The benefit would not be “AI decides who is fraudulent”. It would be faster triage with an auditable escalation path.
2. Better support diagnosis
A support team often has to ask: is the application down, is the local connection congested, or is one device unreachable? Network APIs could supply selected diagnostic clues. An AI support agent could assemble those clues, compare them with service telemetry and give the human operator a more useful starting point.
This could shorten repetitive troubleshooting. It would not remove the need for sound monitoring, good network design or skilled technical support.
3. More responsive digital experiences
Applications used for video, remote assistance or time-sensitive transactions may eventually be able to request information about available connectivity—or, where offered and authorised, a specific quality treatment. CAMARA lists APIs covering connectivity insights and quality on demand.1
A business application might then adapt video resolution, defer a large upload or warn the user before a critical session deteriorates. Any quality feature would remain subject to operator availability, device support and commercial terms.
4. Smarter field and logistics workflows
With explicit consent and a legitimate purpose, location verification or device-reachability signals could help confirm that equipment is in the expected region, identify a disconnected unit or sequence a service visit. An agent could use those signals to update a workflow, but should not turn a narrow operational check into broad employee or customer surveillance.
The hard questions matter more than the demo
A compelling demonstration may take minutes. Responsible production use takes policy, engineering and operational discipline.
Before connecting an AI agent to a network API, ask:
- What exact business problem are we solving? “Use AI” is not a measurable objective.
- What is the minimum data required? Prefer a yes/no verification result over precise raw data when that is enough.
- Who has consented, and for what purpose? Location, identity and device signals can be sensitive.
- What actions can the agent take? Separate read-only checks from changes, notifications and spending.
- Where is human approval mandatory? Account lockouts, adverse customer decisions and safety-critical actions deserve extra care.
- Can every request and action be audited? Logs should show the signal requested, decision made and authority used.
- What happens when the API is unavailable or ambiguous? A safe fallback is part of the design.
- How do we prevent prompt injection and tool misuse? Treat external content as untrusted and tightly scope credentials.
- How long is data retained? “We might need it later” is not a retention policy.
A sensible way to prepare now
Most Australian businesses do not need to buy a network-API platform tomorrow. They can still become ready.
Start by mapping one costly or frustrating workflow—fraud review, connectivity support or field operations. Document the decision points and identify which evidence is actually missing. Then ask whether a network signal would materially improve the decision.
Run any trial in a sandbox with synthetic or low-risk data. Keep the agent read-only first. Set success measures such as fewer false escalations, reduced handling time or better first-contact resolution. Add production permissions only after security, privacy, legal and operational owners agree on controls.
Finally, look beneath the application. Agentic workflows still depend on reliable connectivity between users, sites, clouds and service platforms. Capti offers business fibre, Reach Fibre through third-party carriers, fixed wireless, cloud connectivity and private networks, subject to availability and solution design.4
Network APIs may make telecommunications capabilities easier for software to use; agentic AI may make that software more adaptive. The businesses that benefit will probably be the ones that combine experimentation with clear limits—not those that hand an agent the keys and hope for the best.
Planning a connectivity foundation for more automated operations? Talk with Capti about your sites, cloud paths, resilience needs and addressing requirements. We can help you frame the connectivity questions before you commit to an architecture.
For more detail, read about assessing business network requirements for AI. Explore business fibre options for your location.
