When Intuitive Design Pushes Back: Early Lessons from a Google Drive–Triggered Multi-Agent System

In this post, I’m sharing a challenge I’ve run into while building a multi-agent system across platforms—and how I worked through it. It’s a real-world example of what happens when intuitive design meets the limits of platform integration. My goal is to help system architects and stakeholders spot these friction points early—so they can make smarter decisions, save time, and build agentic workflows with more clarity.

The system, called CASE (Citation Analysis & Summary Extraction), was designed for a university leader who wanted a better way to work with exported citation lists from Zotero. His current process was clunky: export the data, try to make sense of what each citation linked to, and manually review whether the links were even usable. So I set out to design a lightweight, scalable agent system that could clean up and streamline all of that.

If you’ve followed my work before, you know I’ve built large-scale multi-agent systems capable of operating across institutions, detect real-time threats, analyzing collections of historical government documents, or handle adversarial behavior. This wasn’t that. This was supposed to be straightforward: a small system to help one person with a real, focused problem.

But as I’ve learned (again), nothing is easy—especially when you're working across platforms.

The Setup

Here’s the basic idea:

• A folder in Google Drive acts as the signal—anytime a new document is added, the system gets to work.

• Agent 1 is a watcher: it monitors the Drive folder and detects when a new document has arrived (PDF, Word, text, Zotero export—it doesn’t matter).

• From there, additional agents will eventually jump in: to extract citations, check URLs, and generate usable summaries or insights, even disagree and resolve conflicting perspectives.

I’ve written more about the full system in this blog post, but this particular phase reminded me how easy it is to underestimate real-world complexity—even in “small” builds.

Start With the Signal

The person testing this system works in a university setting and uses Google Workspace daily. However, I chose to build the agents in PythonAnywhere for now—because it’s lightweight, accessible, and perfect for early testing. I made that decision knowing it could later be scaled to Google Cloud if he wants to make this a permanent part of his personal workflow (or if his organization adopts it more broadly). Having it run natively within the Google ecosystem will feel natural.

And that’s where I first felt tension.

Though I didn’t want to build the entire system inside Google Cloud, I still needed access to Google’s APIs, so an agent could listen for new files in a Drive folder. That meant I had to pair PythonAnywhere, where the agents live, with a core Google product. It’s a little like getting Apple and Android devices to cooperate. It’s not impossible—but you feel the resistance. Especially in multi-agent systems, that resistance gets amplified. The agents feel it. You feel it. Everything just becomes slightly more fragile or unstable.

Designing for the Handoff

What helps me break through challenges like this is by not building out a full agent roster—its focusing on the signal. Instead of trying to wire the whole thing at once, I build the core interaction first:

• The Google Drive folder

• The monitoring agent (to watch the folder)

• The basic API configuration that let the two talk

Once I could confirm the watcher agent saw the folder, checked for new files, and responded—I knew I had the handoff functioning. Everything else could be plugged in from there.

This lines up with my usual approach: go → complete → handoff. Whether it’s a human process or a machine one, I believe the foundation of a well architecture multi-agent system must prove those three steps work:

• Go → The Google Drive folder: a live signal source with real-world activity

• Complete → The watcher agent: monitors the folder, detects changes, and triggers a response

• Handoff → The API connection: cleanly passes control to the rest of the system

Once those three steps work, I know the system has a spine. Everything else plugs into that.

You might ask: “But didn’t you still have to connect Google to PythonAnywhere? Doesn’t that just move the problem instead of solving it?”

That’s a fair question. The tension doesn’t disappear—it gets managed strategically.

My focus wasn’t trying to keep two divergent ecosystems in perfect sync; I just needed the watcher agent to reliably catch the signal from the Drive folder.

It’s kind of like the old TV setups where you’d run a coaxial cable from the wall to a converter box—not elegant, but once the signal made it to the box, everything else worked fine. That’s what I designed for: the handoff. Because once the watcher agent sees the file, everything else happens on the other side of that signal, in the environment I control.

That’s a key way I move past platform friction: by designing clean handoffs, not trying to unify everything upfront.

Now, you might wonder—does that first signal really make it easier? After all, the system still has to reconnect with Google later, especially if the final output (like a written response or summary) needs to land in a Google Doc.

That is true. However, the signal doesn’t eliminate friction. But it isolates it. And that’s what makes it easier to manage. As simple as it may sound, getting that initial signal stable gives me something far more valuable: control over the timing and shape of that re-connecting back into Google Drive later in the agentic flow.

When you’ve got the watcher agent effectively listening for incoming documents, and the rest of the agents are interacting cleanly within your own environment, you create a controlled middle space. Agent-to-agent communication is smooth. Agents can reason, verify, and format outputs. And when it’s time to plug back into the Google ecosystem—for example, to write into a doc—you’re doing it from a known state. Let me quickly explain what I mean by a “known state” in the context of this multi-agent system.

When I talk about the system being in a known state, I don’t mean the moment it first spotted the file in Google Drive. I mean the point after the agents have done their work—read the file, talked to each other, and determined the next step—like writing into a Google Doc. By then, things are calm and stable. The system knows what it’s trying to do, and it’s ready to send that response back into the Google Doc.

It’s kind of like testing the gears on a bike. If you try to shift gears while the bike is standing still, it’s clunky. You can’t really tell if the gear shifter worked. But when the bike is already moving—smoothly, at a steady pace—you can shift gears cleanly. You hear the click, feel the change, and know it held. That’s what this early-stage setup gives you: motion, rhythm, and a clearer path to shift back into Google.

Would I suggest resolving tension like this in a full-scale, institutional multi-agent system?

That depends. For prototyping agentic workflows or systems, absolutely—this kind of setup is ideal.

On the other-hand, it depends on the depth of experience the person architecting the system has. Because at a certain level, you’re not just dealing with integrations and APIs—you’re up against something deeper I often speak about known as abstract constraints.

I won’t go too deep into that here, but in short, an abstract constraint is what you hit when a system technically works, but no longer supports the level of intelligence or control you're trying to build into it. You’re not getting an error message. You're just not getting traction. The system wasn’t built to do what you’re asking it to do—and it won’t always tell you why. That’s when people start to reach for workarounds.

Sometimes, those workarounds are good. They’re thoughtful, strategic, and stable. But other times, you spend more energy sustaining the workaround than advancing the system. And in multi-agent systems—where timing, handoffs, and coordination really matter—that can quietly become a liability.

I’ve spent a lot of time exploring and building agentic systems across different platforms—Google Cloud, PythonAnywhere, Render, FlowFuse, AWS to name a few. After a while, you start to feel the limitations of each one. You get used to the small frictions, the things that work beautifully, and the things that quietly don’t work. That familiarity doesn’t come from reading docs—it comes from pushing systems just far enough to see where they start to resist or buckle under the pressure of intuitive design.

And I say “limitations” here with care. I don’t mean the platform is weak—I mean you’ve simply reached the upper boundary of what it was designed to support. It’s an abstract constraint—a point where the system technically still works, but it no longer supports the level of intelligence, flexibility, or intuitive design you’re trying to build into it. You won’t always get a warning, or a red flag. Just a sense that your agents are dragging through molasses, or worse, quietly breaking in ways you can’t trace. That’s when you start reaching for workarounds.

And if you’ve worked at this level long enough, you start to factor that in—before you choose a platform. You ask: How far do I need to go with this system? How adaptable does it need to be? Is this platform going to hold, or will I be building against an invisible ceiling?

One thing I’ve learned: if your workaround is solving for an abstract constraint, you have to be honest about whether it’s truly stable. Because even if it works for a week or a month, there’s a real chance the underlying system will eventually recognize the strain and shut it down.

So I do use workarounds—but I evaluate them. I ask: Will this hold? Does it deliver comparable quality? And is it future-proof enough to rely on? If not, that’s when I stop patching and start thinking about shifting my focus architecturally.

Thinking about implementing AI or multi-agent systems? I’d love to help or answer any questions you have. I also offer workshops and strategy support—learn more on my website!