Ryan Johnson (@RyanWorkforceAI) header
Ryan Johnson (@RyanWorkforceAI) profile picture

Making AI agents less intimidating and more useful at work. Practical notes for L&D, HR, workforce learning, and enterprise teams. Building

Joined June 2026
Some of the best testing of your AI rules happens outside the security team. It happens when an employee rephrases a request and the agent does something it was supposed to refuse. Fixed guardrails don't hold up against prompts that keep changing. A NIST result this year says no finite set of guardrails is universally robust against adversarial prompts. So your controls need a steady feed of fresh failures, and your people are already running into them. Make it easy for them to tell you: • a one-line way to report "the agent did something it shouldn't have" • no blame for the person who found the gap, even if they were poking at it • the exact wording that got through, saved with the date • one named owner who reads those reports every week • a reply to the reporter saying what changed, so they keep reporting • a monthly count of reports, where a sudden drop to zero is a warning sign The question is not whether your guardrails are good enough. It is whether the people who watch them fail have somewhere to say so. This week: ask three heavy users of your internal AI tools one question. "Have you ever gotten it to do something you thought it shouldn't?" Write down every yes. That list is your next round of fixes.
1
38
If an AI agent can finish your compliance course for an employee, look at the course before you look at the employee. Static slide decks with a multiple-choice quiz at the end are exactly the kind of training agents breeze through, and if people would rather hand it to a bot, that tells you something about the content. Before you go hunting for who used an agent, look at what the course actually asks people to do: • a quiz that asks what slide 6 said, when the job needs a decision • no scenario where the right answer depends on the situation • nothing that needs a live person (role-play, a manager watching, a peer pushing back) • one check on the day they finish, and none weeks later • no tie between the module and anything the team already measures • content nobody has updated since it went live Banning agents won't fix this. They'll just keep clicking, and the completion report will keep looking great. A course an agent can finish proves the course can be finished. A course where someone has to make a call in front of another person shows whether they learned it. This week: open your most-assigned compliance module. Rewrite the last quiz question as a short scenario from your own workplace, where the answer depends on what's going on. If an agent could still answer it from the slides alone, rewrite it again.
1
36
Your org chart lists every person on the team. It doesn't list the agents that may now draft offer replies, route HR cases, and start approvals. That gap is real. Most enterprise HR systems weren't built to store, manage, or audit work done by non-human workers. So the agents end up living in IT tickets, vendor dashboards, and one engineer's head. Before the next audit or reorg asks "who did this?", start a plain roster: • every agent touching a people process, with a one-line job description • the human who owns it (a name, not a team alias) • which systems it can read and which it can change • where it hands off to a person, and where it doesn't • the date someone last checked it still does what the roster says • what happens to it when its owner changes roles You don't need a new platform for this. A shared spreadsheet with an owner column beats a clean HR system that can't see the agents at all. The question is not "are our agents working?" It is "could we show, from our own records, what an agent did to an employee's file last month?" Monday: pick one people process (onboarding, scheduling, case intake). List every agent that touches it. If one has no named owner, that's your first fix.
2
30
Your AI rules got locked last quarter. Filters on. Blocked-prompt list filed. Then someone rewrites the ask on Tuesday, and the fixed list does not move. A one-time guardrail set will not hold against prompts that adapt. Treat the controls like work you keep doing: • log which prompts get refused, and which ones get through after a rewrite • re-test the same high-risk asks every week with fresh wording • give one person ownership of updating the block list when a new bypass shows up • separate "policy published" from "policy still works" • keep a short path for a human to escalate when the agent does something the rule missed • do not assume last month's safe setup is still safe this month The question is not whether you have guardrails. It is whether anyone is watching them fail and updating them when they do. Monday: pick one high-risk agent workflow. Ask someone outside the build team to try three fresh prompt variants that should be blocked. If any get through, fix the control before you ship the next feature.
2
36
Your LMS just closed another clean completion week. The green bars look fine. The catch is that some of those modules may have been finished by an agent in the employee's browser, not by the person who needs the skill. When agents can click through training for people, completion stops meaning learning. Watch for: • modules finished in minutes that used to take an hour • perfect quiz scores with no wrong answers in the history • the same session pattern finishing courses for many people • managers who only ask "is it done" and never ask "can they do it" • compliance dashboards that treat a green bar as proof of readiness • no spot-check where someone has to show the skill on a live task The question is not whether completion rates look healthy. It is whether the person who got credit can still do the job without the agent. Friday: pick one high-stakes module. Pull five recent completions. Ask each person to show you one step from that course on a real task. If they stall, fix the metric before you celebrate the dashboard.
2
32
Most teams still install AI agents the way they install software. License, deploy, hope the defaults hold. That works for a plugin. It fails for something that acts under your name. Before the next agent goes live, give it the same setup a new hire gets: • a named role with a clear scope of work • its own credentials, not a shared service account • a human manager who owns what it can and cannot do • written guidelines for when it must stop and escalate • a review date on the calendar, not "we'll check later" • an offboarding path that kills access the day the job ends The question is not whether the agent can finish the task. It is whether anyone can say who owns it, what it is allowed to touch, and who shuts it down. Tuesday check: pick one agent already in production. Write its role, owner, credentials, and kill path on one page. If any line is blank, fill it before you add another agent.
1
3
34
A long-running AI agent is not a chat window that stayed open. It is a job that keeps going after you leave the room. Once an agent runs for hours or days, chatbot habits stop being enough. Treat it like a distributed system: • a named owner for the agent's identity and credentials • unique credentials with the least privilege the job needs • context that survives across handoffs, not a fresh prompt each time • a shared registry so agents do not quietly duplicate each other's work • a kill path and rollback that work while the run is still going • logs of what it used and changed, not only what it returned The question is not how many agents you can launch. It is whether your org can keep identity, context, and ownership straight once those agents stop being short chats. Monday check: pick one agent that has run longer than a single session. Name its owner, its credentials, and the context it still carries. If any of those three is fuzzy, fix that before you add another long-running job.
1
1
1
4
154
Your AI agent may already reach regulated data nobody meant it to see. In the Kiteworks 2026 survey of security and risk leaders, 63% of organizations said they cannot enforce purpose limits on what their agents are authorized to do. A policy memo is not a control. Before the next agent goes live, lock these in: • credentials that cover only the systems the job needs • no path into regulated stores it was never cleared for • a named human who owns the access list • a review whenever the job, owner, or workflow changes • a written kill path someone can use without a ticket marathon • a log of what it touched, not only what it returned The question is not whether the agent has enough access to finish the task. It is whether anyone can prove what it is barred from, and who stops it when that bar fails. Monday check: pick one production agent and list the systems it can reach. If the list is longer than its job, shrink it before you add another agent.
2
76