Features
Aorka isn't one thing. It's a handful of pieces that hand work off to each other — the agent goes on the machine, the knowledge base remembers what it found, the model proposes a script, an evaluator scores it, you approve, the engine sequences the phases. Here is each piece, in the order it fires on a typical request.
Aorka starts in the chat window. You describe a problem in the words a tech would use to describe it — not a cmdlet, not a ticket template, not a structured query. The model reads what you said, pulls the relevant facts out of the knowledge base for the endpoint or unit in question, drafts a script when one is needed, and waits for you to say go.
Conversations are scoped to a unit by default, so the context the model gets is the context for the place you're working — not an opaque corpus and not the entire fleet.
See it move
Plan cards, risk scores, the approval the operator clicked, the script behind it. Pick a session from the gallery and it plays.
The agent on each endpoint collects facts and runs them again on a schedule. The knowledge base is not a wiki — it's a record of what the agent measured, when it measured it, and how confident it is that the measurement is still true. Stale insights decay and surface themselves; the things that matter get revalidated automatically.
Three kinds of insights live in the base: facts for measurable values, understandings for lessons and operational context that wouldn't be obvious from a config, and procedures for known-good recipes. The model retrieves all three when it's working on something for you.
A sample from the knowledge base for LW-DC-01
spool\PRINTERS, restart, verify queue.
Every script the model proposes is read three times before anything touches an endpoint. A regex command filter classifies the operation by what it does. An AI evaluator scores the blast radius. An approval gate routes the script by risk tier — some auto-execute, some need an operator to acknowledge, and some are rejected outright with no override.
Units are read-only by default. A tenant admin unlocks a unit for writes only after the deployment has been verified end to end. New clients onboard locked.
The shape of the pipeline is sketched on the home page. The diagram is the same thing in fewer words.
The first time the model writes a script to solve a particular kind of problem, it goes through the safety pipeline like any other script. When it works, it gets kept. When it gets reused, its success ratio gets tracked. Over time the library becomes a record of what actually works on real fleets — not a list of suggestions from a manual.
Search is semantic. Describe the problem in plain English and the library returns scripts whose past descriptions match the meaning of what you said. The success ratio is shown alongside the result so you know what you're picking up.
Domain admin passwords, firewall logins, SQL sa — the credentials your techs need to do their work, kept out of shared spreadsheets and shoulder-surfed sticky notes. The vault encrypts each credential with its own key, requires a second factor to view, and injects secrets into agent sessions at run time so they never touch the endpoint's disk.
Every read is logged. Webhook alerts fire when a high-trust credential is accessed outside its expected pattern.
The agent ships as a signed MSI. Push it through GPO, Intune, NinjaRMM, JumpCloud, or anything else that can push an MSI. The agent talks outbound only — no inbound firewall rules, no VPN, nothing for the security team to argue about.
Once the agent is on a machine, it shows up in the console within a minute. You can also push from the console directly — no RDP, no manual steps, no watching a progress bar.
Multi-phase work — patch rollouts, migrations, onboarding sequences — runs as a directed graph of phases and steps. The engine handles sequencing, fan-out across endpoints, and failure propagation. Between phases, the model reads the results and decides whether it's sensible to keep going.
A runbook fails like a runbook should: when one machine in a fan-out fails, downstream phases that depend on it stop; independent work keeps moving. There's a real audit trail.
Aorka exposes its tools over the Model Context Protocol. Connect Claude Code, Codex CLI, Gemini CLI, or anything else that speaks MCP. The same safety pipeline runs. The same approval gates fire. The tools you already prefer get infrastructure awareness for free.
Write scripts coming in through MCP require browser approval before they execute, regardless of who's on the other end. The pipeline doesn't care if the request came from a human in the console or a CLI in a terminal.
.claude.json
{
"mcpServers": {
"aorka": {
"url": "https://aorka.com/api/mcp",
"headers": {
"Authorization": "Bearer …"
}
}
}
}
Eight pieces, in the order they fire. If this is the shape of the tool you've been wanting, the home page has the demo signup.
Request access