[FEATURE] Native deterministic guardrail to prevent infinite agent delegation and tool loops

Feature Area

Core functionality

Is your feature request related to a an existing bug? Please link it here.

Yes. One of the most expensive and frustrating failure modes in multi-agent Crews is the infinite loop.
Specifically:

1. The Delegation Ping-Pong: Agent A delegates a task to Agent B, but Agent B gets confused and delegates it back to Agent A.
2. The Tool Loop: An agent gets stuck calling the exact same tool (e.g., search_web("rust")) repeatedly because the LLM fails to realize it's looping.

Currently, these loops run indefinitely, burning thousands of dollars in LLM API credits before the user manually kills the process or hits a blind max_iter limit.

Describe the solution you'd like

I propose adding a Deterministic Trajectory Guardrail to CrewAI.

Instead of relying on the LLM to "notice" it's looping (which takes 1.5+ seconds and burns tokens) or using a blind max_iter counter (which kills valid 15-step workflows at step 11), we intercept the tool execution pipeline and deterministically hash the trajectory state: (agent_role, tool_name, canonical_arguments).

If the exact same trajectory repeats within a sliding window, the guardrail instantly raises an exception locally (in ~480ns), blocking the loop before the API call ever leaves the machine.

Describe alternatives you've considered

1. Prompt Engineering ("You are looping, please stop"): Fails because the context window gets polluted with the agent's own repeated errors, making it impossible for the LLM to self-correct.
2. max_iter limits: A blind budget. It doesn't detect redundancy, it just detects time.
3. Semantic Embeddings: Too slow. Running an embedding model on every tool call adds 10ms+ of latency and heavy dependencies. We need sub-microsecond, deterministic hashing.

Additional context

I have actually already built the core engine for this exact physics problem in Rust (called Microloop), which handles the nanosecond-level trajectory hashing. I also just opened a PR to integrate this exact logic natively into LiteLLM as a guardrail callback.

My Proposal for CrewAI:
I have a working Python prototype that wraps the Crew and intercepts the Agent's tool execution pipeline (catching both standard tool loops AND delegation ping-pongs).

Before I open a formal PR, I’d love the maintainers' feedback on:

1. Integration Point: Is there a specific internal hook or callback system in CrewAI 0.105.x that is preferred for intercepting tool execution, or is wrapping the Agent.execute_tool method the cleanest approach?
2. Location: Should this live in a new crewai/guardrails/ directory, or as an external integration package?

I am happy to write the code, the tests, and the documentation for this if the team is aligned on the approach. Let me know what you think!

Willingness to Contribute

Yes, I'd be happy to submit a pull request

Start by reading the CrewAI 0.105.x tool execution path, especially Agent.execute_tool, and compare it with the existing Python prototype and Microloop design linked in the issue. Confirm whether a callback hook or method wrapper is appropriate, decide between crewai/guardrails/ and an external package, and define tests for repeated tool calls and delegation ping-pong before implementing documentation and code.