---
title: "Driving the agent from your own product"
description: "Can my product drive the Coassemble agent?"
canonical_url: "https://support.coassemble.com/articles/driving-the-agent-from-your-own-product-7P4qRy443J"
md_url: "https://support.coassemble.com/articles/driving-the-agent-from-your-own-product-7P4qRy443J.md"
---
# Can my product drive the Coassemble agent?

> How to give your own users AI course building inside your product, using the same agent tools that run in the Coassemble builder.

Yes. The Coassemble agent exposes the course lifecycle as tools, and your application can call them over MCP or REST. Your backend mints an agent token, scopes it to what that user is allowed to do, and drives course creation and editing on their behalf without them ever opening Coassemble.

Course generation still runs on Coassemble's own AI, so a course your product generates is the same course a user would get building it in the app.

## What can my product do with it?

The tools cover the course lifecycle in five groups:

* **Create.** Build a course from a brief or from a document your user supplies, and generate screens, blocks and assessment.
* **Enrich.** Rewrite content, add narration or translations, apply themes and branding, and place or generate images.
* **Publish and share**, including getting a share link.
* **Organise.** Restructure a course, reorder screens, and group courses into collections and folders.
* **Measure.** Read analytics at course and screen level.

## How do I keep it inside the lines?

Three controls are set when you mint the token, and they are the reason this is safe to expose to your own users.

* **Pin it to a course.** `courseId` ties the token to a single course, so anything the agent does can only affect that course and nothing else in the workspace. This is the control to reach for when each of your users works on their own content.
* **Allowlist the tools.** `tools` takes the list of tools that token may call. Omit it and the token gets the full surface, so set it when you want your product to decide whether a user can, for example, publish or delete.
* **Make it read-only.** `readonly: true` restricts the token to read tools, which suits an assistant that answers questions or reads analytics without changing anything.

Together these mean the agent in your product can be much narrower than the agent in the Coassemble builder, which is usually what you want when your users are your customers rather than your own team.

## Which should I use, MCP or REST?

Both reach the same tools, so the choice is about how your product is built.

* **MCP** suits a product that already has an AI assistant or agent of its own. Your assistant discovers the Coassemble tools and calls them as part of its own reasoning, so you are not writing course-building logic yourself. You authenticate at the MCP endpoint with `Authorization: Bearer <agent-token>`.
* **REST** suits a product driving Coassemble deterministically. Your code lists the tools and runs them itself, which is the better fit when the flow is fixed and you want predictable results.

You can use both. A product might drive course creation deterministically over REST and expose a conversational assistant over MCP for the parts a user wants to explore.

## How is the caller identified?

Your backend holds your workspace API key and uses it to mint an agent token. The token carries an `identifier` for the end user the agent is acting as, so activity is attributed to that user rather than to a shared service account.

Your users never get a Coassemble login, and your API key never leaves your backend. There is no second identity system to keep in sync: a course created for one of your users belongs to that user, exactly as it would if they had built it in an embedded builder.

## Where are the endpoints documented?

Every endpoint, tool and parameter is in the developer documentation at [developers.coassemble.com](https://developers.coassemble.com), with the MCP specifics at [developers.coassemble.com/embed-mcp](https://developers.coassemble.com/embed-mcp). This article covers what the capability is and how to think about scoping it. The developer docs are the reference for actually calling it.

## Frequently asked questions

### Does my product need its own AI model?

No. Coassemble's AI does the generating. Your product supplies the request and the identity, and receives the result. Connecting your own assistant over MCP is an option rather than a requirement.

### Can my users see that AI built the course?

That is your call. The agent returns the course into your product, and the surrounding experience is yours to design, so whether the user sees a conversation, a progress indicator or just a finished course is up to you.

### Is this the same agent my users get in an embedded builder?

The same tools, driven differently. In an embedded builder your user talks to the agent directly. Driven from your product, your application mints the token, makes the requests and decides what the user sees.

### Can I give different users different permissions?

Yes, and this is what the token controls are for. Mint a read-only token for a viewer, a course-pinned token for someone editing one course, and an allowlisted token for a user who should be able to edit but not publish.