G2G: Building Microservice Architectures for AI Agents

In the evolving landscape of AI agent systems, the ability to compose specialized, independent units that can communicate seamlessly is crucial. This is where Guild-to-Guild (G2G) communication comes into play. In this post, we’ll explore what G2G is, why it’s essential for building scalable AI systems, and how it’s implemented in the Rustic AI framework.

What is G2G?

G2G communication is a messaging pattern that enables secure, structured communication between independent guilds in multi-agent systems. Think of it as a microservice architecture for AI agents.

In Rustic AI, a guild is a collection of agents that share a messaging bus, execution engine, and state. Each guild operates in its own namespace, with agents collaborating on tasks within that boundary. G2G extends this model by allowing guilds to communicate across boundaries while maintaining their independence.

The Core Problem

Without G2G, AI agent systems face several challenges:

• Tight coupling: All agents must exist within a single guild, creating monolithic architectures
• No clear boundaries: Difficult to separate concerns and responsibilities between different agent groups
• Limited scalability: Can’t distribute specialized guilds across different processes or machines
• Resource conflicts: All agents share the same memory space and execution context

G2G solves these problems by introducing a structured way for guilds to interact while maintaining their isolation.

Why Do We Need G2G?

The primary motivations for Guild-to-Guild communication are reusability and memory isolation. Let’s explore each of these benefits.

1. Reusability Through Service Composition

G2G enables you to build specialized guilds that can be reused across different applications, much like microservices in traditional software architecture.

Example scenario: Imagine you’ve built a Research Guild that specializes in gathering information from various sources. With G2G, you can:

• Use this Research Guild in multiple different applications
• Call it from a Data Analysis Guild in one project
• Use it with a Report Generation Guild in another project
• Avoid duplicating the research logic across projects

# Research Guild - Reusable across projects
research_guild = GuildBuilder(
    guild_name="research_guild",
    guild_description="Specialized research capabilities"
).set_gateway(GatewayConfig(
    input_formats=["research.Query"],
    output_formats=["research.Result"]
))

# Data Analysis Guild uses Research Guild 
analysis_guild = GuildBuilder(
    guild_name="analysis_guild",
    guild_description="Data analysis with research capabilities"
) 

This composition model means you can:

• Build once, use everywhere: Create specialized guilds and compose them into different workflows
• Define clear interfaces: Guilds communicate through well-defined message formats
• Evolve independently: Update a guild’s implementation without affecting consumers
• Mix and match: Combine different specialized guilds to create complex applications

2. Memory Isolation for Robustness

Memory isolation is crucial for building reliable multi-agent systems. G2G provides this through strict process and namespace boundaries.

This provides several critical benefits:

• Fault tolerance: If one guild crashes, others continue operating
• Resource protection: Each guild has its own memory space
• Security boundaries: Guilds cannot access each other’s internal state

3. Namespace Isolation

G2G architecture enforces strict memory isolation where each guild maintains exclusive ownership of its data. This creates a secure, single-source-of-truth model where guilds act as authoritative data owners and explicitly control what information is shared across boundaries.

4. Security Advantages

1. Blast Radius Containment If one guild is compromised, the attacker gains access only to that guild’s data. They cannot pivot to other guilds’ databases or memory.
2. Least Privilege Access Guilds receive only the minimum data needed for their function. A billing guild doesn’t need medical diagnoses; an analytics guild doesn’t need patient names.
3. Audit and Compliance All cross-guild data exchanges are message-based, creating a complete audit trail. This supports HIPAA, GDPR, SOC 2, and other compliance requirements.
4. Data Minimization By forcing explicit data sharing through messages, organizations naturally implement data minimization practices, reducing regulatory exposure.
5. Single Source Updates When patient data changes, only the Patient Records Guild updates its database. Other guilds request fresh data as needed, eliminating stale data issues.

5. Concurrent Access with Safety

Multiple guilds can safely query the same authoritative guild concurrently:

Each requesting guild receives only the data subset appropriate for its role, even when querying the same underlying patient record.

6. Scalability and Distribution

This allows you to:

• Scale specific capabilities: Add instances of high-demand guilds
• Geographic distribution: Place guilds closer to their data sources
• Resource optimization: Run compute-intensive guilds on GPU machines, lightweight guilds on CPU-only machines

Key Principles

Principle	Description	Security Benefit
Exclusive Ownership	Only the owning guild can read/write its data. No direct access from other guilds.	Prevents unauthorized data access and lateral movement
Controlled Disclosure	Guilds explicitly choose what data to include in responses	Minimizes data exposure; only necessary information crosses boundaries
Single Source of Truth	Each guild is the authoritative source for its domain data	Eliminates data duplication and synchronization issues
Message-Based Sharing	Data sharing occurs only through structured message exchanges	Creates audit trails and enables security monitoring
Format Contracts	Strict message format filtering at boundaries	Prevents unauthorized data formats from crossing boundaries

How G2G Works in Rustic AI

Rustic AI implements G2G through a well-designed architecture involving three core components: GatewayAgent, EnvoyAgent, and a shared namespace.

Architecture Overview

The G2G architecture uses a shared organization namespace that exists outside individual guild namespaces. Each guild has a unique inbox topic in this shared namespace where other guilds can send messages.

Organization Namespace (Shared)
├── guild_inbox:guild_a
├── guild_inbox:guild_b
└── guild_inbox:guild_c

Core Components

1. GatewayAgent - The Server Side

The GatewayAgent acts as the entry point for cross-guild requests. It’s the “server” that receives messages from other guilds and routes responses back to the originating guild.

from rustic_ai.core.guild.g2g import GatewayAgent, GatewayAgentProps
from rustic_ai.core.guild.builders import AgentBuilder

# Create a Gateway for your guild
gateway_spec = (
    AgentBuilder(GatewayAgent)
    .set_id("gateway")
    .set_name("Gateway")
    .set_description("Receives cross-guild requests")
    .set_properties(
        GatewayAgentProps(
            # Accept these message types as requests
            input_formats=["myapp.messages.Request"],
            # Forward these types back as responses
            output_formats=["myapp.messages.Response"],
            # Accept these types as returned results
            returned_formats=["myapp.messages.Result"],
        )
    )
    .build_spec()
)

guild._add_local_agent(gateway_spec)

The GatewayAgent handles three types of flows:

1. Inbound requests: Receives messages from external guilds and forwards them internally
2. Outbound responses: Catches internal responses and routes them back to the origin guild
3. Returned responses: Handles results coming back from guilds this guild called

2. EnvoyAgent - The Client Side

The EnvoyAgent is the “client” that sends messages to other guilds.

from rustic_ai.core.guild.g2g import EnvoyAgent, EnvoyAgentProps

# Create an Envoy to send requests to another guild
envoy_spec = (
    AgentBuilder(EnvoyAgent)
    .set_id("envoy_to_research")
    .set_name("Research Envoy")
    .set_description("Sends queries to Research Guild")
    .set_properties(
        EnvoyAgentProps(
            target_guild="research-guild-id",
            formats_to_forward=["research.Query"],
        )
    )
    .add_additional_topic("outbound_research")
    .build_spec()
)

guild._add_local_agent(envoy_spec)

When an agent publishes a message to the “outbound_research” topic, the EnvoyAgent:

1. Picks up the message
2. Adds the current guild to the origin_guild_stack
3. Forwards it to the Research Guild’s inbox

The test_saga_integration.py file can be used as a reference to build g2g.

3. Multi-Hop Routing with Origin Guild Stack

One of the most powerful features of G2G is support for multi-hop routing: Guild A → Guild B → Guild C → Guild B → Guild A.

This is enabled by the origin_guild_stack, which tracks the chain of guilds:

Automatic Session State Preservation (Saga Pattern)

One of the most elegant features of Rustic’s G2G implementation is automatic session state preservation.

This is implemented using the saga pattern:

1. EnvoyAgent saves session_state to guild state with a unique saga_id
2. The saga_id is stored in the origin_guild_stack alongside the guild ID
3. When the response returns, GatewayAgent restores the session_state from the saga_id

No manual correlation tracking needed!

Security Through Format Filtering

G2G provides security through strict message format filtering:

• Input format: Only accept these specific request types
• Output format: Only send back these response types
• Returned format: Only accept these return types

GatewayAgentProps(
    input_formats=["api.v1.AuthenticatedRequest"],
    output_formats=["api.v1.AuthorizedResponse"]
    returned_formats=["api.v1.Result"]
)

• View Rustic AI Gateway Agent for full code.

This ensures:

• Type safety: Only expected message types cross guild boundaries
• API versioning: Control which API versions are accepted
• Security boundaries: Prevent unauthorized message types from crossing guilds

Real-World Use Cases

Microservice-Style AI Applications

G2G communication enables you to build AI systems using microservice architecture principles, where each guild acts as an independent service with its own:

• Specialized purpose (customer service, data analysis, document processing, etc.)
• Independent tech stack (different LLMs, vector databases, tools)
• Isolated state and memory (no shared database or state)
• Explicit API contracts (defined message formats)
• Independent deployment (can scale, update, or restart guilds independently)

Conclusion

G2G communication is a powerful pattern for building scalable, maintainable AI agent systems. By providing reusability through service composition and memory isolation for robustness, G2G enables you to:

• Build specialized, reusable guilds that can be composed into complex applications
• Achieve true process isolation and fault tolerance
• Scale different capabilities independently
• Maintain clear boundaries and security between components

Rustic AI’s implementation of G2G, with its elegant architecture using GatewayAgent and EnvoyAgent, automatic session state preservation, and robust multi-hop routing, makes it straightforward to build microservice-style AI applications.

Whether you’re building a multi-LLM system, a data processing pipeline, or a complex enterprise AI application, G2G provides the foundation for creating systems that are both powerful and maintainable.