Agent Experience: Build without leaving your terminal

Coding agents are becoming part of the development workflow.

But most infrastructure tools still assume a human in the loop. You write code with your agent, then switch to a dashboard to configure redirect URIs, create webhook endpoints, or debug environment issues. The agent can suggest changes, but you’re the one clicking through the UI to apply them. The loop breaks.

Agent Experience makes WorkOS operable by agents, not just readable by them.

It brings together the CLI, WorkOS Skills, declarative environment setup, configuration commands, diagnostics, resource access, and a new environment model so your coding agent can act as a true WorkOS expert, applying changes and verifying state directly from the terminal without constant human intervention.

If you’re building with agents, WorkOS should feel native to that workflow. Now it does.

Six upgrades that change the feedback loop

This launch includes improvements designed to make your coding agent dramatically more capable when working with WorkOS.

1. WorkOS Skills

Installing the WorkOS CLI now installs a curated set of WorkOS Skills that make your coding agent much more effective when working with WorkOS.

In practice, this means that with these Skills your agent can:

• Choose the correct SDK approach for your stack.
• Use the right configuration primitives for AuthKit, SSO, Directory Sync, Audit Logs, and more.
• Map “what you want” to “what WorkOS needs” without you pasting docs or correcting terminology.

Instead of prompting an LLM with a long preamble (“We use WorkOS. Here’s the SDK. Here’s our redirect URI format…”), the agent starts with a stronger baseline understanding of WorkOS APIs, concepts, and integration steps.

No manual prompt engineering. No copy-pasting docs into context. Your agent understands how to integrate AuthKit, configure SSO, manage roles, and work with webhooks out of the box. And it works across the LLM of your choice.

2. Try AuthKit without creating a WorkOS account

You can now integrate AuthKit without creating a WorkOS account first.

When you run the CLI to add AuthKit to a project, WorkOS creates an unclaimed environment that your agent can use immediately. That means you can scaffold and test an authentication flow inside your app without signing up or logging in.

For example, you can run the CLI inside a Next.js project and have your agent integrate AuthKit end-to-end from the terminal.

Once you’ve tried the integration and are ready to move forward, you can claim the environment and convert it into a normal WorkOS project.

This removes one of the biggest setup interruptions when working with agents: having to stop development to create accounts, projects, and configurations before the code can run.

At the moment, this is supported for Next.js, with more frameworks coming up in the future.

3. workos doctor

workos doctor is a new command that inspects your project and flags common misconfigurations.

It’s designed for the reality of auth integrations: most issues aren’t dramatic failures, they’re small mismatches.

Examples of what workos doctor can help catch:

• AuthKit configured, but redirect URIs don’t match what the app is using.
• Environment variables present, but inconsistent with the intended setup.

workos doctor analyzes your application and surfaces recommendations, not just errors. It’s useful when something is broken, and equally useful before you ship.

Crucially, this is machine-usable. Your agent can run diagnostics, interpret the output, and suggest or apply fixes.

4. Configuration without the dashboard

Many integration steps previously required clicking through the WorkOS dashboard.

Now, the CLI can:

• Set redirect URIs.
• Create and manage webhook endpoints.
• And more, as configuration expands.

So now, instead of:

1. Ask the agent what to do.
2. Copy values.
3. Click around a UI.
4. Paste them in.
5. Return to the terminal.

You can keep it inside the same loop and let the agent apply changes via CLI commands.

Less tab switching. Fewer manual steps. Faster iteration.

5. Declarative environment setup with workos seed

You can now define your WorkOS environment as code.

With workos seed, you describe resources like organizations, roles, permissions, redirect URIs, and CORS origins in a YAML file, and apply them in a single command.

Start by generating a template:

  
workos seed --init
  

This creates a workos-seed.yml file in your project with a starting configuration you can edit:

  
# workos-seed.yml
# Resources are created in dependency order: permissions → roles → organizations → config.

permissions:
  - name: Read Posts
    slug: posts:read
  - name: Write Posts
    slug: posts:write
    description: Create and edit posts

roles:
  - name: Admin
    slug: admin
    description: Full access
    permissions:
      - posts:read
      - posts:write
  - name: Viewer
    slug: viewer
    permissions:
      - posts:read

organizations:
  - name: Acme Corp
    domains:
      - acme.com

config:
  redirect_uris:
    - http://localhost:3000/auth/callback
  cors_origins:
    - http://localhost:3000
  homepage_url: http://localhost:3000
  

Apply it:

  
workos seed --file=workos-seed.yml
  

The command is idempotent. Existing resources are skipped, and new ones are created as needed.

You can also clean up everything it created:

  
workos seed --clean
  

For agents, this changes how environments are managed.

Instead of issuing a sequence of commands or relying on manual setup, an agent can define the desired state of your WorkOS environment, apply it, and keep it in sync over time.

6. Resource commands for real data access

The CLI now exposes a curated set of authenticated resource commands that wrap core WorkOS APIs.

Your agent can programmatically access:

• Roles.
• Permissions.
• Audit logs.
• Directories.
• Users.
• And more.

Instead of manually wiring API calls or crafting curl requests, your agent can query real data from your environment and use it to debug, reason, and build.

This unlocks workflows like:

• Debugging an authorization issue by checking the actual roles/permissions state.
• Pulling recent audit events to confirm an action happened.
• Inspecting directory configuration without writing one-off scripts.

It’s the difference between an agent that can suggest what to do and an agent that can verify what’s true.

A tighter loop for agent-driven development

Each of these pieces is useful on its own, but together they make WorkOS predictable to automate against.

A typical workflow now looks more like:

1. Scaffold or update integration code with your agent.
2. Define your environment in a workos-seed.yml file
3. Apply it using workos seed
4. Run workos doctor to catch setup issues early.
5. Apply required configuration changes via CLI commands.
6. Validate behavior using resource commands against real environment data.

The difference isn’t just fewer clicks. It’s a different development rhythm.

Before:

• Write code.
• Switch to dashboard.
• Update config.
• Test.
• Manually inspect state.
• Debug.

Now:

• Write or update code with your agent.
• Define environment state declaratively.
• Apply configuration programmatically.
• Run diagnostics.
• Validate using authenticated resource commands.

The terminal becomes the control surface.

Your agent can reason about WorkOS, apply configuration changes, inspect live resources, and verify system state. And you stay in the same workflow the entire time.

WorkOS is no longer a service you configure in parallel, but a system your agent can operate within.

Built for how developers build today

Teams are increasingly pairing agents with terminals and editors to move faster. The best developer platforms support that directly, by making setup, configuration, and verification possible through tools that agents can reliably use.

Agent Experience is our step in that direction: agent-friendly by default, across products, and designed to reduce friction from first integration to ongoing operations.

If you’re building with Claude, Cursor, Codex, or another coding agent, WorkOS now fits directly into that loop.

No detours, broken context, or dashboard dependency.

Just build.