# CrewAI for Software Teams: Sandboxes, Coding Agents and CI

> CrewAI for engineering teams: E2B and Daytona sandboxes, skills for Claude Code and Cursor, experimental crewai eval, GitHub, Jira, Linear and AMP deploys.

_Source: https://professionalstoolkit.com/articles/crewai-for-software-teams — The Professional's Toolkit · updated November 2026_

---

CrewAI fits engineering teams well, provided someone on the team owns Python. The open-source CrewAI framework is MIT-licensed and free to run on your own machines, and it gives developers sandboxed code execution through E2B or Daytona, a skills pack for Claude Code, Cursor, Codex and Gemini CLI, and a `crewai eval` command that hands failures back to a coding agent. The paid platform, CrewAI AMP (Agent Management Platform), adds Git-based deployment plus GitHub, Jira and Linear integrations. Its free Basic plan includes 2 automations and 50 workflow executions a month. Treat that as a pilot.


**50** — Workflow executions a month on the free AMP Basic plan, which is also the maximum (2 automations).



- **2 sandboxes** — E2B and Daytona replace the code interpreter removed in April 2026
- **4 skills** — In CrewAI's skills pack for Claude Code, Cursor, Codex and Gemini CLI
- **3.10 to 3.13** — Python versions the open-source framework supports (3.10 or newer, below 3.14)


## What an engineering team actually gets from CrewAI

Two products share the name. The framework is the Python package `crewai`: agents, tasks, crews and Flows that run wherever you run Python, which here means **3.10 or newer and below 3.14**. The CLI installs with `uv tool install crewai`. New projects are JSON-first, so `crewai create crew` writes agents to `agents/*.jsonc` and crew settings to `crew.jsonc`, while the older YAML and `crew.py` layout needs the `--classic` flag. Agent definitions therefore live in the repository as plain config files, next to the code that calls them.

AMP is the hosted layer that builds, deploys, triggers, monitors and governs those crews. Every deployed crew or flow becomes an automation with its own API, triggers and traces. Neither layer pays for models. You bring your own keys, with native connections for OpenAI, Anthropic, Gemini, Azure, Bedrock and Snowflake Cortex, and other providers through the optional LiteLLM extra. Out of the box the default model is an OpenAI one, so a fresh project expects an OpenAI key. The token bill is always yours.

CrewAI's own guidance on structure is simple: use a crew when the path to the answer is open-ended, and a Flow when you control the steps, order and conditions. For production apps the docs suggest starting with a Flow and running a crew inside one step. Open-ended bug research that needs judgment suits a crew; a fixed triage pipeline with branches suits a Flow. Our [CrewAI Flows guide](/articles/crewai-flows) covers the decorators, state and persistence behind that choice.



> ⚠ **Hooks fail open:** Any exception in a hook other than HookAborted is swallowed, so a buggy approval hook lets the tool call through.

## Letting agents run code without handing them your servers

The built-in code interpreter is gone. CodeInterpreterTool was removed in April 2026, and the agent setting that allowed code execution is deprecated. Code now runs through sandbox tools added the same month. The E2B set (E2BExecTool, E2BPythonTool, E2BFileTool) gives an agent a shell, a Python interpreter and file access inside isolated, ephemeral remote VMs; it installs with the `e2b` extra and needs an `E2B_API_KEY` [1]. Its idle timeout defaults to 300 seconds and does not cap total execution time, so a long test run is not cut off.

Daytona offers the same three capabilities as DaytonaExecTool, DaytonaPythonTool and DaytonaFileTool, through the `daytona` extra and a `DAYTONA_API_KEY`, which means a Daytona account. Its sandboxes are ephemeral by default, created and deleted on every call. Persistent mode keeps one sandbox until the process exits, and attach mode reuses an existing sandbox without deleting it. **Ephemeral suits untrusted one-off snippets; persistent suits an agent that installs dependencies and then runs tests across several calls.** Both services bill you directly, never through CrewAI.

The framework also guards the host. File tools are confined to the working directory, and `file://` URIs and private IP ranges are blocked against SSRF; setting `CREWAI_TOOLS_ALLOW_UNSAFE_PATHS=true` disables that for the whole process. FileWriter does not overwrite by default, and NL2SQL stays read-only unless you pass `allow_dml`. One trap matters for shared repos: JSON crew projects execute local Python when custom tools load. Run only projects you trust.


> ⚠ **JSON projects can run local code:** JSON crew projects execute local Python when custom tools load, so run only projects from sources you trust.


## Building crews from inside Claude Code, Cursor or Codex

CrewAI assumes a coding assistant will write much of the crew. The CLI scaffolds an `AGENTS.md` at the project root, plus `CLAUDE.md` and `GEMINI.md` files that import it, because Claude Code reads `CLAUDE.md` rather than `AGENTS.md`. The official skills pack installs with `npx skills add crewaiinc/skills` or through the Claude Code plugin marketplace, and works with Claude Code, Codex, Cursor and Gemini CLI [2]. It holds four skills: getting-started, design-agent, design-task and ask-docs, which queries the live docs MCP server. The docs also publish an `llms.txt` for agents.

Custom tools are where engineers spend real time. A tool is either a `BaseTool` subclass that implements `_run` or a function with the `@tool` decorator, a docstring and type annotations. Async tools use `_arun`, `EnvVar` declares the keys a tool needs, and `result_schema` returns typed output. Scaffold one with `crewai create tool`. To share tools across the organization, AMP has a Tool Repository, private by default, which needs an AMP account, uv 0.5.0 or newer and Git. It is not version control. A deleted tool cannot be restored, so keep the source in your own repository. The [CrewAI tools guide](/articles/crewai-tools) maps the rest of the 75+ tool catalog.


> 💡 **Expose only the actions needed:** List single AMP actions such as github/create_issue in an agent's apps instead of granting every GitHub action.


## GitHub, Jira and Linear: what agents can touch

| Capability | Layer | What it needs |
|---|---|---|
| GithubSearchTool | Open-source framework | GitHub personal access token |
| GitHub integration | AMP | AMP account with an active subscription, connected GitHub account |
| Jira integration | AMP | AMP account with an active subscription, Jira project permissions |
| Linear integration | AMP | AMP account with an active subscription, workspace permissions |
| E2B or Daytona sandboxes | Open-source framework | Own account and API key |

On the framework side, GithubSearchTool searches code, repository details, pull requests and issues, with embeddings and summarization defaulting to OpenAI. CodeDocsSearchTool, which searches documentation, is marked experimental. The AMP integrations act rather than search. GitHub covers creating, updating, fetching, searching and locking issues, plus creating, updating, fetching and deleting releases. Jira covers creating and updating issues, fetching by key, filtering, JQL search and listing projects, issue types, statuses and assignees. Linear covers issues, sub-issues, projects and team search.

Two Jira details catch scripts out. The `filter_issues` action returns at most 10 issues when no limit is given, and custom issue types go through `describe_action_schema` and `update_issue_any`, which read the expected schema first. Code that calls these apps from the framework sets `CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN`. For least privilege, list single actions such as `github/create_issue` instead of exposing every GitHub action to the agent.

Approval gates come from hooks. A pre-tool hook can ask a human to approve an action before the tool runs, and it blocks a call by raising `HookAborted`. Any other exception inside a hook is swallowed, so a buggy hook does not crash the run. That fail-open design cuts both ways: an approval hook with a bug lets the call through. Test the approval path itself, not only the happy path.

## Shipping crews through the pipeline you already run

AMP deploys from GitHub, any Git provider, a ZIP upload or the CLI, and the web interface can deploy from a connected GitHub account with no local CLI. Commits are not picked up unless Auto-update was checked at deploy time; otherwise someone presses Re-deploy. For CI, existing deployments redeploy from GitHub Actions or similar with a personal access token and the Deploy API [3]. A committed `uv.lock` is required, and without it the build fails during dependency resolution.

Monorepos work by setting a working directory, but that setting lives in the web interface rather than the deploy CLI, and it cannot be combined with auto-deploy. Internal packages come from authenticated private registries such as Azure DevOps Artifacts, GitHub Packages, GitLab, AWS CodeArtifact, Google Artifact Registry and JFrog Artifactory. Their credentials go into `UV_INDEX` environment variables in AMP settings, never into `.env` files. Once deployed, each automation answers on `/inputs`, `/kickoff` and `/status/{kickoff_id}` with a bearer token, and can call back on every step, task or finished run.

The plan decides how far that goes. Basic is Free with 2 automations and 50 workflow executions a month; 50 is also the maximum, and additional executions are not included [4]. By our arithmetic that is about 1.7 a day on a 30-day month: enough for a pilot, not for a pipeline that fires on every pull request. Enterprise is Custom, behind a Request trial button. A team moves there for more than 50 workflow executions a month or more than 2 automations, and for enterprise connectors, SSO with Microsoft Entra or Okta, role-based access control, a dedicated VPC and NAT, PII redaction and dedicated support. The full plan comparison is in our [CrewAI buyer's checklist](/articles/crewai-buyers-checklist).


> 💡 **Commit uv.lock before deploying:** AMP requires a committed uv.lock; without it the build fails during dependency resolution.


## Testing agents the way you test code

`crewai eval` is the most engineering-shaped feature here. Added in October 2026 as an experimental open-source command, it evaluates the last traced run, so no fixture library is needed first. It writes a markdown brief meant for a coding agent to parse and names the role and Flow step where a run failed. The `--models` option swaps models per role against a baseline, and `--no-open` suits headless use. The loop is short: run, evaluate, hand the brief to Claude Code or Codex. Tracing itself needs a free AMP account and `crewai login`.

The older checks still matter. `crewai test` runs 3 iterations by default and scores 1 to 10, and the docs name OpenAI as its only testing provider. Task guardrails, written as Python functions or plain-language checks, retry a failed task up to 3 times by default. The fifth identical tool call (same tool, same arguments, same result) stops the task, and `max_iter`, `max_execution_time`, `max_rpm` and task `max_tokens` cap spend. Reviewers still report token use and run time climbing fast in multi-agent work.

Results reported by customers are worth reading as direction, not promise. CrewAI's case study says PwC saw code-generation accuracy rise from roughly 10% to more than 70% after adding CrewAI agents to its workflow; that figure is customer-reported. One setting belongs in every CI image: the open-source package sends anonymous telemetry by default, and `CREWAI_DISABLE_TELEMETRY` turns it off. Tracing is a separate switch.


## FAQ

**Can CrewAI run with local models for code that must stay on our network?**

Yes, if you configure it. Point the LLM at Ollama through the optional LiteLLM extra or an OpenAI-compatible endpoint with custom_openai and a base_url, and set an Ollama embedder for memory, knowledge and search tools, since those default to OpenAI. Also set planning_llm and turn off telemetry with CREWAI_DISABLE_TELEMETRY; crewai test supports only OpenAI.

**Does the crewai package depend on LangChain?**

No. The package does not depend on LangChain or other agent frameworks, although agents can still use wrapped LangChain and LlamaIndex tools.

**Can a deployed crew be called from our coding assistant?**

A deployed automation can be exported as an MCP server, and the pricing table lists that export on both Basic and Enterprise.

**Is there a self-hosted option for engineering teams with strict infrastructure rules?**

CrewAI Factory is the self-hosted form of AMP Enterprise, deployable in a data center or VPC, on AWS Fargate, Azure Container Apps, Kubernetes via Helm or Red Hat OpenShift; it is sold on the Enterprise plan.


## Framework first, AMP when the pipeline asks for it

For most engineering teams the sensible order is the framework first: install it, scaffold with your coding assistant, run code only inside E2B or Daytona, and wire `crewai eval` into the review loop, paying nothing to CrewAI. Move to AMP when a crew needs to answer an API, act on GitHub, Jira or Linear issues, or redeploy from CI. Basic shows whether that works within 2 automations and 50 workflow executions a month. More volume, enterprise connectors, SSO, role-based access control and dedicated support wait on an Enterprise quote.



## Sources

[1] CrewAI documentation: E2B Sandbox Tools — https://docs.crewai.com/en/tools/ai-ml/e2bsandboxtools (2026-11)
[2] CrewAI documentation: Build with AI — https://docs.crewai.com/en/guides/coding-tools/build-with-ai (2026-11)
[3] CrewAI AMP documentation: Deploy to AMP — https://docs-platform.crewai.com/platform/en/guides/deploy-to-amp (2026-11)
[4] CrewAI pricing — https://crewai.com/pricing (2026-11)
[5] CrewAI documentation: Installation — https://docs.crewai.com/en/installation
[6] CrewAI Terms of Use — https://crewai.com/terms-of-use
[7] AWS Marketplace: CrewAI Enterprise Platform reviews (from G2) — https://aws.amazon.com/marketplace/reviews/reviews-list/prodview-2lisdk6meykru