Kevin Coleman on why approvals are the hard part of enterprise agents

Kevin Coleman stopped by the WorkOS booth at the AI Engineer World's Fair 2026 in San Francisco to talk with Michael Grinich about automating employee support with agents. Coleman co-founded Ravenna, which helps companies build and deploy agents that handle the internal side of support: the ticket you file to get access to a piece of software, to update your payroll details, or to otherwise get unblocked at work. Most of the conversation ended up being about who gets to say yes.

Grinich named the problem plainly: approvals are the core of what's hard about building agents and agent workflows today. Coleman's answer is that approvals can't live at the workflow level, because the same workflow is harmless or catastrophic depending on which resource it touches.

Everyone has already met this problem locally

Grinich's way in was the coding agent everyone in the room had used:

you start running it in a folder and it's like, "Do you want to run this want to run this Git command?" And I'm like, "Yes, I want to do that." And it's like, "Do you want to run this little, you know, bash command?" And then after the third or fourth one you're like, "Oh, come on." And then you just run it in dangerously skip permissions mode.

On your own laptop, the downside of that is a bad afternoon. The same interaction pattern inside a company runs against systems where a single request can change payroll or someone's insurance. There is no enterprise equivalent of throwing permissions out the window, which means the prompt-per-action design has to be replaced with something an organization can actually reason about.

Where the approval actually belongs

Adding someone to a Google Group is one of the most common automations Ravenna customers ask for. It looks trivial until you look at which group.

not all Google Groups are created equal. Adding somebody to like the marketing at alias Google Group might be a a non-consequential thing to happen. If the wrong person gets out of there, it doesn't really matter. But if you add them to some security group that might provision them access to something else, that's something that's a a destructive action, right?

So the control surface has to sit a level below the automation:

it's not just like the workflow that needs approvals, it's actually the individual resources that the workflows or the agent is operating on where you got to get granular control to customers.

Coleman's list keeps going one level down. Workflow, then the resource it touches, then potentially the identity of the person asking to touch it. He's blunt that this is hard to build, and the reason it can't be waved away is that compliance, audit, SOC 2, and GDPR are practical problems in an enterprise setting rather than abstractions.

Determinism as a design choice

Ravenna's founding bet approaches the same concern from the other direction. Coleman's co-founder Taylor Halliday came from Zapier, where he built the AI engineering team. Zapier is a large deterministic workflow engine, and the team there spent countless hours trying to get early models to behave predictably. Reliability was the priority, so Ravenna invested heavily in deterministic workflows at the start of the company.

Then the models got good enough that the industry swung hard toward agentic workflows. Ravenna's platform now lets customers mix agentic automation where flexibility helps with deterministic workflows where something has to run the same way every time. The split is drawn by consequence. Routing a software access request to the right approver stays deterministic, since you don't want an agent fumbling around trying to figure out who that is. Creating a new Google Group or a new Slack channel is lower risk, so an agent handles it.

Google Groups show up on both sides of that line. Creating one is the agent's job; adding a person to a specific one may require a human. That's the resource-level argument in miniature. Policy attaches to the individual thing being acted on.

The service desk becomes a build team

Ravenna's primary buyer is the IT team, and underneath the product is a ticketing system, a service desk, if you want to call it that. Before automation, staffing that desk meant people taking tickets and doing the work by hand.

the role of somebody on an IT service desk or people operations service desk is by and large changing from you're working on the requests or the tickets to you are actually building agents and automations to do that work for you.

The repeat requests are the obvious first targets: the Okta request that arrives every week, the Google Group automation. What Coleman finds notable is who's doing the building. Ravenna works with people ops teams that would not have thought about automation two years ago. In the product you talk to the agent, tell it what you want it to build, and it builds the automation.

Ravenna runs the same pattern internally. A seller named Noah takes requirements from a customer and builds the automation with the agent ahead of the next demo. The event marketer built an agent to identify the right people to invite to prospect dinners instead of sending invites by spray and pray. Coleman's claim is that everyone at the company without a traditional technical background is building with AI today. There's no approved-tools list: Claude, Codex, and Gemini are all available, and non-technical staff are encouraged to pull in the engineers who work with agents all day.

That has a price tag, and he didn't dodge it:

we are spending far too much money on the models, but that's all right, you know? ... in this time of experimentation, like if you're not doing this, I feel like you're falling behind, and like I am I am very confident the cost is going to come down

He doesn't put a number on it. His position is that the opportunity cost of not letting people experiment is the larger one.

The integration bottleneck they deleted

Asked to stack-rank what's actually blocking the company, Coleman said that a quarter ago he'd have answered integrations without hesitating. Customers want their core business systems connected (IDP, HRIS, MDM), and the count of supported systems had become the limiting factor on onboarding speed, because every customer has a one-off they want to see before they'll sign.

So Ravenna built a coding agent to remove the ceiling:

say we didn't have an integration with WorkOS and a customer wanted an integration, they give us a link to your documentation, we go out and do deep research on your API, we build up a context document that the agent then use to build additional API calls, and we call them actions or tools in our system.

Coleman's read is that the set of systems Ravenna can integrate with is now effectively unlimited.

One thing the interview doesn't resolve: generated integrations inherit the approval problem from two sections ago. Every new action the coding agent writes is a fresh resource surface someone has to classify as safe or destructive before an agent can call it unattended. Grinich's payroll example is the sharp version of that — a generated write action against a payroll API that nobody flagged is exactly the case the whole approval model exists to catch. If the integration layer scales without bound and the policy layer stays hand-curated, the policy layer becomes the new queue. So that's what I'd ask any vendor pitching on-the-fly integrations: how much human classification does each generated action need before it can run without approval?

The constraint moved to sequencing

With integrations handled, the blocker isn't model capability. It's the volume of feature requests from existing customers and prospects, and sequencing that work without dropping the quality bar.

I am like totally against AI slop. Like if we're using AI, we're going to do it right and we're going to ship good quality software. We're not going to lower the bar just because we have AI.

Hiring reflects the same split. Coleman says Ravenna could not have built the breadth of platform it has at its current team size without AI. Some roles got more important rather than less, forward deployed engineering in particular, because the engagements are deep, Ravenna integrates with customers' core business systems, and getting customers to success quickly takes people on the ground. Customers prompt the agents themselves, which turns them into prompt engineers whether they signed up for it or not, and someone has to teach them how to do it well.

What to model before you automate

Grinich put the AI Engineer World's Fair crowd at around 7,000 people, a long way from last year's edition in the basement of a hotel. Coleman came to learn how other teams handle the unglamorous questions: MCP or CLIs, and how to get models to do what you want without blowing out the context window.

For anyone building agents against internal systems, the model isn't the risky part. The permission surface is, and it's finer-grained than your workflow diagram suggests. Ravenna's answer is to make the resource and the requester first-class approval settings rather than workflow footnotes. Enumerate your resources and classify them by blast radius before you write the first automation. That classification is the artifact you'll be maintaining for years.

This interview was recorded at the AI Engineer World's Fair 2026 in San Francisco.