AI Sustained. Case Study 003
Agentic AI · 30 Jun 2026
Agentic AI · Case Study

Meet Charles — my first virtual hire.

Not a chatbot. A semi-autonomous agent that runs my backlog, takes the notes and books the meetings — and the low-code bridge I used to get round the read-only wall.

The hire
Agent 001
"Charles" — after Charles Babbage
Core remit
Backlog
Jira: create, triage, status, groom
The wall
Read-only
Email & Teams connectors can't send
The bridge
Low-code
MD → OneNote → SharePoint → Power Automate

Every team has the work that matters and the work that just has to happen. For a business analyst, the second pile is enormous and oddly invisible: grooming a backlog, writing up meeting notes, chasing statuses, booking the next session. None of it is hard. All of it is relentless. And it's the first thing to slip when the real work lands — which, for me, was constantly.

So rather than wait for headcount, I built some. The idea isn't a clever chatbot bolted onto the side of the team; it's a semi-autonomous agent that takes a standing slice of the admin off everyone's plate — supervised, correctable, but doing the legwork. One agent now, more to follow. This is the story of the first one, and the genuinely annoying obstacle I hit halfway through.

Why "Charles" — and what he actually does.

I named him Charles, after Charles Babbage — widely credited as the father of the computer for his Analytical Engine. It's a small thing, but naming an agent matters more than it sounds: it turns an abstract "AI integration" into a colleague with a remit, which makes it far easier to reason about what he should and shouldn't be allowed to touch.

Charles is an administrative assistant, plainly. His job description started where you'd expect — drafting meeting notes and summaries, and scheduling meetings — and then grew the part I actually needed most: owning my Jira backlog, and helping with my team's.

The job nobody has time for: the backlog.

Backlog management is textbook BA admin, and I have tried, repeatedly, to stay on top of mine by hand. I keep slipping behind. Tickets go stale, statuses drift from reality, the grooming session becomes an archaeology dig. It is exactly the kind of bounded, rules-based, repetitive work an agent is good at — and exactly the kind of work I am bad at finding time for.

With a Jira connector, Charles does the unglamorous middle of the job: creating, updating and triaging. He drafts new issues from a note or a message, sets and changes status as work moves, tidies fields, flags what's gone quiet, and keeps my backlog — and a view of the team's — honest. I still decide priority and direction. He does the keeping-it-true.

What Charles does  · supervised, on instruction or schedule
Meeting notesDrafts summaries & actions from a transcript or rough notes, ready to circulate.
SchedulingProposes and books meetings against availability.
Backlog — createTurns a note or request into a structured Jira issue.
Backlog — maintainStatus changes, field tidy-ups, stale-ticket flags, grooming prep.
Team updatesWrites the update — then hands it to the bridge below to deliver.

Charles operates semi-autonomously: I set the remit and the guardrails, he does the legwork, I approve anything that leaves the building.

The wall: an agent that can read but can't send.

Here's where it got interesting. The natural next step was for Charles to deliver his updates — email the team, post in Teams. In my case I ran into a wall: the connectors I had available were read-only, so Charles could read mail and messages but couldn't create and send them. An assistant who can read your inbox but never reply is, generously, a very expensive notepad — so I needed a way round it.

Worth saying plainly: this was a hurdle in my own setup, not a verdict on the tools. Connector and MCP permissions vary by vendor, version and — crucially — how your own tenant and admin policy are configured, and they change often. Your stack may well let an agent send straight out of the box. Check your own configuration first; if you hit the same wall I did, the bridge below is how I got past it.

An agent that can read your inbox but never reply is just a very expensive notepad.

The bridge: Power Automate, OneNote & SharePoint.

The fix didn't need an engineer — which suits me, because I'm a business analyst who can vibe-code and wire up simple integrations, not build software. It needed Power Automate, Microsoft's low-code automation tool, and a file as the hand-off point.

The pattern is deliberately dull, which is why it works:

The delivery bridge  · no software engineering required
01 · GenerateCharles writes the update as a Markdown file — the thing he's allowed to do.
02 · DropThe file lands in OneNote, which syncs to SharePoint.
03 · ListenPower Automate watches that SharePoint location for new or changed files.
04 · DeliverThe flow formats the content and sends it to the team by email or Teams.

The agent only ever writes a file. The sanctioned, governed tool (Power Automate) does the sending — which keeps the "send" capability inside Microsoft's own permissions, not the agent's.

There's a neat side-benefit to routing it this way. The agent never holds the keys to your outbound comms; it just produces content. The send stays inside a tool your IT function already governs. That's a far easier conversation with security than "let the AI email people," and it gave me a clean, auditable trail of what went out and when.

If you want to build the same thing, this is squarely a job you can do with an assistant like Claude alongside you — drafting the agent's instructions, shaping the Markdown template, and talking you through the Power Automate flow step by step. No in-house software engineers needed.

Charles is agent 001 — the team to come.

Charles isn't the destination; he's the proof. One bounded, supervised agent, doing real admin, with a sensible bridge for the bits the connectors won't do. The moment that works, the question stops being "can an agent help?" and becomes "who do I hire next?"

That's the genuinely exciting part. A team of virtual agents to complement the team of humans — each with a narrow remit, each supervised, each taking a slice of the work that was quietly drowning us. Charles is 001. He won't be the last.

Tactical takeaway

Your first agent should be a bounded colleague, not a clever chatbot.

01 · START NARROW
Give one agent one repetitive remit — backlog admin, notes, scheduling. Name it. Supervise it. Bounded beats clever.
02 · MIND THE GAP
Assume some connectors are read-only. When an agent can't send, have it write a file and let a governed tool deliver it.
03 · KEEP THE KEYS
Route "send" through Power Automate, not the agent. Easier on security, auditable, and no engineers required.
Register your interest

Want to hire your own Charles?

Leave your email and I'll be in touch about how this was built, the read-only workaround, or where a first agent might take a slice of work off your team.

Tags
#AIAgents #AgenticAI #VirtualAgents #Jira #PowerAutomate #MCP #FutureOfWork #BusinessAnalysis
AI Sustained. · By Kevin Clubb · All case studies 2026