An agent can earn an operator’s confidence by showing its recommendations on the work it will handle before receiving permission to change live systems.
A deployment can begin with observation and proposed actions, then expand its execution scope through explicit operator decisions. That creates a record of behavior before a mistake can become a service-affecting change.
I've spent years building automation tools for ISP operators, and I know their tolerance for unexpected behavior is very low. These are operators running 24/7 networks where an unexpected automated action at 2am does more than generate a support ticket; it wakes someone up. Trust in this environment is earned slowly and lost instantly.
XSI LodeStone’s deployment design starts in Shadow Mode.
The agent can inspect permitted information and propose actions while the execution layer blocks writes to managed systems.
What Shadow Mode Actually Is
In the deployment design, Shadow Mode covers read-only advisory work and shadow-write proposals. Within its permitted scope, the agent can inspect telemetry, run diagnostic queries and recommend actions. It records the proposed action for operator review while writes to managed systems remain blocked.
Shadow operation gives operators recommendations to compare with the actual events, their own decisions and observed outcomes.
Four permission scopes
The design separates four permission scopes. Each expansion requires an explicit operator decision:
- Read-only advisory. The agent monitors, diagnoses and recommends using permitted information. It has no write access to managed systems.
- Shadow write. The agent prepares and records the proposed action sequence for review. The sequence remains a proposal; the agent has no permission to execute it.
- Scoped autonomous write. The agent can execute approved classes of write operation under the assigned policy. Validation, scope and applicable authority determine eligibility; a confidence score alone cannot authorize the action.
- Service-affecting authority. An operator can separately authorize defined operations that affect service. That decision needs its own scope, operating conditions and audit record.
The execution layer enforces the permissions assigned to each scope. An agent’s own recommendation or confidence score cannot grant it write access. Changing the scope requires the authorized operator’s decision.
Review the evidence before expanding authority
An operator needs to know which scenarios the agent handled correctly, which it escalated and which it misunderstood. Aggregate success can hide a rare but consequential error.
The operating record gives the operator a basis for deciding which workflows can receive broader authority.
Track recommendations against reviewed outcomes over a defined observation period. Record incorrect actions, missed escalations and the evidence available at the time. Use that record to decide which specific workflows are ready for broader authority.
Compare recommendations with what happened
Select diagram to enlargeKeep an accountable operating record
Operators remain accountable for the activities delegated to their systems. The applicable privacy, security, reporting and service obligations depend on the workflow and deployment.
The audit ledger records proposed and executed actions with the triggering event, model, action, authorization and observed outcome. Access controls and retention protections must preserve the integrity of that record.
The Trust Argument
An operator can begin with read access, observe recommendations and authorize specific write operations as the evidence supports them. Each change has defined limits and remains under the operator’s control.
Shadow Mode gives the agent a defined view of the work and gives the operator a record to evaluate. Authority changes only when the operator decides to change it.
