Teaching It to Be Useful — From Chatbot to Coworker
This is Part 2 of a three-part series on running an AI agent like an actual IT coworker. If you missed the setup story, start with Part 1.
The morning it got real
The first morning after moving everything into WSL, i opened my laptop expecting the usual inbox grind.
Instead, i had a summary waiting:
- what mattered
- what could wait
- what already had draft responses ready
That was the moment this stopped feeling like a cool demo and started feeling like leverage.
What we actually wired up
Between Part 1 and that first useful morning, we spent most of the time on integration plumbing. Not flashy. Extremely important.
Microsoft Graph came first for Outlook, calendar, and Teams context. That meant app registration, permission scopes, token handling, and stable refresh logic.
ServiceDesk Plus came next for ticket operations. If you’ve worked with enterprise APIs, you already know this pattern: good enough docs, edge-case responses, and a lot of testing.
Once those were connected, the agent had what it needed:
- Email context (what changed)
- Calendar context (what’s about to happen)
- Ticket context (what’s at risk)
- Persistent memory (what matters over time)
That combination is where the value shows up.
Heartbeat design: useful without being noisy
I set periodic heartbeats during work hours so the agent could check state and decide whether to interrupt me.
Each cycle looked at:
- new inbox activity
- upcoming calendar windows
- ServiceDesk escalations or aging risk
- open follow-ups from prior conversations
If nothing needed attention, no ping. If something crossed urgency thresholds, i got a clean Signal update.
That one design decision mattered a lot. Good automation should reduce cognitive load, not become a new notification problem.
The 5 AM briefing workflow
I’m usually in work mode early, so we added a daily pre-work briefing.
The report includes:
- overnight inbox triage
- today’s meeting map with priority context
- ticket risk snapshot (aging, overdue, blocked)
- project reminders tied to active work
Could i gather all of that manually? Sure.
Do i want to every morning before coffee? No.
This consistently buys back focus at the exact time i need it most.
Automation sprint: from assistant to system
One Sunday session turned into a full ops sprint. In a few hours we put real workflows in place:
- meeting prep packets before key calls
- ticket aging flags with context
- vendor follow-up reminders when replies stall
- inbox noise sweeps on a schedule
- end-of-day status capture for cleaner handoff
Nothing here is individually revolutionary.
Together, it changed my operating tempo.
What changed for me day-to-day
The biggest gain wasn’t “faster replies.” It was better decision quality.
When context is pre-assembled, you spend less time hunting and more time deciding.
By week two, i wasn’t babysitting outputs. I was reviewing edge cases and improving rules. That’s a very different relationship than prompt-in / answer-out tooling.
Cost vs value (actual math, not vibes)
Yes, there’s real API spend when you run this heavily.
But if the system reliably returns even 1–2 hours per day of focused time, the ROI is obvious for leadership roles in operations-heavy environments.
The bigger value is consistency: fewer misses, faster escalation response, and better prep quality in high-context meetings.
The trust curve is operational, not emotional
Trust didn’t come from personality. It came from repeated, correct behavior under normal load.
That’s the same standard i use for any production system:
- does it fail safely?
- does it alert clearly?
- does it improve outcomes over time?
Once the answer stayed “yes,” this became part of core workflow.
Part 1 was infrastructure. Part 2 is operationalization.
Part 3 gets even more meta: using the agent to help produce and refine the very content you’re reading, plus where i think this goes next in real enterprise IT.
