I decided to test out three different frameworks for building multi-agent systems at my company. Built the same setup using each one to see how they actually work.
The setup: One main coordinator agent plus two helper agents (one for email, one for chat). Pretty basic stuff.
What I found interesting: How each framework passes information between agents is totally different.
Google ADK dumps everything to the next agent. All chat history, all previous responses. It works but seems like overkill.
OpenAI SDK gives you options. You can either hand over full control to another agent or keep the main agent in charge while using others as helpers. This feels more flexible.
LangGraph lets you build whatever you want. Complete control over how agents connect and share data. More complex but way more customizable.
Real example that showed the problem: User wanted me to check 50 support tickets and send an email summary. The coordinator had to call the chat agent 50 times, then summarize everything for the email agent. With Google ADK, all 50 responses got passed to the email agent even though it only needed the final summary. That’s a lot of unnecessary data.
Turns out all three frameworks use the same basic approach under the hood. Agent-to-agent communication is just function calls. Nothing fancy.
Anyone else dealing with too much context getting passed around? What solutions are working for you?
Had the same performance headaches but found a different approach that worked great. Instead of filtering context after creating it, we went with lazy context generation - agents only compute what they’ll actually use. Your coordinator wouldn’t process all 50 tickets upfront. It processes them on-demand when downstream agents ask for something. Email agent needs ‘summarized ticket data’? That’s when the coordinator crunches those numbers. This works especially well with branching workflows where some agents might not even run. We built this using LangGraph’s conditional edges and saw huge improvements in speed and token usage. The key was treating context like a service instead of a data dump. Each agent exposes endpoints that others can query for specific info formats. Takes more planning upfront but scales way better than post-processing filters when you’ve got complex agent hierarchies.
Context bloat is exactly why I ditched agent frameworks for automation workflows. Those frameworks turn every interaction into a chat conversation, creating tons of unnecessary baggage.
I built mine with Latenode where each step gets only what it needs. For 50 tickets, the workflow:
Pulls tickets in batches
Extracts key data (not full text)
Builds summary incrementally
Sends final summary to email
No context passing between “agents” because there aren’t any. Just workflow steps that transform data and move on.
Latenode handles all the API calls and data transformations without writing context management code. You drag boxes on screen and connect them. Each box sees its input, produces output, done.
I built something similar last month for customer feedback. Instead of 3 agents passing full conversations around, it’s now 8 simple workflow steps. Each processes exactly what it needs. Way cleaner and costs 60% less.
You’re spot on about function calls. But workflows skip all that agent coordination overhead.
Your findings match exactly what I’ve seen across different projects. Context bloat gets exponentially worse once you move past basic use cases. We switched to agents explicitly requesting specific data chunks instead of getting everything by default. Rather than pushing all 50 ticket responses forward, the email agent queries back: ‘give me your executive summary and top 3 critical issues only.’ This pull-based approach slashed our API costs and cut processing latency. The coordinator becomes a data service that other agents query selectively. Different agent types have predictable context needs. Email agents almost never need full conversation histories, chat agents usually do. Build these assumptions into your architecture from the start - saves refactoring headaches later. You’re spot on about function calls. Most complexity in these frameworks is just orchestrating when and how those calls happen.
Been dealing with this exact issue for the past year. We built custom context filtering middleware that sits between our agents.
The middleware tracks what each agent actually needs and strips out everything else before passing data along. For your support ticket example, it’d grab those 50 responses, let the coordinator summarize them, then only pass the summary to the email agent.
We’re using LangGraph because of the flexibility you mentioned, but added our own layer with “context contracts” between agents. Each agent declares what data it needs and produces. The system enforces these contracts automatically.
Saved us about 40% on token usage and made everything way faster. Initial setup took some time but worth it when you’re processing hundreds of agent interactions daily.
One trick that helped - we logged all context transfers for a week to see what data actually gets used vs ignored. Eye opening stuff. Most agents only need like 20% of what they’re getting.
This video covers some advanced patterns for building these systems that might give you more ideas on handling context efficiently.
Honestly surprised more people don’t just use stateless agents with Redis caching. We store processed summaries in cache with expiry times so agents only fetch what’s actually needed. Your 50 ticket scenario? First agent processes and caches the summary, email agent grabs the cached version. No massive context dumps. Works with any framework - added it to our OpenAI setup in about 2 hours.
