Before building a multi-agent system—before you touch a platform, prototype an agent, or start wiring up automations—there’s a phase most teams skip or misunderstand: scoping.

This post kicks off a new series where I walk through the early-phase planning that has to happen before a full-scale MAS (multi-agent system) can be responsibly developed and deployed—especially in real-world, high-stakes environments.

This isn’t about hands-on engineering or building yet. It’s about asking the right questions up front, so that when it's time to build, you’re not scrambling to fix things that could’ve been anticipated.

Where the idea for this blog series started

I started thinking more deeply about writing this series after a great conversation with a stakeholder around cross-continent MAS deployment. The question that sparked it was about budgeting: how much does it actually cost to build and maintain a full-scale, multi-agent system?

That question quickly opened up a deeper one: how do you even know what to build?

That led us to infrastructure—where will the agents live? Is cloud fast enough for this? What if the system needs to respond in near real-time? What if the data is highly sensitive, subject to regulations like GDPR or SOX? Will some agents need to run locally? And if so, what kind of hardware or networking environment do they need? If this is cross-continent, how do we handle coordination and data handling across regions?

What this series is (and isn’t)

This series is part journal, part case study, and part open invitation to anyone who wants to understand MAS from a system-level perspective—not just a platform or product view.

It’s not a technical tutorial. I’m not assuming someone is just dragging agents onto a visual canvas or relying entirely on tools like Bedrock or LangChain. Instead, we’ll be looking at what happens when an organization wants to build a complete MAS—a system with custom agents, layered infrastructure, and long-term coordination across multiple zones and environments. Some components might use agent platforms, but the system is not defined by them.

These posts are meant to walk through real planning decisions—what to consider, what to budget for, what risks exist—and how to scope those decisions clearly and honestly from day one.

Why scope matters more than tools

A lot of teams want to move fast. They assume they’ll “just connect the cloud,” or “drop an agent into the workflow” and everything else will sort itself out.

But that skips over realities like:

Latency between regions
Firewalls blocking agent communication
Data access boundaries for regulated content
Departmental silos or approvals that slow integration

Even major companies like Amazon design their systems using availability zones, keeping data and processing power close to where it's needed. That same mindset applies to MAS: if you want agents collaborating across continents or even across departments, they need more than LLM prompts—they need infrastructure.

Scoping isn’t about slowing down the build. It’s about making sure there’s actually a path to build on.

The first scenario: Hybrid MAS for internal workflows

To kick off this series, we’ll start with a mock, hybrid MAS deployment inside a global finance enterprise. This system is designed to automate internal reporting—each month, departments need to generate consistent reports using data from various sources. Some of that data lives in AWS, some lives on-prem, behind corporate firewalls. Agents will need to collaborate across that divide while complying with GDPR, SOX, and internal audit requirements.

We’ll explore:

Where the agents should live (cloud, on-prem, or both)
How they’ll communicate across boundaries
What kinds of permissions and audit trails are required
How episodic MAS design differs from persistent agent deployment

This scenario was a deliberate starting point. I didn’t want to begin with a cloud-only MAS, because while those are easier to explain, they’re not representative of most real-world environments. The hybrid model allows us to talk about local deployment, cross-system coordination, and the kinds of tradeoffs many enterprises have to face.

MAS types we’ll be exploring

As the series continues, we’ll walk through additional mock scenarios. Each one is designed to reveal different challenges in early MAS planning. These include:

Hybrid MAS for internal enterprise use (the one we’re starting with)
Persistent MAS under strict compliance (e.g., healthcare systems governed by HIPAA or regional privacy laws)
Edge-deployed MAS with fallback design (e.g., logistics or maritime systems with intermittent connectivity)

Each scenario will bring its own set of scoping issues—technical, legal, and operational. And with each one, we’ll look at the planning conversations that need to happen before development starts.

Follow along—or jump in

This series is for anyone trying to think clearly about what it means to scope, fund, or build a multi-agent system that works outside the lab. If you’re a decision-maker, advisor, or technologist who’s being asked to “stand up something agentic,” this series can give you language and structure to make smarter, earlier decisions.

In the next post, we’ll begin walking through the hybrid MAS scenario and start breaking down the infrastructure requirements.

If you have questions as you read, feel free to comment or reach out to me through my website. I’ll continue weaving insights from those conversations into future blog posts.

Scoping Cross-Continent Multi-Agent Systems: Post 1