AI Newtika Scope your agent →

Telecom · Cloud + on-premise agent

Running a multi-location FTTH operation on agents, where nothing has an API

We run a BSNL FTTH operation across three locations. Every system that operation depends on — provisioning, the OLT management interfaces, the billing portal, the fault register — is web-only. None of them offers an API, and none of the vendors has a commercial reason to build one. So we built the agents instead, and we run our own business on them.

283production automation modules
26services running continuously
4 monthsin production, still shipping
0of these systems offer an API
Cloud nativeSince March 2026, ongoingCloud + on-premise agentPlaywrightBullMQ + RedisNode.jsAsteriskCircuit breakersLocal agent

01The situation

A fibre-to-the-home operation touches an unusual number of systems for its size. Orders arrive in one portal and are cleared in another. ONT provisioning happens through an OLT management interface designed to be operated by hand. Bills, payment history and unpaid-customer lists live in a billing system reachable only through a browser. Faults surface in a register that has to be polled. Voice services need password resets performed through yet another screen. Every one of those is a person, logging in, clicking through, copying a value into the next system.

02The constraint

There is no API anywhere in this stack, and no prospect of one. Beyond that, the systems actively resist automation: sessions expire mid-task, CSRF tokens rotate, some screens sit behind a national proxy that returns 502 under load, and the billing portal periodically interrupts login with a password-expiry interstitial that a naive script walks straight into. Any automation that assumes a stable, cooperative interface breaks within days — quietly, which is worse than loudly.

03What we built

A cloud orchestrator with a pooled browser layer driving each system through its own interface, work distributed over durable job queues, and a local agent that polls for work so tasks needing on-premise network access run inside the operation rather than from the cloud. Resilience is not an afterthought: circuit breakers appear in 26 modules, retry logic in 59, adaptive backoff in 11. When a system becomes unreachable the breaker opens and alerts rather than hammering it, and structural changes in a page raise a signal instead of producing quietly wrong data. A voice layer built on Asterisk handles calls with speech-to-text, TTS and an LLM in the loop.

04The outcome

The operation runs on this. Provisioning, order clearance, bill and payment retrieval, MAC and VLAN changes, voice password resets and fault monitoring are performed by agents against the same interfaces a person would use, with the work queued, retried and audited. The failures that do occur are visible: an unreachable OLT opens a circuit breaker and logs it; a changed login flow raises an alert. That visibility is the point — the alternative is a dashboard that stays green while the data goes stale.

05What we are not claiming

Two things we are not claiming. First, this is our own operation rather than a client engagement — useful evidence that we run our own business on this approach, but it is not a third-party reference. Second, we did not instrument the manual baseline before building, so we are not going to quote hours saved or a failure-rate improvement. We would measure that properly at the start of a client engagement; we did not do it for ourselves, and we are not going to reverse-engineer a number to fill the gap.

Have the same problem in a different system?

Tell us the workflow being done by hand today and the system that blocks it. We reply within one working day with an initial read on feasibility — including when the honest answer is that you do not need an agent.

Start with a fixed-price discovery