Two agents, one loop, a technician in charge
The routine work of a service desk is repetitive by definition: read the request, work out what it is, check the device, apply the known fix, tell the client. BIASHARA puts agents on that path, inside the platform, with the permissions and approval rules you set.
Inside the platform, not bolted to the side
An assistant that sits outside your tools can only talk about work. It has to be told what a device is, it cannot see the monitoring history, and it has no way to apply a fix or prove that the fix held. That is why most automation projects in managed services stall at the demonstration.
The BIASHARA agents run inside the platform. They read the same ticket, device, inventory and event records a technician reads, they act through the same scripting and remote channels, and they are bound by the same identity layer, so an agent can never reach a tenant, a machine or a command that its role does not allow.
That places them in the only position where routine work can actually be finished rather than described: close enough to the data to be right, and close enough to the controls to be useful.
- Where they runIn your deploymentThe agents are part of the platform you host, so the client data they read stays inside the boundary you already defend.
- What they seeOnly their assigned tenantsAgent credentials are scoped like a technician's: per client, per device group, per module, and they expire.
- What they may changeWhat you allow, and nothing elseActions are declared. Reading a monitor, drafting a reply and running an approved script are separate permissions.
- When they stopAt the approval gateAnything that alters a client environment pauses for a named technician, with the proposed change and the dry run attached.
- What they leave behindAn auditable trailClassification, draft text, script version, approver, output and verification are written to the record for every action taken.
Every ticket is met the minute it lands
The first minutes of a ticket decide how the rest of it goes. The triage agent spends them well: it reads the request properly, answers the client, and does the collecting a technician would otherwise do before any real work could start.
- 01Read and classify
- The request is parsed for what it actually is, not for the words the client used. A message titled "computer slow" that describes a mailbox is classified as a mail issue, matched to the client contract and prioritized against the service level target that applies.
- 02Identify the estate involved
- The agent resolves the sender to a client contact, the contact to their devices, and the devices to their current health, patch state and recent changes. The ticket arrives with the affected machines already linked.
- 03Answer in your voice
- A first reply goes out in the tone and format you configure, confirming what was understood, what happens next and when the client should expect an update. Clients get an answer rather than an automated receipt.
- 04Assemble the evidence
- Monitoring history, related tickets, the applicable runbook and any correlated security events are attached to the ticket, so the technician who picks it up starts from a prepared case.
- 05Propose the next step
- Where the fault is well understood, the agent names the likely fix and stages it, handing the work to the scripting agent for a dry run. Where it is not, it says so and escalates with a clear summary instead of a guess.
It writes the script, you decide if it ships
The scripting agent does the hands-on work: drafting remediation for the right platform, testing it where testing is safe, and presenting it for approval with the evidence that it behaves as described.
-
01
Draft
The agent writes the remediation for the target operating system, using your approved library first and only writing something new when the library has no answer. Parameters are explicit and the intended change is stated in plain language.
-
02
Test
The script runs in a sandbox that matches the target build. The agent reports what changed, what it touched that it did not expect to touch, and whether the verification step passed.
-
03
Approve
A named technician reviews the script, the dry run and the target list, then approves, edits or rejects. Nothing reaches a client machine without that decision, and the decision is recorded with the change.
-
04
Apply and verify
The approved version runs on the agreed targets inside the agreed window. The agent checks the condition it was asked to fix, writes the outcome to the ticket and stops if the verification fails.
One alert, followed through to the end
Because monitoring, tickets, scripting, inventory and security sit in one platform, a signal can become a finished piece of work. Here is a sequence that runs on an ordinary Tuesday, with no human involvement until the approval.
- 01A monitor fires
- Free space on a client file server falls below the threshold set for that contract. The monitoring module raises one incident and attaches the device record, its role and its recent performance history.
- 02The signal is correlated
- The platform matches the timing to a backup job that has been overrunning for three nights and to a software deployment from last week. The incident now has a probable cause rather than a symptom.
- 03A ticket is opened and the client is told
- The triage agent opens a ticket against the correct client and priority, notes the correlation, attaches the runbook and sends the client a short message saying the condition was detected and is being worked on.
- 04A remediation is proposed
- The scripting agent drafts a cleanup limited to the paths the runbook permits, tests it in the sandbox, and presents it with the expected space recovered and the verification step it will run afterwards.
- 05A technician approves
- One person reads the proposal and the dry run, then approves it for the maintenance window. This is the first and only human step in the sequence, and it takes about as long as reading this paragraph.
- 06The loop closes
- The script runs, the verification passes, the monitor clears, the ticket closes against the service level target, the inventory record updates and the backup overrun is raised as a separate piece of work so the cause is fixed too.
Guardrails that are yours to set
Automation in a managed estate is only acceptable if it is governable. Every agent behaviour is a setting, every action is attributable, and the whole thing can be turned down or turned off without taking the platform with it.
Define which actions run freely, which require a technician and which require a client sign-off as well. Read-only work such as classification and evidence gathering can run on its own, while anything that writes to a client environment waits for a person.
Agents authenticate like staff. They hold a role, the role holds permissions, the permissions are limited to named tenants and device groups, and credentials expire on a schedule you choose.
Automation respects the maintenance windows already agreed with each client. Work found outside a window is staged rather than applied, unless you have marked the condition urgent enough to override it.
The audit trail records which agent acted, under which role, on whose approval, against which device, with which script version, and what the result was. Agent actions are not a separate log you have to reconcile.
The agents run within the deployment you operate. Client records are processed inside that boundary, and what leaves it, if anything, is a deployment decision you make and can document for a client audit.
Any behaviour can be disabled per client, per queue or entirely, and the platform keeps working as a conventional console. Nothing in the product depends on automation being switched on.
What the agents are not for
Being clear about the edges is part of making automation usable. The agents are good at well-understood, repeatable work with a verifiable outcome. They are not a replacement for engineering judgment, and the platform does not pretend otherwise.
In practice this means a service desk keeps its people and spends their hours on the work that actually needs them: project delivery, architecture, difficult faults, and the client conversations that decide whether a contract renews.
- They do not design a client's infrastructure or decide a migration strategy.
- They do not approve their own changes, and they cannot grant themselves permissions.
- They do not touch a system outside the tenants and device groups assigned to their role.
- They do not improvise on a failed verification. The work stops and a technician is told.
- They do not handle the commercial relationship, the contract or the escalation call.
- They do not replace a change process. They operate inside the one you already run.
What operators ask first
It depends on the shape of your queue, and anyone quoting a single percentage without seeing it is guessing. The honest answer is that the gains come from the repetitive tail: password and profile issues, mail and sync faults, disk and print problems, onboarding steps, patch follow-up and status updates. Start by having the agents triage everything and act on nothing, measure how often their classification and proposed fix were right, then widen the permissions where the record justifies it.
Four things, and they are independent of each other, so a failure in one does not become an incident.
- Permissions: the agent role cannot reach tenants, devices or commands outside its scope.
- Sandbox testing: a change is executed against a matching build and reported before it is offered.
- Approval: a named technician authorizes production execution, and the approval is recorded.
- Verification: the agent checks the intended outcome and halts on failure rather than retrying blindly.
That is your decision and it is a setting, not a hidden default. You configure how replies are signed, whether automated messages are labeled, and which queues or clients are excluded from automated correspondence entirely. Many providers label automation on first reply and keep a named technician on anything that follows, which clients tend to find reasonable when it is stated plainly.
They get better inside your deployment, because the material they work from is your script library, your runbooks, your classification corrections and the outcomes recorded on your tickets. When a technician edits a proposed script or recategorizes a ticket, that correction is part of the record the agents work from next time. Your operational data is not pooled with another provider's to make that happen.
You treat it like any other change that did not go to plan, with the advantage that the record is complete. The audit trail holds the classification, the script version, the sandbox result, the approver and the verification output, so the review is a factual exercise rather than an archaeology project. Then you narrow the permission, fix the runbook or adjust the approval gate, and the same mistake stops being available.
Put the agents on your own queue
Describe the shape of your service desk, the tickets that repeat most often and the approval rules you need to honor. We will tell you where the agents help and where they will not.