Hey everyone! I've been absolutely loving CrewAI for the past few months—it's such a powerful framework for orchestrating these autonomous agents. I've built a few crews now, mostly for content brainstorming and customer support simulations, and the potential feels huge.
But I've hit a major snag with my latest project, and I'm wondering if anyone else has run into this or has a workaround. I built a "Customer Inquiry Resolver" crew that's designed to be chat-based. The idea is it mimics a live chat support flow: the user asks a question, the crew (with a Researcher and a Support Agent role) digs into a knowledge base and provides a step-by-step, contextual response.
Here's the frustrating part: **the crew seems to have a memory span of about three messages.** After that, it completely forgets the entire conversation history. The context evaporates. For example:
* Message 1: User asks about resetting a password.
* Message 2: Crew asks for the user's account type (e.g., "Are you on a Team or Pro plan?").
* Message 3: User provides the info ("Team plan").
* Message 4: Crew's response completely ignores the provided account type and gives a generic, non-specific answer, as if the previous three exchanges never happened.
It feels like the `llm` or `agent` executor is not passing the full conversation history back into the prompt on subsequent interactions. I'm using a simple sequential process with `kickoff()` and then `crew.kickoff(input="next user message")` in a loop.
My setup is pretty standard:
- I'm using `ChatOpenAI` (gpt-4-turbo) as the LLM.
- Both agents have `memory=True` set.
- The tasks have `context` defined to pass info between agents, but that's for intra-crew execution, not for remembering the user's chat history across kicks.
- I've tried tweaking the `max_iter` and `max_rpm` but that doesn't seem related.
Has anyone else built a truly conversational, multi-turn crew successfully? I'm starting to wonder if I need to manually manage the conversation history as a variable and inject it into each `kickoff(input=...)` call, or perhaps leverage the `CacheHandler` differently? Or is this a known limitation where the "memory" is more for a single task execution chain, not for a persistent chat session?
I'd be so grateful for any insights or shared experiences. The promise of a long-running, context-aware support agent is so cool, but this memory hurdle is a big one to clear.
—Aurora
don't spam bro