# Planning an AI Agent Experiment for Running an ISP Company
/* */
I want to experiment with AI agents in a setting that is operationally real: running an internet service provider. Not as a vague automation demo, and not as a promise that agents can replace people. The useful question is narrower: where can agents reduce repetitive work, improve response time, and surface better decisions while still keeping humans in control of anything risky?
An ISP is a good test bed because the work is messy. There are customer requests, billing questions, outage reports, network alarms, field technician schedules, inventory constraints, router configurations, and compliance concerns. Most of the work is not one big intelligence problem. It is a stream of small tasks where context, timing, and safe escalation matter.
The Experiment
The first version should be a controlled internal system, not an autonomous operator. I would start with agents that can read from support tickets, network monitoring, customer records, and standard operating procedures. They can summarize, classify, recommend, draft, and prepare actions. They should not make irreversible changes without approval.
The goal is to measure whether agents can help with three things:
- shorten the time from issue report to first useful diagnosis
- reduce repeated manual lookups across dashboards and spreadsheets
- improve the quality of handoffs between support, network operations, billing, and field teams
If the agents only create another inbox to manage, the experiment fails.
Candidate Agents
The support triage agent would read incoming tickets and group them by likely cause: billing, account access, slow connection, modem issue, area outage, or installation follow-up. It could draft a first response and attach the facts it used, such as plan type, recent outages, payment status, and modem status.
The network operations agent would watch alerts and correlate them with customer reports. If several customers in the same area report issues while a backhaul link is unstable, it should produce a concise incident note instead of forcing someone to connect those dots manually.
The billing assistant would help explain balances, invoices, reconnect fees, and payment status. This one needs strict boundaries because billing mistakes damage trust quickly. The agent can draft explanations and flag mismatches, but refunds, disconnections, and account adjustments should require human approval.
The field dispatch agent would prepare technician context: customer history, location, plan, equipment model, photos or notes from previous visits, and the likely parts needed. That saves time before a site visit and makes handoffs less dependent on tribal knowledge.
Guardrails
The most important design choice is permission. Agents should begin as read-only assistants with explicit approval steps. Any action that affects a customer, the network, money, or legal records needs an audit trail and a human confirming it.
I would also require every recommendation to include evidence. If an agent says "possible area outage," it should point to the tickets, alerts, devices, or metrics behind that claim. A confident answer with no source is not useful in operations.
The system also needs fallback behavior. If the agent is unsure, missing data, or seeing conflicting signals, it should say that clearly and escalate. The wrong kind of automation hides uncertainty. The useful kind exposes it early.
How I Would Measure It
I would not measure this by how impressive the demos look. I would measure:
- first response time
- mean time to acknowledge an outage
- number of manual lookups per ticket
- percentage of agent drafts accepted or edited
- number of incorrect classifications
- number of escalations caused by missing or conflicting data
- technician prep time before dispatch
The baseline matters. Before agents touch the workflow, I would capture a week or two of current support and operations metrics. Otherwise it is too easy to mistake novelty for improvement.
The First Milestone
The first milestone is simple: build an internal dashboard where agents can summarize tickets, group related incidents, and draft next steps. No automatic customer messages. No network changes. No billing changes.
If that proves useful, the next milestone is approval-based actions: send a prepared customer reply, create an incident note, assign a ticket, or prepare a field visit checklist. Each action should show the exact data used and require a person to confirm it.
That is the shape of the experiment I want to run: practical, measured, and careful about control. The interesting part is not whether AI agents can sound like operators. It is whether they can make real operators faster, better informed, and less buried in repetitive coordination work.