Iniciaste sesión como:
filler@godaddy.com
From a network question to a ticket someone can act on.
One continuous Nashira session, in the order it happened — including the part that failed.
Ask Nashira what is happening. It checks the device is in inventory and reachable, runs the read-only commands, brings the output back into the conversation — and when the next step changes a system outside the chat, it stops and asks you first.
The conversation carries the evidence.
The answer is not detached from the work that produced it.
What was called, with which arguments and what came back sits next to the sentence written from it.
The operator types one sentence — "Can you check on node l1 for me? I need to see what version it's running and the state of its interfaces" — and names no command, no syntax and no device path.
Nashira states what it intends to do before it does it, and waits. The inventory held two devices matching "l1", so it says which one it picked and why — the one with a credential assigned — instead of choosing silently.
It checks before it trusts: inventory says the device exists; the reachability check says it answered in 2 ms. Every call is accounted for: the reply ends with a ledger of what ran — show version succeeded, show interfaces failed as invalid on SR Linux. The version, chassis, build and interface state that come back are the device's own output, not a summary of it.
Ask, plan, approval, execution and raw device output — in one screen, in that order.
The first command failed. That is in here too.
What I could not get
A section headed "What I could not get", the parser error quoted verbatim, and a per-command ledger: show interface succeeded, show lldp neighbor failed.
It looked up the right command
It did not guess. It asked the catalogue for platform nokia_srl, intent show_lldp_neighbors, got the command back, and ran that.
One intent. The right command for each platform.
"Show me the LLDP neighbors" is not a command — until Nashira knows what the device is.
It becomes one only once Nashira knows what the device is — which is exactly the lookup you just watched it make.
The catalogue maps an operational intent plus a platform to the CLI command that expresses it. In the previous section you saw it called by name — platform nokia_srl, intent show_lldp_neighbors — and return the syntax that box accepts.
Every entry is classified read or write before it can be used, and that classification is what the permission and confirmation rules act on. A read runs; a write asks.
The banner at the top of that screen is not staged. Nashira is reporting that one platform present in the inventory has nothing catalogued yet, so intents will resolve to a 404 on those devices. We left that in as well.
196 commands across eight platforms, each tagged read or write — including the warning that one platform is not covered.
Ask it once in chat. Repeat it as a deterministic workflow.
A one-off diagnostic belongs in the conversation. The same check on a schedule belongs in a workflow
Once stored, a Nashira workflow runs the code it was built with. It is not re-planned by a language model on each execution, and it does not consume model tokens unless a step deliberately calls one.
The run keeps the workflow it came from, who started it, the environment it ran in and the outcome of every step — so a result can be defended later without running it again.
Explicit steps: what was prepared, executed, collected and saved, in order, with the output of each step. Controlled lifecycle: a workflow is simulated and tested before it is promoted through its environments to production. Inspectable outcome: changed, unchanged, failed and skipped stay distinguishable — "it ran" and "it changed something" are not the same claim.
A real run in production: seven steps, four changed, none failed, seven seconds.
It shows you the ticket before it opens it.
What I will do
"What I will do", field by field, and "Reply confirm and I'll create the ticket". The operator replies "confirm".
INC0010004 created
Incident INC0010004, 201 Created, mail sent — and a ledger of the five calls it took, including the discovery call that missed first.
See what ran, who started it and what changed.
Runs, traces and audit entries are three views of the same operation.
A polished answer is not evidence. The record is.
Audit entries can be filtered by entity, action, actor, request and date, so a question asked weeks later — who changed this, and on whose authority — has an answer that does not depend on anyone's memory.
Every governed action is written to a trail chained from its first entry, so an alteration or a gap in the history is detectable.
The audit view, filtered the way a reviewer would filter it.
