We get network automation into production. On the platform you already own.

Four kinds of engagement. All of them aim at the same thing: a change reaches the network without a person typing it, and with evidence that it worked.

1. 01Stalled project rescueFind out why the project stopped. Get one real workflow into production.
2. 02Workflow platform deliveryCisco NSO, Cisco Crosswork, NetBrain, Forward Networks. The layer that touches devices.
3. 03Process mapping and pipelinesMap how changes happen today. Build the pipeline that makes them happen automatically.
4. 04Custom tools and integrationsWhen the platform has a gap, build the tool. AI-assisted where it speeds delivery.

• The platform has been installed for months and only a handful of workflows run in production.
• Changes still arrive as tickets and an engineer still types them in.
• The person who built the automation has moved on, and nobody wants to touch it.
• The platform does 90% of the job and the last 10% needs a tool nobody has time to build.
• You want a second opinion before buying another platform.

Why automation projects stall explains the seven patterns we see most often.

It starts with a 30-minute call with an engineer: no slides, no demo unless you ask for one. You get a short written note afterwards with what we would do first, or who we think is better suited. From there the work runs in stages, each priced before it starts.

1. 01

   Assess

   2 weeks, fixed price

   A read-only review of the platform, the process, and the team against the seven patterns that stall automation projects. Versions, packages, sync state, repository history, change records, and interviews with the engineers who build it and the operators who are meant to use it.

   You get: A scorecard with the evidence for each finding, a risk list, and a 90-day plan that names the first workflow to put in production.

2. 02

   Deliver

   6 to 8 weeks, fixed price

   One or two workflows chosen in the assessment, built, tested against a simulator or a lab, and put into production. Git as the source of truth for the code, a pipeline with dry-run review on every merge request, and a reconciliation plan for devices that have drifted.

   You get: Workflows in production with test cases and a runbook each, a repository and pipeline the team has used, and handoff sessions with the client's engineers.

3. 03

   Run

   Monthly retainer

   Senior automation engineering on a set number of days each month. Platform and driver upgrades on a cadence, new workflows, small tools where the platform has a gap, and code review with the team. Pairs naturally with a NetStacks support plan.

   You get: A platform that keeps moving after the project ends, without a full-time hire.

NetStacks, our terminal and controller, is the tool we publish under our own name. It is not the only one. Most of what we build belongs to clients and lives in their repositories, so we describe it here rather than name it:

• AI operations agentsChat and chat-ops agents that run read-only device commands over SSH, NETCONF and gNMI, query inventory and ticketing, and stop for a person's approval before anything changes.
• Operator portals and formsSo a NOC engineer can run a workflow from a form instead of logging into the orchestrator.
• Ticketing integrationsServiceNow and Jira wired to the platform that makes the change, with results written back to the ticket.
• Service packages and modelsOrchestration service models with the inputs operators have, and a dry-run diff they can read.
• Change pipelinesPre-checks, dry runs, approvals and post-checks in GitLab CI or GitHub Actions, with evidence kept for every change.
• Drift and compliance reportsBuilt from data the network already produces, on a schedule, without a new platform.
• Parsers and collectorsFor the devices and outputs a platform does not cover out of the box.
• Lab and test harnessesSimulators and test suites so a change or an upgrade is tried before it is real.

When the gap is something a product should solve, we say so, even when the product is not ours. When it is ours, you can read about NetStacks on its own site.

Independent, hands-on expertise. We are not affiliated with these vendors and do not resell their products; we make the platform you have licensed do the job.

• Cisco NSOService packages, NEDs, YANG models, upgrades, and brownfield reconciliation. Git and a netsim pipeline for every package change.
• Cisco CrossworkChange Automation playbooks built around real change windows. Workflow Manager flows that take a ticket in and hand evidence back.
• NetBrainRunbooks and intent checks before and after every change, triggered from the ticket. Maps that stay current because they are used.
• Forward NetworksIntent and path verification in the change pipeline, so a change that breaks reachability or isolation is blocked before it ships.
• NetStacksOur own controller and terminal, for MOPs with approvals, shared credentials, session recording, and an AI assistant that reads the same CLI the operator does.

1. Start with the process, not the tool.

   Before anything is built, the way a change actually happens today is written down with the people who make it. Automation that skips this step encodes a process nobody agreed on, and that is where most projects stall.

2. One small workflow before any large one.

   The first thing in production is frequent, low-risk, and boring. It proves the path from request to device and gives operators a habit. Scope grows from there.

3. Every change gets a dry run a person reads.

   No change reaches a device without a native diff reviewed by someone who knows the network. If the diff is a surprise, the change does not ship.

4. The platform you own comes first.

   We build NetStacks, and we say when it is not the right tool. The platform a client already owns is the one we make work, and ours comes in only where it adds something the stack does not have.

5. The client can run it without us.

   The measure of a finished engagement is that the client's team can operate, change, and upgrade what was built on their own. Until that is true, the work is not done.

Do we have to use NetStacks?

No. Most engagements do not involve it. The platform you already own is the one we make work. NetStacks comes up only when it fills a gap the existing stack cannot, and we will say plainly when it does not.

Who will we actually talk to?

Engineers. The people on the first call are the people who do the assessment and write the code. Nobody on our side is paid to sell you something.

What happens on the first call?

Thirty minutes, no slides. We ask what platform you run, what the project was meant to do and where it stopped. Afterwards you get a short written note with what we would do first, or the name of someone better suited if it is not us.

How is the work priced?

The assessment and each delivery stage are fixed scope and fixed price, agreed before work starts. Ongoing work after that is a monthly retainer for a set number of engineering days.

What do you need from our team?

For an assessment, read-only access and two to four hours in total from the people who build and operate the platform, spread over two weeks.

Who owns the code afterwards?

You do. Everything is in your repository from day one, written so your engineers can change it after we leave.