Files
crewAI/docs/edge/en/enterprise/guides/training-crews.mdx
Lucas Gomide a237ebabba feat: adopt directory-based docs versioning with Edge channel (#6202)
* feat: adopt directory-based docs versioning with Edge channel

Switch docs.crewai.com from navigation-only versioning (every version
selector entry rendered the same docs/<lang>/* source files) to
Mintlify's directory-based versioning so each version selector entry
renders its own snapshot. Add an "Edge" channel under docs/edge/<lang>/*
that always reflects main HEAD for unreleased work, eliminating
pre-release leakage onto frozen release labels. External links to
canonical /<lang>/* URLs are preserved via wildcard redirects that
always land on the current default version.

Layout:
- docs/edge/<lang>/*         rolling source (you edit here)
- docs/edge/enterprise-api.*.yaml
- docs/v<X.Y.Z>/<lang>/*     frozen, immutable snapshots
- docs/v<X.Y.Z>/enterprise-api.*.yaml
- docs/images/               shared, append-only
- docs/docs.json             nav + redirects

URLs follow the Mintlify-idiomatic shape: /edge/<lang>/<page> for
Edge, /v<X.Y.Z>/<lang>/<page> for every frozen snapshot. The wildcard
redirects /<lang>/:slug* -> /<default>/<lang>/:slug* keep stale links
working, and every freeze rewrites them (plus all per-section/per-page
redirects) so destinations always resolve to the current default
without depending on a second redirect hop.

Release flow integration (devtools release):
- New module crewai_devtools.docs_versioning.freeze() materialises
  docs/v<X.Y.Z>/ from docs/edge/, rewrites openapi: refs inside the
  snapshot, inserts the version into every language block in
  docs.json, and refreshes all redirect destinations.
- _update_docs_and_create_pr() in cli.py now calls that freeze during
  Phase 2 of devtools release. Edge changelogs are updated first (so
  the snapshot freeze picks them up), then the snapshot is staged
  alongside docs.json, branched as docs/freeze-v<X.Y.Z>, and the PR
  is titled [docs-freeze] docs: snapshot and changelog for v<X.Y.Z>
  — the title prefix the new CI guard reads.
- The PR still gates tag, GitHub release, PyPI publish, and the
  enterprise release as before; no new PRs are added.
- Pre-releases (1.X.YaN, 1.X.YbN, ...) skip the snapshot — they ride
  Edge — and the docs PR title omits the [docs-freeze] prefix.
- docs_check (AI-generated docs scaffolding) writes to
  docs/edge/<lang>/* so newly-generated unreleased docs land in Edge
  and never accidentally touch a frozen snapshot.

Migration scripts (one-shot):
- scripts/docs/freeze_historical_versions.py reconstructs all 16
  historical snapshots (v1.10.0 .. v1.14.7) from git tags via
  git archive | tar, rewriting openapi: MDX refs so each snapshot
  reads its own enterprise-api YAML rather than the live one.
- scripts/docs/prefix_version_paths.py one-shot-migrates docs.json:
  rewrites every page path in 16 versioned blocks to point under
  docs/v<X.Y.Z>/, inserts a new Edge entry per language, tags
  v1.14.7 as Latest (default), prunes pages whose target file
  doesn't exist in the snapshot (e.g. docs/ar/ didn't exist before
  v1.12.0), and writes the wildcard + per-section redirects.
- scripts/docs/freeze_current_edge.py is now a thin CLI wrapper
  around docs_versioning.freeze for manual one-off freezes (e.g.
  retroactively snapshotting a forgotten release).

CI guards (.github/workflows/docs-snapshots.yml):
- Frozen snapshots under docs/v[0-9]*/ are immutable; only PRs whose
  title contains [docs-freeze] (i.e. release-cut PRs generated by
  devtools release or the manual wrapper) may modify them.
- Images under docs/images/ are append-only since snapshots share a
  single image directory. Deleting or renaming an image breaks every
  historical snapshot that still references it.

Restored docs/images/crewai-otel-export.png from PR #3673; it was
deleted in PR #4908 but v1.10.0 / v1.10.1 snapshots still reference
it. Restoring instead of editing the snapshots preserves historical
rendering fidelity and validates the new append-only rule
retroactively.

Tests:
- lib/devtools/tests/test_docs_versioning.py covers the freeze: file
  copy, openapi rewrite, version insertion, default demotion, redirect
  upserts, per-section redirect rewriting, idempotency, and invalid
  inputs.

Verified locally with mintlify broken-links: 0 broken links across
the full site (Edge + 16 frozen versions, 4 locales).

AGENTS.md (repo root) is the contributor guide for the new model;
RELEASING.md is the release-cut runbook; README's Contribution
section links to both.

Co-authored-by: Cursor <cursoragent@cursor.com>

* style: resolve linter issues

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-17 11:56:59 -04:00

133 lines
5.4 KiB
Plaintext

---
title: "Training Crews"
description: "Train your deployed crews directly from the CrewAI AMP platform to improve agent performance over time"
icon: "dumbbell"
mode: "wide"
---
Training lets you improve crew performance by running iterative training sessions directly from the **Training** tab in CrewAI AMP. The platform uses **auto-train mode** — it handles the iterative process automatically, unlike CLI training which requires interactive human feedback per iteration.
After training completes, CrewAI evaluates agent outputs and consolidates feedback into actionable suggestions for each agent. These suggestions are then applied to future crew runs to improve output quality.
<Tip>
For details on how CrewAI training works under the hood, see the [Training Concepts](/en/concepts/training) page.
</Tip>
## Prerequisites
<CardGroup cols={2}>
<Card title="Active deployment" icon="rocket">
You need a CrewAI AMP account with an active deployment in **Ready** status (Crew type).
</Card>
<Card title="Run permission" icon="key">
Your account must have run permission for the deployment you want to train.
</Card>
</CardGroup>
## How to train a crew
<Steps>
<Step title="Open the Training tab">
Navigate to **Deployments**, click your deployment, then select the **Training** tab.
</Step>
<Step title="Enter a training name">
Provide a **Training Name** — this becomes the `.pkl` filename used to store training results. For example, "Expert Mode Training" produces `expert_mode_training.pkl`.
</Step>
<Step title="Fill in the crew inputs">
Enter the crew's input fields. These are the same inputs you'd provide for a normal kickoff — they're dynamically loaded based on your crew's configuration.
</Step>
<Step title="Start training">
Click **Train Crew**. The button changes to "Training..." with a spinner while the process runs.
Behind the scenes:
- A training record is created for your deployment
- The platform calls the deployment's auto-train endpoint
- The crew runs its iterations automatically — no manual feedback required
</Step>
<Step title="Monitor progress">
The **Current Training Status** panel displays:
- **Status** — Current state of the training run
- **Nº Iterations** — Number of training iterations configured
- **Filename** — The `.pkl` file being generated
- **Started At** — When training began
- **Training Inputs** — The inputs you provided
</Step>
</Steps>
## Understanding training results
Once training completes, you'll see per-agent result cards with the following information:
- **Agent Role** — The name/role of the agent in your crew
- **Final Quality** — A score from 0 to 10 evaluating the agent's output quality
- **Final Summary** — A summary of the agent's performance during training
- **Suggestions** — Actionable recommendations for improving the agent's behavior
### Editing suggestions
You can refine the suggestions for any agent:
<Steps>
<Step title="Click Edit">
On any agent's result card, click the **Edit** button next to the suggestions.
</Step>
<Step title="Modify suggestions">
Update the suggestions text to better reflect the improvements you want.
</Step>
<Step title="Save changes">
Click **Save**. The edited suggestions sync back to the deployment and are used in all future runs.
</Step>
</Steps>
## Using trained data
To apply training results to your crew:
1. Note the **Training Filename** (the `.pkl` file) from your completed training session.
2. Specify this filename in your deployment's kickoff or run configuration.
3. The crew automatically loads the training file and applies the stored suggestions to each agent.
This means agents benefit from the feedback generated during training on every subsequent run.
## Previous trainings
The bottom of the Training tab displays a **history of all past training sessions** for the deployment. Use this to review previous training runs, compare results, or select a different training file to use.
## Error handling
If a training run fails, the status panel shows an error state along with a message describing what went wrong.
Common causes of training failures:
- **Deployment runtime not updated** — Ensure your deployment is running the latest version
- **Crew execution errors** — Issues within the crew's task logic or agent configuration
- **Network issues** — Connectivity problems between the platform and the deployment
## Limitations
<Info>
Keep these constraints in mind when planning your training workflow:
- **One active training at a time** per deployment — wait for the current run to finish before starting another
- **Auto-train mode only** — the platform does not support interactive per-iteration feedback like the CLI does
- **Training data is deployment-specific** — training results are tied to the specific deployment instance and version
</Info>
## Related resources
<CardGroup cols={3}>
<Card title="Training Concepts" icon="book" href="/en/concepts/training">
Learn how CrewAI training works under the hood.
</Card>
<Card title="Kickoff Crew" icon="play" href="/en/enterprise/guides/kickoff-crew">
Run your deployed crew from the AMP platform.
</Card>
<Card title="Deploy to AMP" icon="cloud-arrow-up" href="/en/enterprise/guides/deploy-to-amp">
Get your crew deployed and ready for training.
</Card>
</CardGroup>