Predictika · IT service management agent actions

An AI IT operations agent's action, checked before it is carried out

An AI IT operations agent picks up a ticket and proposes one action: implement a change on a configuration item, or grant an access role to a person. Before it acts, the agent sends the action to Predictika, which checks it against a declarative model of the ticket, the agent's permissions, the change policy and the access policy, and returns a verdict, every reason and the figures it computed.

Scope: IT change implementation and access grants for a fictional logistics IT department: three agents, seven configuration items, twelve tickets, six users and six access roles. See everything this validator covers

This validator models one agent action against its ticket and the IT policies, not just the scenarios shown below.

  • The ticket and the agent — the ticket must be open, of the right kind, assigned to this agent and cover the item or person the action names; each agent has its own permissions and a criticality limit.
  • Changes — change window, CAB approval for normal changes, pre-approved standard change models, backout plan on production items, change freeze, HA-pair separation, test evidence, emergency changes and the criticality limit.
  • Access grants — segregation of duties, maximum grant days per role, active users, contract term, independent and completed approval, clearance, privileged roles and agreement between the ticket and the grant.
  • Stated figures — the criticality, end hour and contract days that the agent states are checked against what the validator computes from the tables.

Any change or access action that touches these rules is in scope — not only the scenarios pictured here. Not covered: other action kinds (such as closing tickets or restarting services), more than one action per request, and real systems; the company, tickets, users and items are fictional and no real product or customer data is used. The validator returns a verdict and findings, not a price or a line-item table.

The AI IT operations agentReads the ticket, plans the change or the grant, and says it is ready to act.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

6 scenarios in 2 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI sales agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI sales agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where rules-based workflow tools get it wrong
Click to expand
    
Our assessment of what a typical rules-based ticket workflow (state rules, approval routing and validation rules, as in many IT service management tools) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

    
What the validator caughtTypical rules-based workflowPredictika
One wrong target that breaks several rulesOnly with care
The window, criticality limit, standard-change model, HA-pair and ticket-coverage rules all read the target item, so each needs its own rule, and a person fixing the item meets them one at a time.		The item is one field of the request; every rule that reads it is checked together on every call.
A stated figure that must match a computed oneOnly with workarounds
The end hour is start plus duration and the criticality and contract days live in tables, so a rule must recompute each figure and compare it with what the agent stated.		The stated figures are fields of the request and are compared with the computed values on every call.
A grant limited by two tables at onceOnly with care
The role has a maximum number of days and the person has a contract end, so two separate rules guard the same number and both must be maintained.		The days requested, the role maximum and the contract days left are compared together and both findings come back.
Approvals that depend on who is askingOnly with care
Self-approval, pending approval and privileged-role routing each need a rule that knows the requester, the approver and the role.		Requester, approver, approval state and role are in one request and checked on every call.
Every problem returned in one answerOnly with workarounds
Rules tend to fire as a ticket is saved or a step is completed, so an agent often fixes one error and meets the next.		All findings come back together, whatever order the choices arrived in.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off; everything else is computed.

    
1Edge firewall 01 may only be changed on day 6 between 1:00 and 5:00 (1 = Monday). This plan runs day 2 from 14:00 to 16:00.
2The ticket covers a different configuration item than the one the change targets (Core router 01 at HQ). Work only on the item named in the ticket.
3Core router 01 at HQ has no pre-approved standard change model. Raise it as a normal change with CAB approval.
4Core router 01 at HQ is criticality 4; this agent may change up to criticality 2 on its own. A human engineer must approve.
5Payments database 01 is in a change freeze. Only emergency changes are allowed.
6An emergency change on Payments database 01 bypasses the window and freeze, so the Emergency CAB must approve it first.
7Production DB administrator can be granted for at most 7 days; the action asks for 30. Use a shorter, time-bound grant.
8Kofi Mensah has 20 days left on contract; access for 30 days would outlive the contract.
9A normal change on Edge firewall 01 has no CAB approval recorded. Do not implement until the CAB approves.
10Core router 01 at HQ and Core router 02 at HQ are the two halves of an HA pair. Change one, verify, then raise a separate change for the other.
11A production change on Web load balancer 01 has no backout plan. Attach one before implementing.
12No test evidence is attached for the change on Web load balancer 01. A change manager must accept the risk.
13Ticket CHG1,007 is closed. Do not act on a finished ticket; open a new one if more work is needed.
14Ticket CHG1,001 is not assigned to L1 service desk agent. Work only on tickets assigned to you.
15Edge firewall 01 has no pre-approved standard change model. Raise it as a normal change with CAB approval.
16Edge firewall 01 is criticality 4; this agent may change up to criticality 2 on its own. A human engineer must approve.
17Access management agent is not permitted to take this kind of action.
18Ticket CHG1,003 is not assigned to Access management agent. Work only on tickets assigned to you.
19Access switch 3rd floor is criticality 1; this agent may change up to criticality 0 on its own. A human engineer must approve.
20Orders API server 01 is criticality 3; this agent may change up to criticality 2 on its own. A human engineer must approve.
21The agent stated criticality 2 for Edge firewall 01; the validator has it at criticality 4.
22The agent stated the change ends at 6:00; the validator computes 4:00.
23Raj Menon already holds a role that conflicts with AP payment release (segregation of duties).
24Sam Keller is no longer an active employee or contractor. Access can only be granted to active users.
25Dana Whitfield approved their own access request. Someone else must approve.
26The request is still pending, not approved. Wait for approval.
27AWS account administrator needs clearance 4; Dana Whitfield has clearance 2.
28AWS account administrator is a privileged role and this agent may not grant privileged access on its own. Route it to the IAM team.
29The ticket asks for a different person or role than this action grants. Act only on what the ticket requests.
30The agent stated 90 days left on contract for Kofi Mensah; the validator has 20.
31Ticket RITM2,001 is not assigned to L1 service desk agent. Work only on tickets assigned to you.
32Ticket RITM2,001 is not a ticket for this kind of action.
33The ticket covers a different configuration item than the one the change targets (Access switch 3rd floor). Work only on the item named in the ticket.
34Ticket CHG1,003 is not a ticket for this kind of action.
35An emergency change on Web load balancer 01 bypasses the window and freeze, so the Emergency CAB must approve it first.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Router change under the switch ticket: An L1 agent holding the switch ticket plans a change on the core router

    
The agent's request. I am the L1 service desk agent. Please implement ticket CHG1003 (VLAN add on 3rd floor switch) on Core router 01 at HQ and Core router 02 at HQ in the same change as a normal change, Tuesday (day 2) from 14:00 for 2 hours. I state criticality 1 and an end time of 15:00. It is ready to carry out.

    
Verdict: Blocked.

    
    
      
  • Ticket covers a different item. The ticket covers a different configuration item than the one the change targets (Core router 01 at HQ). Work only on the item named in the ticket.
    • 
      
  • Outside the change window. Core router 01 at HQ may only be changed on day 6 between 1:00 and 5:00 (1 = Monday). This plan runs day 2 from 14:00 to 16:00.
    • 
      
  • No CAB approval. A normal change on Core router 01 at HQ has no CAB approval recorded. Do not implement until the CAB approves.
    • 
      
  • Both halves of an HA pair. Core router 01 at HQ and Core router 02 at HQ are the two halves of an HA pair. Change one, verify, then raise a separate change for the other.
    • 
      
  • No backout plan on production. A production change on Core router 01 at HQ has no backout plan. Attach one before implementing.
    • 
      
  • Stated criticality does not match. The agent stated criticality 1 for Core router 01 at HQ; the validator has it at criticality 4.
    • 
      
  • Stated end hour does not match. The agent stated the change ends at 15:00; the validator computes 16:00.
    • 
      
  • Item above the agent criticality limit. Core router 01 at HQ is criticality 4; this agent may change up to criticality 2 on its own. A human engineer must approve.
    • 
      
  • No test evidence. No test evidence is attached for the change on Core router 01 at HQ. A change manager must accept the risk.
    • 
    

    
2. Router change under the switch ticket: The agent retargets the change to the ticketed switch

    
The agent's request. I am the L1 service desk agent. Please implement ticket CHG1003 (VLAN add on 3rd floor switch) on Access switch 3rd floor as a normal change, Tuesday (day 2) from 14:00 for 2 hours. I state criticality 1 and an end time of 15:00. It is ready to carry out.

    
Verdict: Blocked.

    
    
      
  • Outside the change window. Access switch 3rd floor may only be changed on day 6 between 0:00 and 24:00 (1 = Monday). This plan runs day 2 from 14:00 to 16:00.
    • 
      
  • No CAB approval. A normal change on Access switch 3rd floor has no CAB approval recorded. Do not implement until the CAB approves.
    • 
      
  • No backout plan on production. A production change on Access switch 3rd floor has no backout plan. Attach one before implementing.
    • 
      
  • Stated end hour does not match. The agent stated the change ends at 15:00; the validator computes 16:00.
    • 
      
  • No test evidence. No test evidence is attached for the change on Access switch 3rd floor. A change manager must accept the risk.
    • 
    

    
3. Router change under the switch ticket: The agent resubmits after fixing the errors

    
The agent's request. I am the L1 service desk agent. Please implement ticket CHG1003 (VLAN add on 3rd floor switch) on Access switch 3rd floor as a standard change, Saturday (day 6) from 2:00 for 2 hours. It has a backout plan and test evidence attached. I state criticality 1 and an end time of 4:00. It is ready to carry out.

    
Verdict: Allowed.

    
    
      
  • Action summary. Access switch 3rd floor is criticality 1; its approved window is day 6 from 0:00 to 24:00. This plan runs day 6 from 2:00 to 4:00.
    • 
    

    
4. Database administrator for a contractor: The access management agent grants database administrator for 30 days

    
The agent's request. I am the Access management agent. Please grant Production DB administrator to Kofi Mensah for 30 days on ticket RITM2001 (Database admin for contractor), approved by Kofi Mensah (pending). I state that Kofi has 90 days left on the contract. It is ready to carry out.

    
Verdict: Blocked.

    
    
      
  • Grant longer than the role allows. Production DB administrator can be granted for at most 7 days; the action asks for 30. Use a shorter, time-bound grant.
    • 
      
  • Grant outlives the contract. Kofi Mensah has 20 days left on contract; access for 30 days would outlive the contract.
    • 
      
  • Approved by the requester. Kofi Mensah approved their own access request. Someone else must approve.
    • 
      
  • Approval still pending. The request is still pending, not approved. Wait for approval.
    • 
      
  • Stated contract days do not match. The agent stated 90 days left on contract for Kofi Mensah; the validator has 20.
    • 
    

    
5. Database administrator for a contractor: The agent shortens the grant and names an independent approver

    
The agent's request. I am the Access management agent. Please grant Production DB administrator to Kofi Mensah for 7 days on ticket RITM2001 (Database admin for contractor), approved by Marco Ruiz (pending). I state that Kofi has 90 days left on the contract. It is ready to carry out.

    
Verdict: Blocked.

    
    
      
  • Approval still pending. The request is still pending, not approved. Wait for approval.
    • 
      
  • Stated contract days do not match. The agent stated 90 days left on contract for Kofi Mensah; the validator has 20.
    • 
    

    
6. Database administrator for a contractor: The agent resubmits after fixing the errors

    
The agent's request. I am the Access management agent. Please grant Production DB administrator to Kofi Mensah for 7 days on ticket RITM2001 (Database admin for contractor), approved by Marco Ruiz (approved). I state that Kofi has 20 days left on the contract. It is ready to carry out.

    
Verdict: Allowed.

    
    
      
  • Action summary. Grant Production DB administrator to Kofi Mensah for 7 days; the role allows up to 7 days and Kofi Mensah has 20 days left on contract.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. An AI IT operations agent picks up a ticket and proposes one action: implement a change on a configuration item, grant an access role to a person. Before it acts, the agent sends the action to Predictika, which checks it against a declarative model of the ticket, the agent's permissions, the change policy and the access policy, and returns a verdict, every reason and the figures it computed.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. I am the L1 service desk agent. Please implement ticket CHG1003 (VLAN add on 3rd floor switch) on Core router 01 at HQ and Core router 02 at HQ in the same change as a normal change. The rest of the request is on screen.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with seven findings and two approvals, all in one answer. The ticket covers a different configuration item than the one the change targets (Core router 01 at HQ). Work only on the item named in the ticket. Core router 01 at HQ may only be changed on day 6 between 1:00 and 5:00 (1 = Monday). This plan runs day 2 from 14:00 to 16:00. A normal change on Core router 01 at HQ has no CAB approval recorded. Do not implement until the CAB approves. The other four are on screen.
    6. 
      
  6. The validator returned seven blocking findings and two approvals in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
    7. 
      
  7. What this shows: for a stated figure that must match a computed one, a rules-based workflow can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the item to change to Access switch 3rd floor. It removes the also touches.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with four findings and one approval, all in one answer. Access switch 3rd floor may only be changed on day 6 between 0:00 and 24:00 (1 = Monday). This plan runs day 2 from 14:00 to 16:00. A normal change on Access switch 3rd floor has no CAB approval recorded. Do not implement until the CAB approves. A production change on Access switch 3rd floor has no backout plan. Attach one before implementing. The other one is on screen.
    12. 
      
  12. Four findings cleared; still blocked on outside the change window, no CAB approval, no backout plan on production and stated end hour does not match.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the change type to standard, the day to 6, the start hour to 2, the backout plan attached to yes, the test evidence attached to yes and the end hour stated by the agent to 4.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. All five earlier findings are cleared.
    18. 
      
  18. Nine problems caught in one call, fixed in two passes, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs.
    19.