Today we are shipping the TP-Link integration for Sia. SIA, Scogo's IT-operations agent, now brings up and verifies TP-Link enterprise gear from a single instruction, across three surfaces: browser automation, CLI, and API via MCP. We proved it on roughly a thousand branch routers, configured site to site on real ER605 hardware, with no engineer driving the web UI. One instruction in. A configured, verified router out.

The news is bigger than one vendor.

We are building toward one agent that configures, verifies, and governs every device in your estate. Any OEM, any product, the whole estate, on the record. TP-Link is the first vendor we are putting our name behind. It will not be the last, and we are shipping each one the same way: proven at fleet scale before we announce it.

So read this as more than a feature. We are not adding another console to your stack. We are taking them away. Every integration we ship is one more class of gear your team stops clicking through by hand, and one more reason the work moves to Sia and stays there.

This post is for the people who run these networks: the L1 techs onboarding hardware, the L2 engineers chasing tunnels that won't come up, the L3 architects who own the fleet. Here is what just changed for you.

Why branch networks resisted automation this long

Branch network gear is repetitive to configure and unforgiving to get wrong.

A regional retailer, a bank, a logistics chain: they all have the same shape. Hundreds or thousands of near-identical sites, each needing the same router brought up the same way. Login, WAN, internet check, site-to-site IPSec VPN, LAN, DHCP. Miss one value and a branch goes dark.

The web UIs make it worse, not better. TP-Link's standalone firmware (the ER605 LuCI interface, for example) is a dense jQuery app. Element IDs renumber between page loads. Key settings hide behind an "Advanced" toggle. The session token never sits in the URL.

We tried the obvious shortcut first. Point a general-purpose LLM at the live UI and let it click. One run burned through millions of tokens and still didn't finish cleanly. Clicking a hostile UI by hand does not scale to a fleet, whether the hand is human or model.

So we stopped clicking. Then we built the thing that does scale, and we ran it across a thousand routers to be sure.

How Sia drives TP-Link

Three ways in, one engine behind them.

• Browser automation. Sia opens a real Chrome, logs in, and drives the device's own web UI, including the parts no public API exposes.

• CLI. sia browser, sia run, recipes, and secret brokering, scriptable into the tooling you already run.

• API via MCP. The same capabilities exposed as tools to any MCP-compatible agent or orchestrator, so Sia plugs into the automation you already have.

The piece that makes a fleet practical is record once, replay everywhere.

You configure one golden unit by hand. Sia captures the device's own authenticated configuration calls and turns them into a parameterized recipe. Per-site values become variables. Credentials become secret placeholders that never touch a log.

Then you replay that recipe across every other site from a one-row-per-site CSV. No per-device clicking. No per-device LLM cost. The same config, applied identically, every time.

Built for people who have been burned by automation

Every rollout runs through verification gates with explicit stop codes: WAN_NO_IP, VPN_DOWN, LAN_RECONNECT_FAILED. If a gate fails, Sia stops, reports exactly what it saw, and changes nothing further.

It never factory-resets. It never reuses another site's values. It never prints a PSK or an admin password.

This is automation with a seatbelt, not click-and-pray. It is the difference between a demo and something you let near a thousand production sites.

What you can automate, by tier

The integration targets TP-Link's enterprise lines: the ER-series gateways , JetStream switches, and EAP/Omada access points. Here it is mapped to how NetOps actually divides the work. BTW, SIA is intelligent and is not hardwired with any model type, you just throw any TP-Link device at it , which has a web / CLI / API surface, SIA has got you covered.

L1: routine, high-volume onboarding

L2: configuration and troubleshooting

L3: design, scale, and governance

Site-to-site IPSec VPN is generally available today, proven on real ER605 hardware at fleet scale. The rest of the matrix is what the same three surfaces, browser, CLI, and MCP, are built to drive, and what we are rolling out next.

The flagship: a verified VPN site, end to end

Here is the deployment that shipped, exactly as it runs. Watch a full site come up on real ER605 hardware, from a factory-fresh router to a verified tunnel, with no engineer touching the web UI. The step-by-step below annotates what you are seeing.

No cuts, no speed-up on the parts that matter. One instruction in, a configured and verified router out.

Now the same deployment, step by step.

1. Log in. Sia opens the router, creates the admin account on a factory-fresh unit or logs in, and lands on the dashboard.

2. WAN. Sets Dynamic IP, waits for a WAN address, retries if needed.

3. Verify internet. Pings 8.8.8.8 and a hostname, which proves DNS too.

4. Replay the config. Re-issues the recorded IPSec, LAN, and DHCP calls for this site's variables, deterministically, in seconds.

5. Reconnect. The LAN-IP change drops the laptop's link. Sia renews the lease, moves into the new subnet, and re-points to the router's new address. This is the detail most demos quietly skip.

6. Verify the tunnel. Confirms Phase 1 and Phase 2 are Connected and that traffic crosses the tunnel.

7. Report. Prints a deployment checklist: WAN, internet, LAN, VPN policy, both phases up.

The operator's entire job is to hand Sia the site details. The PSK and admin password live in the OS keychain and are referenced by name. They never appear in the prompt, the transcript, or the logs.

What this does to the work

The work does not disappear. It moves up a level.

Instead of an L1 tech walking a checklist per site, an agent executes the checklist and an engineer reviews exceptions.

Instead of an L2 engineer reverse-engineering why a tunnel won't form, the agent reports the exact failing gate.

Instead of an L3 architect hoping every site matches the standard, the standard is the recipe, applied identically and verified.

Rollouts get faster and config drift gets rarer, because the same recipe enforces the same standard at every site. Engineers spend their time on the hard cases instead of the repetitive ones.

Why we are naming OEMs one at a time

TP-Link is one box. The estate is everything else: the firewalls, the switches, the access points, the servers, the cloud accounts, the storage, the service desk. Scogo already reaches across that estate through Agent Fabric. What we are doing now is going vendor by vendor and proving Sia can drive each one to fleet scale, then putting our name on it.

That is the whole strategy, stated plainly. Every named integration takes a class of gear off your team's hands and makes Sia the place that work runs. We would rather earn that one proven OEM at a time than claim a logo wall we cannot stand behind.

TP-Link is first. We are already working the next ones, and we will announce them the same way: at fleet scale, on real hardware, or not at all.

Availability

The TP-Link integration is in Sia now, with site-to-site IPSec VPN generally available and the broader task matrix rolling out. We deliver Sia as part of the Scogo platform to enterprise customers, so there is no public download.

If you run TP-Link enterprise gear at scale, branch routers, switches, or access points, we want to put it in front of your fleet. If you run a different vendor and want to be early on the next integration, tell us which one.

Autonomous where it is safe, governed where it matters, on the record everywhere.