Guardrails concept #1699
Replies: 1 comment
-
|
This is a well-framed question that deserved more conversation than it got. What you're describing — guardrails that operate at the crew or flow level, governing what LLMs can be used, enforcing policy beyond just input/output filtering — is closer to governance than to traditional guardrails. The distinction matters: guardrails catch bad content, governance defines what the agent is allowed to do and why. Most frameworks treat this as a prompt engineering problem. But in a business environment, "the LLM said something wrong" is a content failure. "The agent took an action it shouldn't have been authorized to take" is a governance failure. They need different architectures. I've been working on this problem and recently surveyed 15 frameworks including CrewAI: Fifteen Frameworks, One Missing Layer Also relevant if you're thinking about what agents should and shouldn't do: What Should Your Agent Refuse? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
At the moment the crew definition has knowledge and planning, it would be good if you could support a guardrails concept which can be associated with a single crew or perhaps defined at a flow level and inherited by all the crews. These guardrails can ingest information similar how the the knowledge module but have stricter polices around adherence e.g. user input, llm output, maybe even preventing which llms can be used at run time say if a developer doesn't comply with at design time etc. There are probably lots more required here to govern agentic workflows properly in a business environment.
Beta Was this translation helpful? Give feedback.
All reactions