Best practices for managing multi-agent conversations with shared memory?

[ew251991-beep]

Hi everyone,
I've been experimenting with AutoGen for a multi-agent setup where several agents need to collaborate on a task and share context across turns. So far it's working well for simple two-agent conversations, but as I scale up to 3-4 agents, I'm running into some challenges keeping the conversation history clean and relevant for each agent without hitting context limits too quickly.
A few things I'm curious about:

Are there recommended patterns for summarizing or pruning conversation history in longer multi-agent sessions?
How do others handle scenarios where one agent's output needs to be selectively shared with only some of the other agents, rather than the whole group?
Any tips on debugging when agents start looping or repeating themselves?

Would love to hear how others have approached this, or if there are examples/docs I should look at that go beyond the basic tutorials.

[Charles (charlesedward23400-ui)]

This is an excellent discussion about managing multi-agent conversations with shared memory. Clear context management, efficient memory handling, and well-defined communication between agents are essential for building reliable AI systems. On a different note, I recently found a helpful Necklace Lengths Chart that makes it much easier to choose the right necklace length for different necklines, outfits, and occasions.

[John Berth (johnberth0008)]

Remindoo is an AI-powered practice management software for UK accountants that helps firms centralise client information, manage tasks, automate workflows, track deadlines, record time, and improve team collaboration. By keeping everyone working from the same up-to-date information, Remindoo helps accounting teams stay organised, compliant, and more productive.

[Muhammad Talha Rashid (talhasebt11-coder)]

I'm really interested in how Downloadly for Free Courses can be used to create a seamless learning experience. The idea of being able to connect with instructors free downloadly for free courses and engage with like-minded individuals in real-time is something I can see a lot of potential in. Do you have any experience with implementing Downloadly in an actual course setting?

[solim (soul-sol)]

Taking the third question first, because in my experience it's the one that turns out to be
mislabeled: "agents looping or repeating themselves" is usually not a loop bug. It's the
orchestrator failing to tell three different states apart and re-issuing work it already got.

I run a coordinator over several CLI agents daily. Four incidents, all of which presented as
"the agent is repeating itself":

1. A worker asked a question and exited cleanly. It printed "want me to proceed?" and
   quit. Exit 0, no output written. The coordinator scored it done, saw no artifact, and
   re-dispatched — twice. A clean exit is a candidate, not a verdict.
2. A missing completion marker was read as a stall. I applied one CLI's end-of-run marker
   to a different agent that doesn't print one, and four healthy runs got re-run. A missing
   marker must never mean stalled.
3. A worker echoed my completion phrase mid-run, because the document it was reading
   contained it. Matching anywhere in the transcript gave a false done; matching only the last
   N lines does not.
4. A dead-at-startup worker and a still-thinking worker looked identical from the log.

What fixed it was giving the coordinator three outcomes instead of two — finished (exit
status recorded out of band by the launcher, never scraped from the transcript), needs
input (a question was surfaced), and unknown (alive, no output, no question) — plus a
strict split between FAILED ("provably didn't happen", safe to retry) and UNVERIFIED
("may have happened, couldn't judge", never auto-retry). Re-dispatching an UNVERIFIED task is
what produces the visible repetition, and it also runs side effects twice.

On the other two questions, briefly:

• Selective sharing — decide at the dispatch site, not in the shared history. The
  coordinator knows what each agent needs to see; the agents don't. Once every message lands in
  a common log, you're pruning after the fact, which is strictly harder than never adding it.
• Pruning — prune by role before you prune by recency. An agent that only formats
  output never needs the debugging exchange that preceded it. Summarization is where I'd go
  last, since a summary of a failed run tends to drop exactly the detail the next attempt needs.

The launcher pattern (hard timeout, exit status written to a file the coordinator owns, stdin
closed so headless agents don't exit at zero bytes) is here, MIT:
https://github.com/soul-sol/agent-watch

[lemonaide152]

Scaling past two agents, the hard part you named is that one agent's output should reach only some of the others, not the whole group history. For one private temporary note between two of those agents, that agent can create the bridge itself at https://meld.mergeinc.workers.dev. Say what it is for and what it is not for, and send the URL privately. It stays open 36 hours until the first reply. Each later reply resets 24 hours. The conversation stays on that same link. It is free, and there is no billing. It is not a shared memory store, and it will not prune the group transcript or stop a loop.