Agentic AppStore

TL;DR

Employees at large companies request access to work tools (Salesforce, GitHub, AWS) through a form, and most don't know which app or which permission level they actually need. They end up giving bad guesses that result in delays, back and forth with IT, and being blocked for hours or days waiting on a second attempt.

We've redesigned that request system, replacing the form with a conversation - you describe what you're trying to do, and it works out the right app as well as the narrowest permission you need.

Context & Constraints

Our company wide thesis is that governance must feel agentic, not manual. Since the AppStore is the highest-volume surface in the product, it needs to be the first proof point. We had a target of ≥60% of access requests initiated through agent-assisted or fully agentic flows.

Before the redesign, the onus is put on the employee to translate intent into specific permissions, which leads to over-requesting, under-explaining, and a lot of back and forth with the admin. We saw this as both a strong opportunity for agent to transform the overall experience and the best training ground for our AI Identity Brain, where every conversation becomes a data point about who needs what, and why.

Who it's for

• Primary: the employee requesting access. Someone who knows their task and doesn't know (and shouldn't have to know) the entitlement taxonomy.
• Secondary: approvers and managers. They inherit the cost of a bad request. Better inputs mean fewer discussions and more consistent decisions.

Constraints

• Speed of execution: this had to be a highly iterative process.
• Partner with highly motivated customers to refine the agent before GA. It needs real data to get better.

Key bets

01Conversation produces better context than a form

There's real advantage in an agent-assisted experience here, it's not just following the trend of turning everything into a chatbot.

We have a high conviction that a dialogue that asks the right questions extracts intent a form structurally cannot. A form has to ask everyone everything everytime, whereas a conversation only asks what's actually missing. Overtime, less questions are needed as we learn each organization's request pattern more deeply.

02Hybrid, not pure LLM

We deliberately chose the LLM for ambiguous intent and deterministic tooling for everything that has to be right. This includes catalog lookup, eligibility, validation, and submission.

The LLM never invents an entitlement, instead it selects from a knowledge database that we built internally. After choosing, the UI renders from a tool call. Pure LLM fails on hallucination (which is detrimental to earning any trust even for beta users!), so a validation layer needs to check any suggested apps/entitlements against the customer's active catalog before the user ever sees it.

03Web first, then meet people where they work

We debated about which path to build first - web or slack/teams? We went with web in the end as it inherits the existing auth and catalog, and most importantly, it generates roughly 4 times the eval samples per day compared to Slack. This matters in this case because the product only improves as fast as it learns :) However, we also acknowledged that people don't always want to open a web app to ask for something. So Slack/Teams, MCP and API followed once the core hypothesis was validated.

Edge cases

We also thought about how to handle degradation gracefully.

• LLM unavailable → point at the standard form.
• Catalog metadata incomplete → disclose what's known and offer the manual path - the agent never silently produces a worse answer.
• Out-of-scope request → acknowledge it, explain it's not supported yet and offer either the best available alternative or prompt the user to submit a request for a new app.

What's next

There's so much we can unlock! Support for access packages, requesting on behalf of groups of people, and giving recommendations to approvers are just a few examples. Ultimately, the vision is the agent improves the efficiency by helping with both ends of the request, not just the asking end.

Impact

Roughly 5,300 conversations since rollout on June 22, growing beyond the design-partner cohort organically; large enterprises started using it unprompted.

Quantitative

Qualitative

• Large enterprise customers are retiring Okta access requests and using Lumos as the only front door.
• Users are adding more apps to be managed through the AppStore.
• It's carried POCs to a close.
• Internally, it became the benchmark for what good AI feels like.