PermitAI

Inspiration

AI agents are getting good enough to take real actions across workplace tools, but most teams still face the same problem: once an agent moves from “answering questions” to “sending emails, creating calendar events, and acting on behalf of users,” trust becomes the bottleneck.

We built PermitAI to solve that gap. Instead of treating workplace automation like a black box, we wanted a system where AI actions are permissioned, reviewable, and auditable from the start. The inspiration came from a simple question: how do you make AI agents useful in the workplace without giving them blind access to business tools?

What it does

PermitAI is a workplace control console for AI agents.

A user gives PermitAI a natural-language task, like coordinating an interview or sending an email. PermitAI turns that request into structured actions, evaluates each action against workspace policies, automatically executes low-risk work, routes high-risk work to approval, and records the full workflow in an audit trail.

In the current version, PermitAI supports governed Gmail and Google Calendar actions such as:

• reading availability
• drafting email
• creating events
• sending email The result is controlled autonomy instead of blind automation.

How we built it

We built PermitAI as a full-stack Next.js application with TypeScript.

For identity and connected access, we used Auth0. Users sign in through Auth0, connect Google Workspace through Auth0-connected access, and then PermitAI uses that delegated access for governed Gmail and Calendar actions.

For planning, we used Gemini 2.5 Flash through the Google GenAI SDK. The model converts natural-language requests into structured action plans that fit the actions PermitAI can actually govern and execute.

For policy and workflow control, we built a server-side pipeline that:

• parses the request context
• generates a structured action plan
• evaluates each action against policy and risk
• routes risky actions to approval
• executes approved actions in Gmail and Calendar
• stores the workflow in PostgreSQL through Prisma
• We used Supabase Postgres for persistence and Vercel for deployment.

Challenges we ran into

• making Gmail and Calendar execution work through Auth0-connected access and Token Vault-related flows
• handling the difference between low-risk automatic execution and high-risk approval-gated execution
• avoiding misleading behavior when a task was vague or missing key details

Accomplishments that we're proud of

We’re proud that PermitAI is not just a UI concept. It actually performs governed actions in real tools.

Some highlights we’re especially proud of:

• turning natural-language tasks into structured governed workflows
• connecting Gmail and Calendar through Auth0-backed delegated access
• making approval a first-class part of the product instead of a bolt-on
• executing real Gmail and Calendar actions after review
• building an audit trail that makes the workflow explainable
• shaping the product around control, trust, and policy rather than generic AI assistant behavior

What we learned

We learned that the hardest part of agentic systems is not the model output itself. It’s the control surface around the model.

What's next for PermitAI

Next, we want to expand PermitAI from a Gmail and Calendar governance layer into a broader workplace control plane.

Bonus Blog Post

When we started building PermitAI, we thought the hardest part would be planning actions from natural language. In reality, the harder problem was much more important: how do you let an AI agent take real actions in workplace tools without turning it into an over-permissioned black box?

That is where Auth0 Token Vault shaped the project.

PermitAI is a workplace control console for AI agents. A user gives a natural-language task, PermitAI turns that into structured actions, evaluates each action against policy, sends risky actions to approval, and then executes approved work in Gmail and Google Calendar. The key challenge was not just connecting those tools. The challenge was connecting them in a way that still respected identity, approval, and governance.

Using Auth0 gave us a clean separation between human identity and agent execution. Users sign in with Auth0, and the system knows exactly who requested an action, who approved it, and which connected account the agent is allowed to use. That made the audit trail much more meaningful. Instead of logging anonymous tool usage, we could tie actions back to authenticated actors and policy decisions.

The most valuable lesson from working through Token Vault-related flows was that delegated access is only useful if the surrounding system is explicit about control. During development, we ran into all the real issues you would expect in production: connected account setup, refresh-token exchange failures, handling missing integrations, and making sure the app did not fail silently. Those problems were frustrating at times, but they forced us to design PermitAI more honestly. We stopped treating integrations like a magic “connected” button and started treating them as governed resources with failure states, approval gates, and visible audit evidence.

One thing that became very clear is that Token Vault is not just an implementation detail. It changes how you think about product design. Once an agent can act through delegated access, every decision around policy, approval, and messaging matters more. We had to think carefully about what should auto-execute, what should pause for approval, and what should fail with a clear message. That led directly to the core PermitAI workflow: low-risk actions proceed, high-risk actions require review, and every important event is logged.

We had to think carefully about what should auto-execute, what should pause for approval, and what should fail with a clear message. That led directly to the core PermitAI workflow: low-risk actions proceed, high-risk actions require review, and every important event is logged.

Built With

• nextjs
• prisma
• supabase