You don’t need an engineering title to build AI agents at work. You need to understand the problem better than anyone else, build the first version yourself in the tools your company already uses, and hand IT a clear spec for the parts that need their approval. Once the foundation is approved, it comes back to you. Then every person on the team can shape their own version around how they actually work.
That’s the short answer. Here’s the real one.
I didn’t start as the “tech person”
I walked into a traditional industry with no background in it and no engineering degree. What I did have was a front-row seat to how work actually moved: the emails nobody had time to read, the trip reports that came back in five different formats, the important thread that went quiet for three weeks until a customer noticed.
That turned out to be the most valuable thing I could bring to AI. Engineers can build almost anything. But somebody has to know what to build, for whom, and what happens when it’s wrong. That’s not a technical skill. It’s an operator’s skill.
Step one: build the foundation yourself
I don’t start with a big proposal. I start with a working first version, built inside tools the company already pays for: Copilot Studio, SharePoint, Teams, Power Automate.
The foundation is the part everyone will share:
Where the knowledge lives: a library or folder the agent reads from, organized so it stays useful as it grows.
What the agent does: written instructions, tested against real examples rather than ideal ones.
What it’s never allowed to do: one of my agents is read-only by design. If someone wants to correct its knowledge, it tells them to send the update to a person who owns it. That one rule prevents a lot of quiet damage.
Building it myself matters for two reasons. It proves the idea works before anyone spends real money on it. And it means that when I go to IT, I’m not bringing a wish. I’m bringing something they can look at.
Step two: know what goes to IT, and send a spec, not an idea
Some things you shouldn’t build alone: access to shared mailboxes, connections to core company systems, anything that touches security or runs at scale. That’s IT’s call, and it should be.
The fastest way to get a yes is to make their job easy. Here’s what I send:
The reasoning: the problem, who it affects, and what it costs today in hours, missed follow-ups or slow decisions.
A data map: what the agent needs to read, what access that requires, and just as important, what it should not read.
Cost options: ways to keep usage and token costs down, because IT is thinking about the bill even if you aren’t.
Defined outputs: exactly what gets delivered, to whom, and when.
Tested agent instructions: written and ready to paste, not “something like…”
A phased scope: small pieces that can be approved one at a time, instead of one giant ask.
The part people skip is the risk line. Every department tolerates mistakes differently. In sales, a draft that gets corrected is fine, because nothing goes out without a person checking it. In operations, a wrong answer can mean a misrouted container or a missed contract. So before IT asks, I’ve already decided what the agent does on its own, what it only suggests, and where a person signs off.
Step three: the foundation comes back, and that’s where it gets creative
This is the part I love, and the part most AI rollouts miss.
Once the foundation is approved, it doesn’t stay one-size-fits-all. It comes back to the team, and each person builds their own layer on top of it, shaped around how they actually work and what their role really is. No new approval is needed, because the risky parts are already settled.
Same foundation, very different tools:
One colleague runs expansion into new regions, so his daily recap sorts threads by new markets, existing markets and suppliers. It flags anything that’s gone quiet for five business days, with two drafted replies for each.
Someone in operations needs the opposite: everything sorted by urgency, and a shared view so handoffs still work when someone’s out sick.
For field visits, the team first wanted to grade reps A, B or C. We changed it to surface missed opportunities instead. Same data, completely different feeling, and that’s what got people to actually use it.
That’s the difference between an AI tool people are told to use and one they want to use. The foundation gives you consistency, security and scale. The personal layer gives you adoption.
Build for one team, design for the whole company
I always build for one department’s real needs first. But I design the foundation with room to flex, so another team, office or region can adjust it instead of rebuilding it from scratch. Every office works a little differently. The foundation is where the value comes from; the personal layer is what makes it fit.
The real takeaway
If you’re waiting for permission, a title or a technical background before you start building with AI, don’t. Start with the problem you understand better than anyone. Build the first version. Know exactly what needs IT, and make it easy for them to say yes. Then hand it back to the people doing the work, and let them make it their own.
The technology is the easy part. Knowing what to build, and for whom, is the job.
