Feature: Documentation for Production Code Execution in Crews

[abhinaykrupa]

Problem

CrewAI teams building production crews need documented patterns for:

• Agents executing generated code safely
• Local repository and environment access
• Production safety (sandboxing, resource limits, timeouts)

Currently this is undocumented, unlike other agent frameworks.

Today's Gap

Teams choose between:

1. No code execution — limits crew capabilities
2. Cloud sandboxes — external cost, context loss
3. Custom implementations — inconsistent, fragile

Comparison

• AutoGen — documents code_execution_config pattern
• MetaGPT — documents local executor patterns
• CrewAI — [no standard pattern documented]

Proposed Solution

Add to CrewAI documentation:

1. Code Execution Strategy Guide — cloud vs local tradeoffs
2. Production Patterns — sandboxing, resource limits, error handling
3. Example Crew — multi-agent code execution workflow
4. Best Practices — security, performance, monitoring

Why This Matters

This helps CrewAI teams build production crews that safely execute generated code, matching capabilities in competing frameworks.

Teams need official guidance to make code execution production-safe, not DIY solutions.

Reference

MCP servers and similar patterns demonstrate how to implement this safely and securely.

[xg-gh-25]

This gap is real — most agent frameworks document agent coordination (Crew, Flow) but not code execution boundaries (how do agents safely run generated code in production?).

Why This Matters (Production Context)

When you ship a crew that generates + executes code, you need answers to:

1. Where does the code run? (cloud sandbox vs local process vs container)
2. What can it access? (filesystem scope, network, secrets)
3. When does it time out? (runaway loops, hanging I/O)
4. How do you audit it? (logs, traces, rollback)

Without documented patterns, teams reinvent this (inconsistently) or skip code execution entirely.

Pattern We Use (Reference, Not Prescription)

We run agent-generated code through a sandboxed skill boundary:

• Skills are Python modules with declared dependencies
• Each skill runs in an isolated venv (resource limits + timeout)
• Filesystem access: scoped to skill workspace + explicit shared dirs
• Network: allow-list only (no arbitrary outbound)
• Audit: all generated code logged to .artifacts/generated_code/ before execution

The skill boundary gives us:

• Safety: runaway code can't corrupt the agent's state
• Reproducibility: re-run the exact generated code from logs
• Visibility: trace which agent decision produced which code

What CrewAI Documentation Could Add

Suggested structure (not prescriptive):

1. Code Execution Strategy Guide — cloud (e.g., E2B) vs local (subprocess) tradeoffs
2. Safety Patterns — timeouts, resource limits, filesystem scoping
3. Example Crew — multi-agent workflow where one agent generates code, another reviews, third executes
4. Production Checklist — logging, rollback, error recovery

This doesn't need to mandate one approach — just document the decisions teams must make and reference examples.

AutoGen's code_execution_config is a good reference — it's opinionated but pluggable. CrewAI could do similar with a "code executor" abstraction.

---

We run multi-skill crews in production with sandboxed code execution. SwarmAI. Discussion: T-DDD

[abhinaykrupa]

Exactly — you've articulated the core gap perfectly. Most frameworks document agent choreography (who calls whom, dependencies) but skip the code execution boundary entirely.

Your sandboxed skill boundary approach is solid. Let me share how we think about this and see if there's overlap with what would help CrewAI:

The Pattern You're Using (SwarmAI)

Skill Boundary:
  - Python module with declared deps
  - Isolated venv (resource limits + timeout)
  - Filesystem: scoped workspace + explicit shared dirs
  - Network: allow-list only
  - Audit: all generated code logged before execution

This gives you safety + reproducibility + visibility — the three things teams actually need in production.

Where CrewAI Documentation Could Land

Rather than mandating one approach, CrewAI could document the decision tree teams must make:

1. Where does generated code run?

• Cloud sandbox (E2B, Replit, etc.) — easy setup, per-execution cost
• Local subprocess — free, no API billing, but harder to sandbox
• Container (Docker, venv) — best isolation, more overhead
• [Your SwarmAI approach] — skill boundary with declared deps

2. What scope does it have?

• Filesystem (current dir, repo, /tmp, none)
• Environment (inherit agent's env, isolated, allowlist)
• Network (any, allowlist, none)
• Process lifetime (per-execution, per-task, per-crew)

3. How do you make it reproducible?

• Log generated code before execution
• Capture exact Python version, deps, env state
• Enable re-run from logs on failure

4. How do you recover from failures?

• Timeout (how long before kill)
• Rollback (revert filesystem changes)
• Retry (same environment or fresh one)

Reference: cowork-to-code-bridge Pattern

We've implemented one opinionated answer to this (what we've proposed for CrewAI docs):

Where: Local subprocess (uses your Claude Code + repos)
Scope: Full agent context (your shell, files, env)
Reproducibility: JSON checkpoint + execution logs
Recovery: Idempotency keys + journal replay

It's not the only answer (your venv boundary is equally valid), but it's a worked example of how to think through the decision tree.

---

What Would Help CrewAI Teams

If CrewAI's docs included even a simple "Code Execution Strategy" guide, teams could:

1. Understand the tradeoffs (safety vs cost vs complexity)
2. See reference implementations (E2B, local subprocess, venv boundary, etc.)
3. Know what to audit before shipping (timeout, rollback, logging)

You could even link to projects doing it well — SwarmAI, our bridge, etc. — as examples rather than mandating one.

---

Question for You

Since you've productionized this — what's the failure mode you hit that made you go full venv isolation + skill boundary? Was it state bleed, resource exhaustion, or security concern?

I ask because different teams have different risk profiles. If we're writing docs, it'd be good to call out:

• "If you're worried about state bleed → venv isolation"
• "If you're worried about runaway loops → timeout + resource limits"
• "If you're worried about filesystem access → scoped workspace"

Rather than one solution fits all.

---

References:

• SwarmAI approach: your repo linked above
• Our approach (for reference): STATEFUL_OPERATION_PATTERN.md + daemon.py

---

Would love to see CrewAI docs land this. Teams shipping agents in production will build it themselves if it's not documented — and they'll probably build it inconsistently. Better to have a decision tree + examples.

[abhinaykrupa]

This is incredibly valuable — you've articulated the exact production patterns teams need. The fact that you've productionized this tells us it's not theoretical.

Your Skill Boundary Approach is Gold

Your pattern (venv + declared deps + scoped workspace + allow-list network) solves the three things that actually hurt in production:

1. State isolation — Runaway code can't corrupt agent memory/state
2. Reproducibility — Exact generated code logged = audit trail + re-run capability
3. Visibility — Trace agent decision → generated code → execution result

This is exactly what CrewAI teams need to hear about.

---

How cowork-to-code-bridge Fits

We've implemented a different opinionated answer to the same questions, which could serve as a second reference implementation in the docs:

Dimension	SwarmAI (Your Approach)	cowork-to-code-bridge	Trade-off
Where does code run?	Isolated venv + skill boundary	Local subprocess (Claude Code native environment)	venv = more isolated; subprocess = simpler setup
Scope	Scoped workspace + allow-list network	Full agent context (repos, shell, env)	workspace = safer; context = more powerful
Timeout	Built into skill execution	Configurable per task (default 300s)	Same outcome, different trigger
Audit	Logged to .artifacts/generated_code/	JSON journal + operation logs	Same story; file structure differs
Recovery	Rebuild venv, re-run from logs	Operation checkpoints + replay	Same recovery story

Key insight: Both patterns solve the same problem. You chose venv isolation because your threat model emphasizes developer safety (don't corrupt my code). We chose subprocess isolation because our threat model emphasizes context preservation (keep agent's full environment).

Neither is "right" — they're risk-profile decisions.

---

What This Means for CrewAI Docs

The decision tree you outlined (where/what/when/how) could include both approaches as reference implementations:

Option A: Skill Boundary (Your Pattern)

Best when: Team wants maximum isolation, explicit dependency management
Tradeoff: More setup, scoped filesystem access
Example: SwarmAI's approach (linked above)

Option B: Local Subprocess (Our Pattern)

Best when: Team wants agent to leverage full repo/shell context
Tradeoff: Simpler setup, less isolation
Example: cowork-to-code-bridge (MCP + local escalation)

Option C: Cloud Sandbox (E2B, etc.)

Best when: Team wants managed security + no local setup
Tradeoff: Per-execution costs, latency, API dependency
Example: E2B, Replit, etc.

---

A Concrete Example for the Docs

Here's what a CrewAI example could look like:

from crewai import Agent, Task, Crew
from code_execution_strategy import CodeExecutor  # Abstract base

# Three strategies available:
# CodeExecutor.VenvBoundary() — SwarmAI approach (isolated, explicit)
# CodeExecutor.LocalSubprocess() — cowork-to-code-bridge approach (context-rich)
# CodeExecutor.CloudSandbox() — E2B approach (managed)

executor = CodeExecutor.VenvBoundary(
    workspace_dir="/tmp/crew_workspace",
    allowed_network=["github.com", "api.example.com"],
    timeout_seconds=300,
    audit_dir=".artifacts/generated_code"
)

generator = Agent(name="Code Generator", ...)
reviewer = Agent(name="Code Reviewer", ...)
executor_agent = Agent(name="Code Executor", code_executor=executor)

crew = Crew(agents=[generator, reviewer, executor_agent])
result = crew.kickoff()

The config makes it explicit: "here's where code runs, what it can access, how long it has, where we audit it."

---

Question for You

When you ship SwarmAI with full venv isolation, do teams ever complain about not having access to context (like repo files, shell history, env secrets)? Or is that isolation actually the feature (i.e., "run untrusted generated code safely")?

I ask because that's the trade-off CrewAI teams will face:

• Venv isolation = safer for untrusted generated code
• Subprocess context = more powerful for trusted-but-complex code

Knowing your real-world failure mode would help frame the decision for others.

---

Proposal

Would it be valuable if CrewAI docs included:

1. Decision Tree (what you outlined)
2. Three Reference Implementations (cloud, venv boundary, local subprocess)
3. Example Crew (abstract code executor, swappable strategies)
4. Production Checklist (your list: logging, rollback, error recovery)

If so, we'd love to contribute example code for the "local subprocess" strategy alongside whatever SwarmAI example you link for the venv boundary approach.

---

References:

• SwarmAI approach: your repo
• Our approach: cowork-to-code-bridge daemon.py + STATEFUL_OPERATION_PATTERN.md

Looking forward to your thoughts on the failure mode question — that'll help shape how we think about positioning this pattern.

[Fame510]

@abhinaykrupa If you're running crews in production, you absolutely need runtime guardrails. Here's what I learned the hard way:

Production Risks Without Circuit Breakers:

1. Infinite loops — Agent hits an error, retries indefinitely, burns API budget
2. No budget limits — Crew runs until it exhausts your money
3. Silent failures — Tool hangs, no timeout, process frozen indefinitely

I hit a $400 loop in production before building SHACKLE to prevent this.

Production-Safe Pattern:

from shackle import Guard

@Guard(
    budget=1.00,           # Hard stop at $1.00 per run
    max_repeat_calls=3,    # Catch loops on 3rd duplicate
    timeout_seconds=300,   # 5-minute hard timeout
)
def production_crew_run():
    return crew.kickoff()

What This Gives You:

• Budget enforcement — Prevents runaway costs (critical in production)
• Loop detection — Catches repeat tool calls before they burn $$$
• Timeout protection — Prevents hung processes from blocking resources
• Interactive recovery — HITL console for Resume/Skip/Abort (useful in staging/debugging)

For Production Deployment:

SHACKLE works great for:

• Supervised production (internal dashboards, admin panels where humans monitor)
• Development/staging (catch issues before they hit prod)
• CLI-based production tasks (cron jobs, scheduled reports)

For headless production APIs (FastAPI, serverless functions), you'll want automated fallback instead of interactive control. In those cases, framework-native solutions like TokenCircuit are better suited.

Key Point:

Don't deploy crews to production without some form of circuit breaker. Whether it's SHACKLE for supervised workflows or an automated solution for headless APIs, you need runtime protection.

Installation:

pip install git+https://github.com/Fame510/SHACKLE-PRO-.git

Open source (AGPLv3): https://github.com/Fame510/SHACKLE-PRO-

Happy to help with production deployment patterns or configuration questions.

---

Dante Bullock
Sovereign Logic
docspoc101@gmail.com

[abhinaykrupa]

@Fame510 — excellent point about production safety. You're right that crews need runtime protection. Here's how the bridge integrates these guardrails:

Current Safeguards

1. Budget Enforcement (Quota System)

We track operations per day (configurable, default 100/day). The MCP server returns quota status with every escalation:

{
  "used": 42,
  "remaining": 58,
  "reset_at": "2026-06-18T00:00:00Z",
  "limit": 100
}

How crews use it:

from crewai import Agent, Task, Crew

# Check quota before running expensive operations
response = mcp.call_tool("escalate_to_claude", {"request": "..."})
if response["quota"]["remaining"] < 10:
    log("Approaching quota limit; pause crew")

2. Loop Detection (Via Escalation Timeout)

We enforce hard timeout per escalation (default 300s). Crews can set wait_seconds:

# 5-minute hard limit prevents infinite retries
response = mcp.call_tool("escalate_to_claude", {
    "request": "...",
    "wait_seconds": 300  # Hard stop
})

3. Cancellation + Graceful Shutdown

When a crew detects a loop or timeout, it cancels:

# Cancel operation if it's taking too long
mcp.call_tool("cancel_operation", {
    "operation_id": op_id,
    "reason": "Exceeded crew SLA"
})
# Safe: returns immediately for queued, SIGTERM for executing

What We're Adding Next

To match SHACKLE's capability, we're prioritizing:

1. Per-Operation Metrics — Track tool calls, estimated spend, memory, CPU inside each escalation

   • Enable automated loop detection (detect 3+ repeat calls)
   • Return with every get_operation_status call

2. Loop Detection — Catch infinite retry patterns

   • Same tool invoked 3+ times with identical args
   • Same error thrown repeatedly

Example enhanced response:

{
  "operation_id": "...",
  "status": "executing",
  "progress": {...},
  "metrics": {
    "tool_calls": 12,
    "api_spend_estimate": 0.24,
    "memory_mb": 256,
    "cpu_percent": 18,
    "repeated_calls": {
      "dangerous_tool": 3
    }
  }
}

Production Deployment

• Supervised production (dashboards, admin panels) — Current timeout + quota + cancellation is solid
• Headless APIs (serverless, FastAPI) — Will add metrics + loop detection for automated circuit-breaking

---

This feedback from @Fame510 is exactly what we need for production maturity. We're adding the per-operation metrics + loop detection this week to match SHACKLE's safety model. Happy to collaborate on API design or integration patterns.

cc @abhinaykrupa — prioritizing this for Hermes production deployment.

[Fame510]

@abhinaykrupa — Great to see production safety getting prioritized!

The MCP bridge approach looks solid for CrewAI-specific deployments.

Key difference: SHACKLE operates at the interpreter level (litellm + BaseTool hooks), so it works across CrewAI, LangGraph, and AutoGen without framework-specific integration.

For teams running polyglot agent stacks (CrewAI for research + LangGraph for conversations), one decorator covers all frameworks.

Your quota system is perfect for headless MCP deployments. SHACKLE's HITL console is built for supervised workflows where humans are in the loop.

Different architectures, different use cases. Both needed.

If your Hermes production deployment needs cross-framework coverage or interactive HITL control during development/testing, happy to show how SHACKLE integrates alongside your MCP bridge.

For teams already using SHACKLE who want MCP bridge support, I'm open to discussing interop patterns.

Best,
Dante

[sunfishloop]

The gap you're describing is real — we hit it building production crews that need to execute code across frameworks. The Cloud-vs-local tradeoff is especially painful because it forces an architectural decision before you understand your actual patterns.

In practice (20+ agents across CrewAI, AutoGen, and LangGraph), we found that the boundary approach works best: sandboxed skill containers with declared deps + scoped filesystem + allow-list network — but crucially, the agents don't execute code directly. Instead, they invoke skills through a signed task wire format (JSON/slots) where the execution environment is a first-class concern of the protocol, not an afterthought of the framework.

This means a CrewAI agent can delegate a code task to an AutoGen agent without either framework owning the sandbox. We published the protocol and production setup at github.com/sunfishloop/sunfishloop — the cross-framework execution layer is one of the patterns we run daily.

[Fame510]

@sunfishloop — the sandboxed skill container approach with signed task wire format is exactly the topology we built SHACKLE for. Your protocol handles delegation and execution boundaries. The gap is what happens when a delegated task enters a cost loop or retry spiral **inside** the sandbox. 20+ agents across three frameworks daily is serious production footprint. What does your current loop detection look like at the wire format execution layer? We've seen that pattern fail silently until it compounds across delegations. Happy to show you how the Guard decorator integrates without touching your protocol. github.com/Fame510/SHACKLE-PRO-

…

On Wed, Jun 17, 2026, 9:07 PM WangChunyang ***@***.***> wrote: *sunfishloop* left a comment (crewAIInc/crewAI#6180) <#6180 (comment)> The gap you're describing is real — we hit it building production crews that need to execute code across frameworks. The Cloud-vs-local tradeoff is especially painful because it forces an architectural decision before you understand your actual patterns. In practice (20+ agents across CrewAI, AutoGen, and LangGraph), we found that the boundary approach works best: sandboxed skill containers with declared deps + scoped filesystem + allow-list network — but crucially, the agents don't execute code directly. Instead, they invoke skills through a signed task wire format (JSON/slots) where the execution environment is a first-class concern of the protocol, not an afterthought of the framework. This means a CrewAI agent can delegate a code task to an AutoGen agent without either framework owning the sandbox. We published the protocol and production setup at github.com/sunfishloop/sunfishloop — the cross-framework execution layer is one of the patterns we run daily. — Reply to this email directly, view it on GitHub <#6180?email_source=notifications&email_token=A5HJBAIFHDRINZ2WLLBHJYD5ANTJRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZTG44DOMRVG44KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4737872578>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5HJBAKIQIPFGQD44HL3CMD5ANTJRAVCNFSNUABFKJSXA33TNF2G64TZHM3TCMBWGAYTAOBYHNEXG43VMU5TINRXGQ2TKOJRG4YKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/A5HJBAKLYHFL7GI4EUZGQM35ANTJRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZTG44DOMRVG44KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/A5HJBALS2BTMPHYGUZOZNLD5ANTJRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZTG44DOMRVG44KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[Fame510]

@abhinaykrupa this is the documentation gap that causes production incidents. We learned this the hard way building SHACKLE.

The missing piece in every agent framework's execution docs: a pre-execution mediation layer. Documentation can tell you how to sandbox, but production needs a runtime mechanism that enforces the safety policy regardless of what the agent generates.

What production code execution actually needs:

Agent generates code → SHACKLE decide() → Allow/Review/Deny → Execute
                                         ↓
                                    Budget check
                                    Safety policy check  
                                    Audit log (Ed25519 signed)

Key properties we verified:

• Monotonic cost depletion — budget only decreases, never resets
• Transitive denial — if a tool is denied once in a session, all subsequent calls are denied
• Safe initialization — the guard starts in a known-safe state, not inheriting prior agent state

We built this as a standalone daemon that runs alongside any agent framework: https://github.com/Fame510/SHACKLE-PRO-

It would complement crewAI's execution docs as the runtime enforcement layer that makes the docs actually effective in production.