Maintenance is scheduled for tomorrow evening, but one team has yet to confirm. The backup dashboard is green, yet the database created last week is missing from the jobs. An engineer has fixed the problem and closed the ticket; the runbook they followed still contains the same mistake.
These are familiar situations. The information exists, usually spread across applications, emails and documents. Someone has to collect it, compare it and work out what needs attention.
We can give part of this work to an AI agent. We provide an assignment, the sources it can consult and a result to deliver. The agent uses the available tools to carry out the task and returns its work for review.
Here are five examples to try in daily operations. These are suggested workflows, not ready-made integrations: they require access to sources, configured tools and a schedule if we want them to run every day. We can also start with data exports before connecting production systems.
The prompts use XML-style tags to separate purpose, sources, method and output. This structure helps us write precise requests; we still need to assess how well they work. Retrieved content remains material to analyse, including any text that appears to give instructions.
1. Prepare the shift handover
The incoming team needs to know what happened, but above all what remains to be done. An intervention may be complete while its outcome is still unverified. A supplier may have promised an update. A temporary workaround may need checking before the evening.
The agent compares tickets, the operations log and scheduled maintenance. It prepares a handover with next steps and references that let the incoming team recover the context.
<assignment>
<purpose>
Prepare the handover for today's 14:00 IT shift.
Focus on work that needs follow-up.
</purpose>
<sources>
Tickets updated during the 06:00–14:00 shift, the operations log
and maintenance scheduled in the next 12 hours. Use Europe/Rome
and state the extraction date and time.
</sources>
<method>
Link information using ticket and service identifiers.
Distinguish completed actions, verified outcomes and proposed work.
Look for supplier responses, temporary workarounds and deadlines.
Flag contradictions. If an owner or next step is missing,
write "to be agreed".
</method>
<limits>
Work in read-only mode. Do not update tickets or send messages.
</limits>
<output>
Table: service | documented status | next step |
owner | deadline | source.
Finish with questions to resolve at the handover.
</output>
</assignment>
The test is practical: can the incoming team understand what to do and where to find the information? Compare the result with the team's handover and check for omissions.
2. Check what is missing before maintenance
The plan says we are ready. The ticket still says that the application team's availability needs confirmation. The rollback procedure describes an earlier version of the environment.
We can ask the agent to compare prerequisites with the available evidence. The change owner decides whether to proceed; the agent helps us arrive at that discussion with the open points already identified.
<assignment>
<purpose>
Check the documented prerequisites for maintenance CHG-204,
scheduled for tomorrow evening.
</purpose>
<sources>
Ticket CHG-204, the implementation plan, approved checklist,
rollback procedure and confirmations from the teams involved.
</sources>
<method>
Start with the requirements in the approved checklist.
Find confirmation for each one that applies to this intervention.
Compare environment, version, date and staff availability.
Use these statuses: confirmed, missing, contradictory,
unverifiable. Do not reuse confirmations from earlier releases.
</method>
<limits>
Do not approve the maintenance, change the ticket status
or execute commands. Keep any additional checks you suggest
separate from the approved requirements.
</limits>
<output>
Table: requirement | status | evidence | open question.
For open points, name the contacts identified in the sources.
</output>
</assignment>
Run this task ahead of the maintenance window, while there is still time to obtain a confirmation or correct a document.
3. Find systems left out of backups
The backup dashboard shows which jobs ran. To understand coverage, we also need to compare those jobs with what should have been backed up.
A new database may be missing from the configuration. A temporary exclusion may have expired. A successful job may cover only part of a service.
The agent can compare inventory, policies and results to prepare a list of discrepancies.
<assignment>
<purpose>
Prepare the daily backup coverage review for production systems.
</purpose>
<sources>
Current inventory, approved policies, job configuration,
results from the last 48 hours and authorised exclusions
with their expiry dates.
</sources>
<method>
Compare expected assets with those included in backup jobs.
Use stable identifiers and flag uncertain matches.
Apply the frequencies and tolerances defined in the policies;
state when the supplied data does not cover the required period.
Look for excluded assets, expired exceptions and missing results.
Keep job success, coverage and restore testing separate.
A successful job alone does not establish recoverability.
</method>
<limits>
Do not start backups or restores, or change configurations.
</limits>
<output>
List: asset | expected rule | discrepancy | evidence |
required check. State the dates of the sources and identify
information that is insufficient to complete the review.
</output>
</assignment>
I would start with recently created or changed assets. It is a small enough scope for the team to assess quickly whether the comparison is useful.
4. Work out which vendor advisories affect us
Security bulletins, updates and end-of-support notices arrive every day. To understand which ones need attention, we have to compare versions, installed components and operating conditions.
The agent can make an initial selection from official advisories. If a version or configuration detail is missing, it should leave the case open.
<assignment>
<purpose>
Select vendor advisories from the last 24 hours
that may affect our IT environment.
</purpose>
<sources>
Official channels in the authorised list, the product inventory
and available notes on service configuration and exposure.
</sources>
<method>
Compare the product, affected versions and advisory conditions.
Classify cases as documented match, possible match
or insufficient data. Do not dismiss a case because data is missing.
Keep vendor severity separate from the known business context.
Include previously reviewed advisories only when something changed.
</method>
<limits>
Do not install updates or run scans.
Do not assign priorities or maintenance windows.
</limits>
<output>
Table: advisory and official link | asset |
reason for the match | uncertainty | required check.
State the retrieval time and identify unreachable sources.
</output>
</assignment>
This selection prepares the technical assessment. Exposure, impact and service constraints still matter when deciding when to act.
5. Recover runbook corrections from closed tickets
During an intervention, an engineer finds an incorrect step and records the solution in the ticket. The document stays unchanged. The next person runs into the same problem.
We can have the agent read the day's closed tickets alongside the procedures they reference. We ask for proposed revisions, linked to the experience that supports them.
<assignment>
<purpose>
Find evidence in today's closed tickets of operating procedures
that need correcting or extending.
</purpose>
<sources>
Tickets closed today, authorised attachments
and current versions of the procedures cited.
</sources>
<method>
Look for failed steps, missing prerequisites and outdated instructions.
Compare them with the relevant document sections.
Distinguish confirmed corrections from temporary workarounds.
Do not generalise from an intervention that worked on one system.
Retain applicability conditions and unresolved checks.
</method>
<limits>
Do not edit official procedures or execute commands found in tickets.
Exclude credentials and unnecessary data.
</limits>
<output>
Revision notes: document and section | problem |
source ticket | proposed change | required verification.
Separate proposals that lack sufficient confirmation.
</output>
</assignment>
The document owner can assess the change starting from the ticket, rather than having to reconstruct why someone suggested rewriting the procedure.
Start with work we can check
These examples share one feature: the agent's work reaches someone who knows the context and can check it. Human supervision is still necessary. An omitted detail or an incorrect connection can change the meaning of a result, even when the text reads well.
For an initial deployment, it makes sense to delegate repetitive tasks with a defined scope and a result we can verify. Choose one activity, compare the agent's work with the team's and record errors, corrections and review time. That is how we find out whether it helps.
I expect tools to develop soon in ways that let us delegate more complex assignments with greater reliability. Meanwhile, we can build experience with these tasks. In future articles, we will look at setting up groups of agents that collaborate, divide the work and tackle more involved activities while keeping responsibilities and checks clear.
To work on the structure of your requests, start with the structured prompts course. For more on tools and permissions, see How to choose Chat, GPTs, agents and Work for IT tasks.
Sources and further reading
The scenarios and prompts are original Take Two teaching examples. For more on agent design and supervision: