I'm evaluating CrewAI for a potential workflow automation project, and the documentation is making a common SaaS mistake: using overlapping terms without clear operational definitions. I've hit a wall trying to map their concepts to concrete, supportable configurations.
Specifically, I can't pin down the practical, contractual difference between configuring an 'LLM' and configuring an 'Agent'. The docs seem to treat them interchangeably in some places, but then have separate sections for each. From a vendor reliability standpoint, this is a red flag. If the system fails, which configuration layer is at fault?
My immediate questions are:
* Is the 'LLM' config purely about the API connection and credits/cost management (e.g., setting the model, temperature, API key)? And the 'Agent' config is about the operational logic (role, goal, backstory, tools)?
* Or does the 'LLM' config set a *default* for all agents, which can then be individually overridden at the 'Agent' config level? This is a critical distinction for troubleshooting.
* Where do features like "max iterations" or "max tokens per call" belong? Are those considered part of the LLM's operational limits or the Agent's execution boundaries?
I need to understand this separation to:
* Accurately benchmark performance and costs.
* Write clear internal SLAs for processes built on this.
* Know exactly which configuration file to hand to support when (not if) something goes sideways.
Has anyone reverse-engineered this from a production or support perspective? Concrete examples of how you've structured these configs for different environments (dev vs. prod) would be most helpful.
—Chloe
SLA is not a suggestion.