FEATURES
One app start to finish: connect, diagnose, fix.
One terminal for the gear you support. Describe a problem and Lina reads the live devices you have open, shows her evidence, and drafts the exact commands for your review. Start network discovery from one device and AI NetShell follows CDP and LLDP neighbors to the devices within your scope, maps the site, and writes the documentation. Backups, diffs, and compliance checks live in the same window.
THE TERMINAL
Open sessions and manage devices from the same window.
Every session, one window
- SSH, RDP, and serial in one app; tabs, split panes, restored workspaces
- Find in terminal; one-click export of session output
- Syntax highlighting, plus your own rules and colors
- The host key is pinned on first connect. Multi-line text is reviewed before it is pasted.
Organize devices and store their credentials
- Organize devices in folders. Store passwords and keys in the encrypted vault, or use your SSH agent or OS keyring.
- Import from CSV, PuTTY, SecureCRT, ssh_config, or known_hosts
- Meraki orgs via a read-only key, with per-network site reports
INVESTIGATION
Investigate with evidence.
show running-config | section ip access-list → 40 deny ip 10.8.0.0 0.0.0.255 host 10.2.5.20
The VPN router has a rule that blocks every VPN user from the accounting server, and it catches her too. No line above it lets her through.
Ask Lina about one device, one session, or a connected site
- Before reading, she lists the commands she will run
- Turn on confirmation for every read when you want to inspect each command first
Answers you can audit
- Each fact names its source device and command
- The app turns supported show-command output into tables
- If she didn't capture it, she doesn't claim it
- Export an investigation as Markdown: technical notes with the full record and evidence, or a short executive summary for a manager or a client
- Or copy it as plain text, ready for a ticket or an email
Transcript
Friday, ten to five. A ticket comes in.
The CFO can't open the accounting server from home.
The engineer on call asks Lina, the assistant built into AI NetShell, one question. Why?
Lina reads the VPN router itself. She verifies the CFO's VPN connection. It's up.
Next, Lina reads the rules that decide what VPN users are allowed to reach.
And there it is. One line blocks every VPN user from the accounting server. It has been blocking them all day.
Lina proposes a fix. One new line, just above the block, that lets the CFO's laptop through. Nothing else changes.
Before anything is sent, AI NetShell saves a copy of how the router is set up right now. That is the way back.
The engineer reads the change. And approves it.
AI NetShell makes the change. Then it reads the router again, on its own, to prove it worked.
And if anyone has second thoughts, undo is one click away.
The CFO is in.
AI NetShell. Network changes you can read, approve, and undo.
The notes Lina wrote for this ticket, exported as Markdown and opened in Obsidian. Real app.
Start on Resolve. It reads freely until you approve a change, and the governed path is ready from day one. Exact fix commands are included at every tier. What each tier adds is listed on the pricing page.
CHANGE HISTORY
Know what changed, and when.
Transcript
Every change made through AI NetShell is written down. Who asked. Why. And exactly what changed.
But not every change goes through AI NetShell.
Here, someone logs into a switch directly, and edits it by hand. No ticket. No record.
The next time AI NetShell takes a snapshot, it compares the switch with the last copy it trusted.
And it flags the difference. A change nobody explained, sitting right above the approved one.
Open it, and it shows the exact lines. What was added. What was taken away.
Now you know what changed, where, and when. Before it turns into an outage.
AI NetShell. Nothing changes on your network without you knowing.
Every change, in order, on one timeline
Manual backups, discovery captures, and the snapshot taken before each approved change all land on the same timeline, each labeled with why it exists. When the platform supplies a supported recovery method, the timeline shows the restore point.
- Compare the configuration captured at any two points, line by line
- A snapshot before every governed change; manual backups are one click
- Ignored lines are listed by name and stay available for review
MAPS & DOCUMENTATION
Start from one device. Map the site and hand over the documentation.
Transcript
Most network diagrams are drawn by hand. Once. Then the network changes, and the drawing doesn't.
AI NetShell starts from a single switch.
You pick it, say how far to look, and approve. That is all you do.
It asks the switch what it is connected to. Then it visits each neighbour, and asks again.
Less than a minute later, the map is done. Every line on it was reported by the equipment itself.
This is the physical view. Which cable goes where.
This is the spanning tree view. Which switch is the root bridge, and how every other switch reaches it.
And this is the routing view. Which devices exchange routes, over OSPF and BGP, and whether each session is up.
Nobody drew this. And when the network changes, you run it again.
AI NetShell. See the network as it really is.
Four pages from the same as-built, exactly as the app writes them.
Before you trust any change plan, you need to know what is actually out there. Give network discovery one seed device, a scope, and a credential profile. It follows CDP and LLDP neighbors, logs into what it reaches inside that scope, and draws the network from what it found. It is not a subnet scan. Devices it could not log into are drawn as not reached.
- Built from what discovery actually saw
- Compare two runs to see what is new and what is gone. If they used different scopes, the app says they cannot be compared.
- Investigate shows every map on screen. Exporting and printing maps, the network report and the as-built package come with Resolve; a paid Resolve plan removes the watermark.
What it reads on each device
Discovery does not scan address ranges. It connects to approved devices and reads their existing operational data.
- Neighbor tables. A switch or router can keep a list of the devices directly connected to it. Where available, discovery reads CDP or LLDP neighbors, and that list is the only thing that hands discovery a new device to try.
- Routing neighbors. Routers keep a list of the other routers they exchange routes with. Discovery asks which routing protocols are running, then reads only those lists: OSPF neighbors, BGP peers, and EIGRP neighbors on Cisco IOS. They draw the Routing view and never cause a connection.
- Spanning tree. It reads spanning-tree port states when the device provides them. That draws the Spanning Tree view.
- Identity. Software version and hardware inventory provide the model and serial number. The app displays the lifecycle match associated with that identity.
The documentation package
- PDF as-built: topology maps, device inventory, OS versions, addressing, physical links, VLANs and trunks, spanning tree, routing, allocated subnets, VLAN and trunk mismatches, end of support, config appendix
- Map images, CSV tables, and every captured running config in one folder
- Every section says "not collected" where a device did not answer, never a blank cell
Files and recovery
- Browse and edit remote files over SFTP
- SCP transfers; a temporary TFTP server for image recovery
- A short-lived syslog listener while you make a risky change
Plans and what each unlocks are on the pricing page. The read-only default applies on every plan. Resolve adds the governed write path.
CONFIG & COMPLIANCE
Check each device against the selected standard.
Standards that answer one question
Does this device match its selected standard, yes or no? Each rule reports pass or fail with its severity. When a required block is missing, the app lists the missing lines.
- Per-role standards. A rule can require a block, or forbid one, such as the plain-HTTP server.
- A library of standard configuration blocks, grouped by intent
- Day-0 assembles a role's baseline config for a blank box over serial
- When a change's audit record matches, the timeline shows its reason and the account that approved it. A drift scan of saved snapshots shows changes made outside the app.
LIFECYCLE
See what is running out of support.
End of support for every device a discovery run finds
- Each device’s end-of-support and end-of-life dates, with a status such as Supported or Past listed support date
- Hardware milestones (end of sale, end of software maintenance, last day of support) on screen and in the End of support section of the documentation package
- Devices without a published date say so, rather than showing a blank
- Software dates cover Cisco IOS XE today
GOVERNED WRITE · RESOLVE
The model proposes. You decide whether anything runs.
Two lists, kept apart on purpose.
Everything the app does falls on one side or the other. The left side runs on its own. Nothing on the right side moves without you.
What it can look at
- Running configuration, interface and protocol state, routing and neighbor tables, logs
- Whatever a permitted show command returns, on one device or across a whole site
- Saved snapshots, past investigations, and discovery runs already in your workspace
Reads run without an approval step, because these read commands cannot alter configuration. Turn on confirmation for every read when you want to inspect each command first.
What it can change
- Only configuration commands allowed by the vendor-specific write policy
- Only on the device named in the proposal you are looking at
- Only after you have read the exact commands and clicked approve
Reload, wipe, and shell-escape commands sit outside this list on every plan. No approval, no policy, and no plan can move them into it.
Every change applied through Resolve passes through this sequence. Nothing skips a step.
Read
It runs permitted read commands and records their output. Reading changes nothing.
Propose
It produces the exact configuration commands, then stops. You review them on a Propose a change screen and preview the change before the approval screen opens. A vendor-specific write policy denies by default, and one line it does not allow stops the whole proposal. A stopped proposal is recorded, so a refusal is as visible as an approval.
Approve
A real pause: you see the named device, the exact commands, and the before-and-after view before any of it runs.
Apply
A rollback point is captured first, then the approved commands run exactly as you read them. On FortiOS, where that is its recovery method, a five-minute device-side auto-revert waits for you to keep the change. Every step is written to an append-only record: who asked, who approved, what ran, and what the check found.
Verify
The app reads the device again and reports what it found, because a command finishing is not proof the job is done. When it cannot confirm the result, it says so.
Roll back
The captured point holds that device's configuration as it stood a moment before the change, and that is what rollback puts back. Where the vendor supports recovery, rollback is included with governed changes. If a newer change is on the same device, the app will not roll back the older one. It names the newer change, so you roll that back first.
What rollback cannot promise. It is offered where the platform's recovery method supports it. It can still fail if the device stops answering or refuses the recovery, so keep an independent way back in for production work.
GET STARTED
Try it on your own gear.
The terminal is free. Paid plans add AI investigation and governed changes.