QuickSDWAN: AI as the control plane, not the chatbot.

#The setup: SD-WAN consoles are where good operators go to feel slow

There is a recurring frustration among network operators that almost every SD-WAN customer has experienced and that the established SD-WAN vendors have not fundamentally addressed in the past decade. The frustration is that the SD-WAN console — the dashboard where the operator authors firewall rules, configures DNS filters, monitors traffic patterns, investigates anomalies, and orchestrates incident response — is structurally slow. Not slow in the latency sense; slow in the operator-throughput sense. The operator who needs to ship a policy change spends thirty minutes in the console where they should have spent thirty seconds.

The structural reasons are not hard to articulate. The SD-WAN console is a configuration surface designed in the era when networking changes were rare, deliberate, and authored by specialists with the time to navigate twelve nested screens. The modern operational reality — where the security and networking teams ship policy changes daily, sometimes hourly, in response to threats, business needs, and the constant churn of distributed-workforce traffic patterns — has outgrown the era the consoles were designed for. The operator is fighting the surface area instead of using it.

The first wave of response from the established vendors was to ship "natural-language" search bars and "AI assistants" bolted onto the existing consoles. The assistant could answer questions about the configuration ("which devices are in the prod-network ACL"), but could not actually change anything. The change surface remained the same twelve-screen navigation it had always been. The assistant was a chatbot, not a control plane.

The second wave is the AI-Operator architecture that QuickSDWAN ships. The AI is not a chatbot answering questions about the configuration; the AI is the control plane authoring the configuration. The operator describes the change in natural language; the AI generates the structured rule, previews the impact, and applies on confirmation. Every step is audit-logged and reversible within a five-minute window. The console exists for the cases where the operator wants to verify the AI's work, not as the primary authoring surface.

The platform exists because the founders watched their own network and security teams, and a growing crowd of mid-market network operators, run into the same console-fights-back wall and conclude that the right move was to ship the SD-WAN platform where the AI was the primary authoring surface from day one. The bet was simple: AI as the control plane, every standard SASE capability included, three minutes from one Docker command to a fully-operational site.

#What QuickSDWAN actually is, in one paragraph and then in detail

QuickSDWAN is a cloud-operated SD-WAN platform that runs as a managed SaaS by Ollasoftware. The mental model is a unified SASE stack — WireGuard SD-WAN, firewall as a service, DLP, CASB, anomaly detection, auto-remediation — with the AI Network Agent as the primary authoring and operational surface across all of it. The customer signs up at the dashboard, runs one Docker command on each site, and the agent registers with the controller, auto-connects to the mesh, syncs the firewall policies, and brings every layer of the stack online. The whole site-onboarding completes in roughly three minutes.

Inside the platform there are five composable surfaces. The mesh-networking surface is the foundation — WireGuard SD-WAN with full-mesh encryption, split tunneling, NAT traversal, and managed routes. The fastest VPN protocol in production. The firewall surface ships three-layer protection: DNS filtering, SNI inspection, and protocol blocking — the AI creates and manages the policies through the natural-language authoring surface.

The AI Network Agent surface is the distinguishing layer. The agent is powered by a deliberate dual-model architecture: Claude (Anthropic) handles the high-reasoning tasks (policy authoring, impact analysis, multi-step diagnostics, conversational explanation of complex network state), while Groq LLaMA 70B handles the high-throughput tasks (anomaly classification at scale, remediation routing, real-time event triage). The two models are coordinated through forty-plus structured tools that map to the platform's typed configuration primitives — the AI generates structured operations, not free-form configuration that the platform tries to parse.

The predictive-anomaly-detection surface runs continuously across every node. Every sixty seconds the platform computes z-scores against rolling baselines for the four canonical anomaly types (traffic spike, latency anomaly, packet loss, node flapping), assigns severity (low / medium / high / critical), and surfaces detections through the dashboard plus the AI chat surface. The 10-minute cooldown per node prevents alert fatigue. The detection coverage extends across the entire mesh by default — no per-node configuration required.

The auto-remediation surface is the "if-then" automation layer. The customer authors policies in natural language ("If traffic_spike on any node, severity high or above, auto-reroute to backup path"), the platform translates the policy to the structured remediation primitives, and when the anomaly matches the policy the platform applies the remediation without human intervention. Every action is audit-logged, every action is reversible within five minutes, and every action triggers the appropriate admin notification for visibility.

#The AI Network Agent: 40+ tools, dual-model architecture

The AI Network Agent is the surface the customer interacts with most directly, and the architectural decisions behind it are worth being explicit about because they are what distinguish a usable AI control plane from an unreliable demo.

The first decision is the dual-model architecture. Claude handles the operations where reasoning quality matters more than throughput: policy authoring (translate the operator's intent into a structured firewall or ACL change), impact analysis (which nodes and users will this change affect, what is the blast radius, what is the rollback path), multi-step diagnostics ("the Mumbai office is reporting slow Salesforce performance, walk through the diagnostic"), and conversational explanation (why did the platform make the recommendation it just made). Claude's structured-output discipline and its conservative posture on destructive actions are the operational properties that make it the right choice for these tasks.

Groq LLaMA 70B handles the operations where throughput matters more than reasoning depth: anomaly classification at scale (every node, every minute, four anomaly types, structured severity output), remediation routing (when an anomaly fires, which auto-remediation policy applies, which structured action to take), and real-time event triage (the inbound webhook from a SaaS application or a security feed, classify the urgency, route to the right surface). Groq's inference throughput at the LLaMA 70B tier is the operational property that makes it the right choice for these tasks; the architectural decision is that the platform uses Groq specifically because the cost-per-classification at scale matters when the customer's mesh has five thousand nodes.

The forty-plus structured tools are the bridge between the two models and the platform's typed configuration. The AI does not write free-form configuration changes that the platform tries to parse; the AI generates structured operations against typed tools (`update_firewall_policy`, `create_dns_filter`, `enable_split_tunnel`, `failover_to_backup_path`, the rest of the catalogue), and the typed operations are what actually apply against the configuration. The architectural property is that the LLM's output is constrained by the platform's type system rather than being free-form.

The destructive-action discipline is explicit and is the operational property that lets the customer trust the AI in production. Changes that modify firewall rules, change traffic routing, mutate the security posture, or affect access require explicit confirmation. The AI surfaces the proposed change, the impact preview, and the consequences before applying; the human confirms by clicking Yes (or types Yes in the chat). For the most destructive actions — those that could disconnect the customer from their own network or break critical-path access — the confirmation requires the operator to type the action verbatim, not just click confirm.

The five-minute undo window applies to every action regardless of severity. The platform snapshots the previous state before every change; the customer can revert the change with one click for the next five minutes. The window is short enough to keep the audit log compact and long enough to catch the immediate "wait, that wasn't what I meant" recovery the operational workflow needs.

“ AI as the control plane, not the chatbot. The forty-plus tools, the dual-model architecture, the typed-output discipline, the explicit confirmation gates — all of it adds up to "an autonomous agent the customer can actually trust in production."

#Three-minute deployment: one Docker command, three steps

The deployment story is the part of the platform that determines whether the customer's rollout actually completes. The published target is three minutes per site, and the team has been deliberate about making this verifiable rather than aspirational.

Step one is the Docker pull and registration, which takes about thirty seconds. The customer runs `docker run -d --name sdwan-agent --cap-add NET_ADMIN --network host -e CONTROLLER=https://api.quicksdwan.com -e AUTH_KEY=your-key-here quicksdwan/agent:latest` on the site's primary node. The agent pulls from the registry, the container starts, the agent registers with the controller using the customer's pre-issued auth key, and the dashboard reflects the new node's online status. The customer can verify this step from the dashboard within the first thirty seconds.

Step two is the WireGuard auto-connect, which takes about sixty seconds. The agent generates a WireGuard keypair, exchanges keys with the controller's peer-discovery surface, and brings up tunnels to the customer's existing mesh peers automatically. Peer discovery completes in seconds; for a customer with three existing sites, the agent finds and establishes tunnels to all three. The full mesh is active at this point — the new site is reachable from the existing ones and vice versa.

Step three is the security activation, which takes about ninety seconds. The agent syncs the customer's firewall policies (DNS filtering rules, SNI blocking rules, protocol rules) from the controller and applies them locally. The DLP monitoring engine starts. The anomaly detection comes online and begins computing baselines against the local traffic. By the end of step three, the site is fully operational across every layer of the platform's capability stack.

The total elapsed time is roughly two minutes and forty-seven seconds in the team's published example. For multi-site rollouts, the customer can run the Docker command across all sites in parallel via Ansible, Terraform, or a custom deployment script — the per-site deployment time scales as parallel work rather than sequential. A twenty-site rollout completes in approximately three minutes total when the deployment is parallelised.

The absence of hardware shipping, on-site installation, and certificate management is the operational property that distinguishes the platform from the established box-based SD-WAN deployment. The box-based deployment for the same twenty-site rollout would take a quarter of operator-team capacity and would land tens of lakhs of rupees in hardware before the network is even up. The platform's deployment lands the network in three minutes for the price of the customer's existing compute (the Docker container runs on whatever the customer already has at the site — a small Linux VM, a router with Docker support, a Raspberry Pi at the edge of the office).

#Predictive anomaly detection: z-score, 4 types, 60-second cadence

The anomaly detection surface is the operational property that distinguishes "we have a network" from "we have a network that warns us before users start filing tickets." The platform ships predictive anomaly detection by default on every node, running every sixty seconds across the full mesh.

The detection methodology is z-score analysis against rolling baselines. Every metric the platform tracks — bytes per second per direction, latency to the controller, packet loss rate, flap count — has a rolling baseline computed over the past fourteen days. The current minute's reading is compared against the baseline's mean and standard deviation; a z-score above the configured threshold flags an anomaly. The threshold is per-anomaly-type and per-severity-level — a z-score of 2 might flag low severity, a z-score of 3 might flag high, a z-score of 4 might flag critical.

The four anomaly types cover the dominant patterns the customer needs visibility into. Traffic spike (the node is seeing materially more bytes per second than its baseline supports — could be a legitimate event like a launch or a problem like a DDoS). Latency anomaly (the node's latency to the controller has degraded measurably — could be local network congestion or a cloud-side issue). Packet loss (the connection between this node and its peers is dropping packets at an elevated rate — could be a bad link or congestion downstream). Node flapping (the node is transitioning between connected and disconnected states more frequently than baseline — could be a flaky link or a power issue).

Severity scoring is structured into four levels: low, medium, high, critical. The dashboard surfaces all four severity levels with the appropriate visual treatment; the AI chat surface pushes high and critical detections as proactive alerts; the auto-remediation policies can match on severity to scope which detections trigger automated action versus which surface as advisory.

The 10-minute cooldown is the alert-fatigue protection. After a detection fires on a specific node for a specific anomaly type, the platform suppresses additional detections for the same node-and-type for the next ten minutes. The cooldown is enough to prevent the conventional alert storm (one anomaly producing thirty alerts over ten minutes) while being short enough that genuinely persistent issues continue to alert after the cooldown.

For the SOC team running on the platform, the predictive surface is the operational primitive that produces meaningful early warning. The team gets the alert before users file tickets; the AI chat surface can recommend the diagnostic path; the auto-remediation engine can handle the canonical patterns without operator intervention. The customer who previously ran reactive networking ("users complained, so we investigated") moves to proactive networking ("the platform alerted, we responded, users didn't notice").

#Auto-remediation: define the policy, AI handles the rest

The auto-remediation layer is the part of the platform that converts predictive detection into operational outcome. The architectural pattern is simple: the customer authors "if-then" policies in natural language, the AI translates them to structured remediation primitives, and when detections match the policies the platform applies the remediation without operator intervention.

The canonical policies are short and operational. "If traffic_spike on any node, severity high or above, auto-reroute traffic to backup path" — the platform watches for traffic spikes at high severity, reroutes the affected traffic to the backup link, logs the action, notifies the admin chat. "If latency spike on any node above 200ms for 60 seconds, failover to nearest healthy node" — the platform watches the latency, fails over when the threshold trips, restores when latency recovers. "If packet loss on any node above 5% for 30 seconds, alert + recommend investigation" — the platform watches for packet loss, alerts the admin chat with the diagnostic context, does not auto-act but surfaces the recommendation.

The structured remediation primitives the platform exposes are the operations the network team would otherwise execute by hand: reroute traffic to a designated backup path, failover to the nearest healthy node, throttle the offending traffic, alert the admin chat with structured context, escalate to the customer's incident-management surface (Slack, PagerDuty, OpsGenie), or apply a custom playbook the customer has authored. Each primitive is itself audit-logged and reversible within the five-minute undo window that applies to every action on the platform.

The published example shows the full loop. At 12:04:32 the platform detects a traffic spike on `mumbai-gw-01` with z-score 3.2, classified as high severity. At 12:04:33 the matching auto-reroute policy fires; the platform begins rerouting traffic via `mumbai-gw-02`. At 12:04:34 the reroute completes (1.8 seconds elapsed); the platform creates a recommendation ticket for human follow-up. At 12:04:35 the alert is pushed to the admin chat with the full context. The cooldown is set to ten minutes; the next anomaly on the same node for the same type will suppress until then.

The principle the team has been explicit about is that auto-remediation is for the canonical patterns that the network team has explicitly authorised — not for the AI to take arbitrary action on the customer's mesh. The customer authors the policies; the platform applies them. The autonomy is bounded by the customer's explicit authorisation. For the cases that fall outside the authored policies, the platform alerts and recommends but does not act; the operator stays in the loop for the unfamiliar shapes.

#Natural-language firewall policy

The firewall-as-a-service surface is the layer most customers interact with most directly, and the natural-language authoring discipline is the property that distinguishes it from the conventional firewall configuration UI.

The conventional pattern is the firewall-rule editor that requires the operator to know ACL syntax, the platform's specific rule precedence, the difference between DNS filtering and SNI inspection and protocol blocking, and the operational gotchas of each. The skill ramp is real and is what keeps firewall management as a specialist function rather than a general-purpose team capability.

The platform's pattern is that the operator describes the desired behaviour in plain English and the AI generates the structured rule. "Block all social media during work hours" produces the structured rule set: DNS_BLOCK for the social media domain patterns (`*tiktok*`, `*instagram*`, the rest of the well-known set), SNI_BLOCK for the corresponding hostname patterns at the TLS layer (catches the cases where the device knows the IP and bypasses DNS), time-window restriction for the configured work hours, applied to the configured set of networks. The operator reads the structured rule before applying, confirms, and the rule deploys to all edges in sub-second propagation.

The example library on the brand site is concrete and instructive. "Block gambling and adult content on all office networks" produces the DNS_BLOCK and SNI_BLOCK rule set with the appropriate category patterns, applied to four networks and forty-eight nodes, propagated in 0.6 seconds. "Allow only HTTPS and SSH from dev network" produces the protocol-level rule that whitelists ports 443 and 22, blocks everything else outbound from the dev network. "Run SOC 2 compliance check on all networks" produces the audit query that returns the compliance state across the mesh.

"Analyze capacity and recommend tier upgrade" is the diagnostic shape that converts the AI-assistant pattern into a network-operations primitive. The platform reads the recent traffic data, applies the capacity-headroom analysis, and produces a recommendation the operator can act on (or ignore, or refine). The AI is not just authoring rules; the AI is also surfacing the operational insights that would otherwise require the operator to run a manual analysis pass.

For the operator, the operational result is that policy authoring becomes a chat conversation rather than a UI navigation exercise. The customer's previously-specialist firewall configuration becomes a general team capability — the engineering lead can author the change, the security lead can author the change, the operations lead can author the change, without each needing to develop the deep firewall-DSL fluency the conventional pattern required.

#How QuickSDWAN compares to the alternatives

The SD-WAN and SASE category has a clear set of established names and it is worth being direct about how the platform sits against each.

Cisco SD-WAN is the F500-tier enterprise incumbent. Cisco's install base, support footprint, and procurement gravity are all real. The platform sits below Cisco on raw deployed scale and meaningfully above Cisco on operator throughput — the AI-control-plane discipline is structurally faster than the conventional console pattern Cisco ships. For the F500 customer whose alternative is private MPLS and whose procurement is already Cisco-shaped, Cisco is reasonable. For the mid-market customer whose primary frustration is console velocity, the platform is the differentiated alternative.

VeloCloud (now VMware SD-WAN), Silver Peak (now Aruba EdgeConnect), and Versa Networks are the closer peers in the mid-enterprise SD-WAN tier. They are competent within their tier and structurally heavy for the mid-market deployment shape. The platform extends past them on the AI-control-plane dimension and on the deployment story — three minutes per Docker site versus the multi-week per-site deployment the established mid-tier vendors typically require.

Cloudflare Magic WAN and the cloud-hyperscaler SD-WAN alternatives (AWS Cloud WAN, Azure Virtual WAN) are the cloud-native alternatives that have emerged over the past several years. They are appropriate for customers whose mesh is mostly cloud-to-cloud and whose primary operational shape is "deploy the network as code through Terraform." The platform is the alternative for customers whose mesh includes meaningful on-premises and branch-office presence and whose operational shape is "let the AI handle the day-to-day."

The smaller modern entrants — Cato Networks, Perimeter 81 (now Check Point Harmony SASE), Twingate at the smaller-deployment tier — are the closer peers on the modern-SASE dimension. They are competent within the SASE feature surface and ship the conventional console pattern. The platform's extension is the AI-control-plane discipline and the unified single-platform deployment story; for buyers comparing on the modern-SASE feature surface, the AI dimension is the differentiator that matters most.

For the broader "we have a small VPN setup and need something more" upgrade path — customers running OpenVPN, WireGuard manually, or one of the established consumer-grade mesh-VPNs — the platform is the right-shape destination for customers whose growth has pushed them past the manual-VPN tier and into the "we need actual SD-WAN" requirement.

#The team and the operational substrate

QuickSDWAN is built and operated by Ollasoftware, the AI software development company headquartered in Bengaluru that has shipped more than forty AI brands in production over the last four years. The platform is part of the team's broader networking and AI-operations portfolio that includes QuickZTNA (the zero-trust mesh with the AI Operator), MeshWG (the hosted mesh for existing routers), and OllaVPN (the post-quantum consumer VPN). The shared operational substrate and the shared AI-tooling discipline across the portfolio are part of why the team can ship the breadth the platform covers without the headcount the established SD-WAN vendors require.

The dual-model architecture (Claude + Groq LLaMA 70B) is built on top of the team's broader LLM-routing infrastructure that ships as Ollima and Switchllm in the consumer-facing portfolio. The choice to use Claude for the high-reasoning tasks and Groq for the high-throughput tasks is the architectural pattern the team has standardised on across the portfolio; the platform inherits the model-routing discipline rather than reinventing it.

The parent group, Networkers Home, is the cybersecurity and networking training institute that has placed more than forty-five thousand alumni across eight hundred hiring partners since 2007. The institutional context matters here meaningfully because SD-WAN is precisely the disciplinary inheritance the parent group has been teaching for two decades — Cisco SD-WAN, Palo Alto SD-WAN, Fortinet SD-WAN, the conventional networking-vendor disciplines. The team's background includes the operators the platform is built for.

#What is on the roadmap

The team publishes the roadmap on the brand site and updates it as work ships. The visible near-term threads are concrete: an expanded AI tool catalogue beyond the current forty-plus (the next wave focuses on the operational workflows customer feedback has surfaced — capacity planning, incident response, security audit, compliance reporting), deeper integration with the conventional ITSM platforms (ServiceNow, Jira Service Management, PagerDuty) so the AI's remediation actions can fan into the customer's existing ticketing surface, and expanded auto-remediation primitives for the patterns customer policies have surfaced.

Underneath those visible features is steady investment in the dual-model architecture. The current Claude + Groq pairing is the right balance for the workloads the platform serves today; the team is watching the model landscape closely and is prepared to swap either side when meaningfully better options emerge for the specific workload shapes. The architectural decision is that the model choice is workload-driven rather than vendor-driven.

On the security side, the team is investing in the DLP and CASB surfaces that the SASE feature checklist requires. The current DLP coverage handles the canonical sensitive-data patterns competently; the roadmap extends to richer pattern libraries, customer-authored detection patterns, and the integration with the customer's existing data-classification systems for the customers running those.

Pricing during the current phase is the published per-node tiered model with the conventional SASE-tier shape. The team has signalled that the per-node pricing will stay competitive against the established SD-WAN alternatives at every comparable volume; the AI-control-plane discipline is not gated behind a higher tier — every customer gets the same AI authoring surface regardless of tier.

#How to start

If you run a distributed network — multi-site offices, hybrid-cloud workloads, remote workforces with networking needs that have outgrown the simple VPN setup — and the console you currently fight with is the operational bottleneck rather than the underlying network, the right next move takes about three minutes. Sign up at quicksdwan.com, create your first network in the dashboard, copy the Docker command, and run it on one site.

The three-minute target is verifiable. The agent pulls in thirty seconds, registers and connects to the mesh in another sixty seconds, and brings the firewall and DLP and anomaly detection online in the third minute. The full three minutes is observable from the dashboard — the customer can watch the agent come online, watch the WireGuard tunnels form, watch the security stack activate.

For the second site, the same Docker command (with the same auth key) deploys the agent. The mesh discovery is automatic; the new site finds and tunnels to the existing one within the deployment window. For the third, fourth, and N-th sites, the same pattern repeats. The customer can run all of them in parallel via Ansible if the operational team has the automation in place; the per-site deployment time stays constant regardless of how many sites are deploying in parallel.

For deeper evaluation, the AI chat surface in the dashboard is available immediately after the first site comes online. The customer can ask for a sample policy ("Block social media during work hours" is the canonical first ask), see the AI generate the structured rule, see the impact preview, and decide whether to confirm. The customer is not committed to applying any AI-generated change; the preview-then-confirm discipline lets the customer evaluate the AI's judgment before committing to it.

If you would like the team to walk you through a specific deployment — particularly the migration from an established SD-WAN vendor, the large-scale multi-site rollout, or the Enterprise contract for a regulated-vertical deployment — the Ollasoftware contact page reaches the engineers who built the platform directly.