More people can build useful apps and agents than a platform team can review one by one. Leaving each team to assemble ownership, access, and security controls on its own is risky and chaotic.

Vercel for Enterprise Apps and Agents gives builders a shared path to production with those controls already in place. Teams can move without making the platform team recreate the same safeguards for every project.

This course makes that path concrete through Vendor Review, an internal application that helps employees request new software. It collects a request, uses a model to identify missing information and suggest risk, and sends approval decisions to Procurement or Security. You will identify the point where its fixed workflow becomes an agent, then keep that agent inside explicit limits.

You will give Vendor Review an owner, define who and what it can access, make its AI-assisted decisions inspectable, and finish with an explicit rollout decision.

This is primarily an enterprise-application course. You will not build an open-ended autonomous agent. Instead, you will decide which tools the intake agent may use, when a person must approve, and how final approval stays with a verified person. The course distinguishes controls you implemented from controls you only inspected or planned. Understanding a control is not evidence that it has been implemented.

Before you begin

You need Node.js 24 or later, pnpm, a GitHub account, and a Vercel account. The starter's engines field requires Node 24. Local model calls, the eve agent framework, and live evaluations use an AI Gateway API key. AI Gateway centralizes model access, policy, usage, and spend. Deployments on Vercel use platform-issued, short-lived OIDC identity unless you deliberately configure a key. The runnable database lab also uses a Postgres provider from the Vercel Marketplace.

Some enterprise controls cannot be configured in every learner environment. Vercel Passport, the Enterprise default for putting internal applications and agents behind your identity provider, is available on Enterprise plans. Enterprise Managed Users is an Enterprise Private Beta for managing builder accounts through the company directory. The course clearly separates controls you configure from controls you inspect or plan.

What you will learn

By the end of the course, you will be able to:

Explain what changes when a prototype becomes a company application
Control who can build the application, who can use it, and what systems it can reach
Separate company policy from model judgment
Test, record, and observe AI-assisted decisions
Make human approval survive delays and record who approved
Build a small eve agent with one submission tool, stop conditions, and human approval
Decide when a workflow has actually become an agent
Demonstrate whether the application is ready for a broader rollout

The application

Every lesson uses the same request:

Employee submits a vendor request
  → company policy chooses required reviewers
  → AI identifies ambiguity and suggests risk
  → a durable workflow waits when review is required
  → an authorized person approves or rejects
  → the application records the evidence

Use this diagram as the course's canonical map of its three access boundaries:

builders and deployers → organizational ownership and protected delivery
employees              → application access policy
application            → scoped data, tools, models, and spend

A developer's ability to deploy should not grant every employee access to Vendor Review, and neither should grant the application standing access to company systems.

The final chapter-three exercise adds a conversational way to create the same request. An eve agent gathers missing fields and may submit a completed request only after the person approves the tool call. The agent can gather and submit a request, but it cannot approve one.

A platform team should not be the queue

This course is not about removing platform or security review. It is about moving their work to the places where judgment is actually needed. A governed path gives builders a reliable starting point for ordinary work, then sends exceptions for review: access to a new kind of data, a broader audience, an unusually costly model workload, or a decision that changes data, spend, or access.

When every deployment needs a fresh handoff, a platform team becomes the queue between an idea and its value. When baseline controls are inherited and exceptions are explicit, that team can become the finishing touch: setting the rules, reviewing higher-risk changes, and improving the path from evidence instead of manually shepherding every application.

The course repository keeps one application at the repository root:

main is the deliberately incomplete prototype and the course starter.
implementation-start is a tagged scaffold with the request UI and application plumbing needed for the implementation chapter. It contains unfinished model, policy, and workflow behavior.
complete is the finished answer key.

Create a course-work branch from main and keep it for the whole course. The starter includes docs/readiness.md, docs/model-record.md, and docs/operating-report.md. You will fill those files only when a decision affects the application. Most of the evidence comes from running the code, tests, and final request instead of producing a small library of Markdown.

Course map

From Prototype to a Production Path — deploy Vendor Review, define its job, and find the gaps that matter.
Create One Governed Path — control builder identity, employee access, and access to company systems.
Make AI Decisions Dependable — choose models deliberately, encode policy, test behavior, record approval decisions, and add one small eve agent.
Prove It Is Ready — run one request from intake through a recorded human decision, inspect the evidence, and decide whether to keep testing, roll it out more broadly, or retire it.

The main path is written for anyone who needs to understand how enterprise AI applications reach production. Implementation details are included for developers, but the architecture and decision exercises stand on their own.

Start by deploying the prototype and observing what it can prove today and what remains unknown.