Bring-your-own-agent policies are less about approving tools than about deciding who is allowed to automate what, under whose oversight, and with what evidence of control. For CIOs and IT leaders, the management challenge is not whether staff will experiment; they already are. The real question is how to turn informal use into a governed capability without freezing innovation. That means clear decision rights for acceptable use, data handling, logging, review and escalation, plus a named owner for exceptions when an agent causes error or exposure.
The biggest trade-off is speed versus standardisation. Early pilots in high-value, lower-risk functions can surface practical failure modes faster than a long platform build, but they also create inconsistency if every team invents its own stack. Leaders should treat pilot selection as a portfolio decision: choose cases with visible productivity gains, manageable data sensitivity and a clear path to reuse. The next question is not just โdoes it work?โ but โwhat minimum guardrails must be common across all teams before scaling?โ
This also changes the operating model for senior technical staff. Experienced architects, security and engineering leaders may contribute less as individual builders and more as reviewers, harness designers and control owners. That shift can reduce bottlenecks, but only if the organisation formalises training, usage tiers and assurance checks. A useful management test is whether the policy makes safe experimentation repeatable: can a team onboard a new agent, prove it respects boundaries, and retire it without creating technical debt or compliance blind spots?
AI offers limitless opportunities for people to become more efficient, in-depth and productiveโand your companyโs employees are experimenting with that, both on their own at work and at home when theyโre off the clock. If employees create their own agents that work well for them, it makes sense to allow them to use them for work tasks to be more productive and empoweredโbut you need a policy to govern that.
Prezi CEO Jim Szafranski has experience with this kind of technology shift. Years ago, he was a part of the team at now-IBM company MaaS360 that pioneered and scaled technology and policies that let employees use personal devices to access work systems. Now, heโs created and encouraged a bring-your-own-agent policy at Prezi. We talked about it and how to make something similar work at other companies. This conversation has been edited for length, clarity and continuity.
What do you need to do to make a bring-your-own-agent policy work in an enterprise?
Szafranski: Each organizationโs different, and thereโll be different levels of freedom and responsibility and things like that youโll need to work through. But the playbookโs pretty similar.
First, get early wins. Early wins help a lot because when you understand the benefits, you can start understanding the risk youโre going to take.
Then pilots. Thatโs how we did it at Prezi. Our early pilots deleted a whole bunch of our Confluence archives, but you can restore those. (laughs) Someone had to go back and restore them and then we were like, โOK, great. We just learned something.โ
On the rollout, it should be organized. You should train this like a skill. The teammates that want to be empowered like this should earn it a little bit, like, โI did my AI cohort training. I built my sample app that shows me how I could mess up, and now I know how to do it.โ An organized, sort of cohorted, rollout, like we did with our iPhones and Android devices.
You do have to go through that hard work, but those paths have been paved. AI technology is powerful, so it can be a little scary. Will there be one new tweak in there for every organization? Probably, but not a rethinking.
Thereโs always a set of people you can trust, and theyโre already doing it anyway.
How do you do this in a safe way, making sure that agents donโt exploit vulnerabilities or create liabilities?
The more you empower the team to use this technology and bring their own versions [of] skills, you can be in more places at one time.
We recently built a new product: our Prezi agent for customers. The way we built that was extremely different than in the past. We had a small team, [but] no specific roles. Everyone had skills. We had people with good project management skills, good design skills, engineers. But ultimately, every single person checked in code that got released to the customersโ most of them for the first time.
That could go really wrong. What we did to make sure it didnโt is the senior engineers, the really experienced folks, werenโt there to ship customer-facing code. They were there to make sure there was a harness so that everyone else could ship in a secure way. That the right vulnerabilities were understood and shut down, and things like that.
The roles are blurring: engineers can design, designers can engineer, finance people can market. The key is to make sure you embrace the blurring lines and creativity of it, but also make sure youโre setting people up for success in the sense that you catch their mistakes, as opposed to tell them not to make them. Thatโs where the experience comes in and you can build those harnesses.
Itโs been fascinating. In the past, our most senior folks shipped the most complicated user functionality, and nowadays the user functionality is flowing from all over the business, and our most senior folks are just making sure it all fits together safely.
What advice would you give a CIO who wants to start this kind of policy in their company and doesnโt know how to start to be successful?
- Based on ourselves, by the time Iโm thinking, โWeโve got to do this,โ the reality is plenty of people are already doing it. Theyโre just not telling you because they donโt want to get into trouble.
- Take inventory in a good way, not in a โpoliceโ way. Find the wins and get them into your town hall as fast as possible. Make sure people see there are wins, and our CIO is supporting it. You can be rational and say, โWeโre not ready for everyone to be doing this, but this is where weโre going to get to.โ
- Set up the pilots right away. Thereโs great places to start. Quality assurance is a great place where you never have enough, and itโs always so valuable. Customer service is another great place to start.
- Get the pilots going even before you have all the harnesses figured out. The technology is so easy to stitch together. I wouldnโt build your platform for how youโre going to do it first. I would tell the team, โYou guys figure out how.โ That way, youโll start understanding how to do data analysis in this area [and other] things.
- Make the stack people are using for their agentic workflows part of the pilot, as opposed figure all that out over the next two years and then let people use it.
Original Postutting-together-an-enterprise-bring-your-own-agent-policy/
Related