Building a multi-agent marketing campaign app using AGNTCY’s Internet of Agents

Artificial Intelligence (AI) agents are autonomous applications capable of performing novel tasks by leveraging tools, reasoning, and user interactions—such as composing emails or analyzing meeting transcripts. These agents are being developed by teams worldwide to tackle a wide range of challenges and have the potential to save developers a significant amount of time, but too often, they operate in isolation.  

Each agent may be built with a different tech stack or framework, leading to 'walled gardens' that don’t seamlessly interoperate. For developers, this means reinventing the wheel—like rebuilding a meeting summarizer or email publisher from scratch. That duplication wastes time and, in fast-paced environments, directly delays delivery and reduces business impact. 

Imagine you're building an app to automate marketing emails or analyze meeting recordings. Why develop a new content writer or meeting summarizer when someone has already perfected it? Reusing existing agents will accelerate development, reduce technical debt, and deliver value to customers faster. But the real challenge isn't just discovering these agents—it's enabling them to collaborate, regardless of who built them or what platform they run on. 

That’s where AGNTCY comes in. AGNTCY provides the glue to connect diverse AI agents into cohesive workflows, allowing developers to leverage what's already out there. In this post, we’ll explain how AGNTCY’s components work and show their value through a sample multi-agent application.

Automating a marketing campaign 

Let’s walk through a sample application that showcases how multiple AI agents can collaborate to automate a simple but common business process: running a marketing email campaign. This application handles email composition, review, and delivery through a set of orchestrated agents. 

Agents involved 

• Mail composer agent: Generates marketing email content based on structured input parameters (e.g., campaign goals, audience segment, tone).
• Email reviewer agent: Analyzes the draft email to detect issues, ensure compliance with brand and regulatory standards, and suggest improvements. 

Let’s look at the key challenges—and how AGNTCY’s Internet of Agents addresses them: (1) discovering the right agents, and (2) enabling agents to work together seamlessly. 

Problem 1: Agent discovery 

Composing, reviewing, and sending an email may sound straightforward—but finding agents that can do these tasks easily is not. Developers often need to hunt through: 

• Hosted APIs scattered across the web
• Open source projects on GitHub
• Containerized agents in Docker registries
• Standalone binaries or Python scripts buried in documentation 

Each agent has a different interface, dependency set, and invocation method, making integration painful and slow. 

Solution: Streamlined agent discovery via the Agent Directory 

AGNTCY’s Agent Directory solves this by providing a centralized, searchable catalog of available agents—both internal and external to an organization. 

For this sample application, we assume two agents are available in our organization’s Agent Directory: 

• The mail composer agent is registered as a hosted service.
• The email reviewer agent is an open source model implemented using the LlamaIndex framework and available via GitHub. 

Each agent published in the directory comes with an agent manifest—a machine-readable JSON file describing the agent’s functionality, invocation method, input/output schema, dependencies, and compatibility metadata. This reduces search effort and supports reuse of existing agents. We need to retrieve the agent manifests for the agents from the Agent Directory. 

The mail composer’s manifest also contains an Agent Connect Protocol (ACP) specification that indicates the agent’s ACP compatibility, provides an end point URL, input format, framework, and other specifications. The email reviewer’s manifest specifies its source code location and requirements, and it shows it was built in LlamaIndex framework. 

Here’s a key excerpt from the mail composer agent’s manifest (full code available here.) 

1. Metadata: Identifies the agent. 

"metadata": { "name": "org.agntcy.mailcomposer", "version": "0.0.1", "description": "Compose email for campaigns" }  

2. Capabilities: Defines the agent’s features. 

"capabilities": { "threads": false, "interrupts": false, "callbacks": false }  

3. Message input: Specifies the required message structure. 

"input": { "$defs": { "Message": { "properties": { "type": {}, "content": {} }, "required": ["type", "content"] } } }  

Example: 

"input": {
  "$defs": {
    "Message": {
      "properties": {
        "type": 

{
          "$ref": "#/$defs/Type",
          "description": "indicates the originator of the message, a human or an assistant"
        },
        "content": {
          "description": "the content of the message",
          "title": "Content",
          "type": "string"
        }
      },
      "required": [
        "type",
        "content"
      ],
      "title": "Message",
      "type": "object"
    },
    "Type": {
      "enum": [
        "human",
        "assistant",
        "ai"
      ],
      "title": "Type",
      "type": "string"
    }
  },
  "properties": {
    "messages": {
      "anyOf": [
        {
          "items": {
            "$ref": "#/$defs/Message"
          },
          "type": "array"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "title": "Messages"
    },
    "is_completed": {
      "anyOf": [
        {
          "type": "boolean"
        },
        {
          "type": "null"
        }
      ],
      "default": null,
      "title": "Is Completed"
    }
  },
  "title": "AgentState",
  "type": "object"
}, 

4. Message output: Defines the message format for output. 

"output": { "$defs": { "Message": { "properties": { "type": {}, "content": {} }, "required": ["type", "content"] } } }  

Example: 

"output": {
      "$defs": {
        "Message": {
          "properties": {
            "type": {
              "$ref": "#/$defs/Type",
              "description": "indicates the originator of the message, a human or an assistant"
            },
            "content": {
              "description": "the content of the message",
              "title": "Content",
              "type": "string"
            }
          },
          "required": [
            "type",
            "content"
          ],
          "title": "Message",
          "type": "object"
        },
        "Type": {
          "enum": [
            "human",
            "assistant",
            "ai"
          ],
          "title": "Type",
          "type": "string"
        }
      },
      "properties": {
        "messages": {
          "anyOf": [
            {
              "items": {
                "$ref": "#/$defs/Message"
              },
              "type": "array"
            },
            {
              "type": "null"
            }
          ],
          "default": null,
          "title": "Messages"
        },
        "is_completed": {
          "anyOf": [
            {
              "type": "boolean"
            },
            {
              "type": "null"
            }
          ],
          "default": null,
          "title": "Is Completed"
        },
        "final_email": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "default": null,
          "description": "Final email produced by the mail composer",
          "title": "Final Email"
        }
      },
      "title": "OutputState",
      "type": "object"
    },

5. Final email output: Specifies the final email produced. 

"final_email": { "type": "string", "description": "Final email generated" }  

6. Config schema: Lists configuration options. 

"config": { "properties": { "test": { "type": "boolean" } }, "required": ["test"] }  

7. Deployment options: Describes how the agent is deployed. 

"deployment": { "deployment_options": [{ "type": "remote_service", "protocol": { "type": "ACP", "url": "http://example.com", "agent_id": "id" } }] }  

8. Environment variables: Lists environment variables needed. 

"env_vars": [ { "name": "AZURE_OPENAI_API_KEY", "desc": "Azure key for OpenAI service" }, { "name": "AZURE_OPENAI_ENDPOINT", "desc": "Azure endpoint" } ] 

With this information, developers can quickly gather the specifications necessary to integrate them into their workflows—without needing to manually replicate functionality. 

Problem 2: Enabling agent communication 

While finding the right agents is key, enabling seamless collaboration is challenging. The mail composer agent runs as a remote service, while the email reviewer agent must be hosted locally and is built on a different framework (LlamaIndex). These differences in deployment and framework complicate data sharing, leading to manual effort, delays, and fragmented workflows. Without a standardized communication method, the agents cannot integrate smoothly. 

Solution: Standardized agent interaction 

The Agent Connect Protocol (ACP) SDK solves this problem by enabling both agents to seamlessly communicate within a LangGraph workflow—a graph-based framework that allows agents to exchange data as they progress through the workflow. ACP facilitates the integration of agents regardless of where they’re hosted or which framework they use. 

Below, we instantiate two ACP nodes—one for each agent: 

 # Instantiate the local ACP node for the remote agent
    acp_mailcomposer = ACPNode(
        name="mailcomposer",
        agent_id=MAILCOMPOSER_AGENT_ID,
        client_config=MAILCOMPOSER_CLIENT_CONFIG,
        input_path="mailcomposer_state.input",
        input_type=mailcomposer.InputSchema,
        output_path="mailcomposer_state.output",
        output_type=mailcomposer.OutputSchema
    )
    acp_email_reviewer = ACPNode(
        name="email_reviewer",
        agent_id=EMAIL_REVIEWER_AGENT_ID,
        client_config=EMAIL_REVIEWER_CONFIG,
        input_path="email_reviewer_state.input",
        input_type=email_reviewer.InputSchema,
        output_path="email_reviewer_state.output",
        output_type=email_reviewer.OutputSchema
    )  

By establishing these nodes, we connect the mail composer and email reviewer agents, enabling them to communicate via ACP in the LangGraph workflow. 

Data transformation with IO mapper agent 

Agents often produce and consume data in different formats, making direct integration difficult. For example, the mail composer agent outputs data with fields like final_email and nested messages, while the email reviewer agent expects a flatter structure with separate type, content, and is_completed fields. Although the underlying data is similar, these structural differences—along with the use of different frameworks—create friction. Normally, developers must handle these conversions manually. 

The IO mapper agent solves this by automatically transforming data between formats using information from each agent’s manifest. This enables agents with incompatible structures to work together seamlessly. 

• Mail Composer Agent Manifest: View Manifest

• Email Reviewer Agent Manifest: View Manifest

Here’s how the IO mapper agent is integrated into the workflow: 

 ## Add conditional edge between mailcomposer and either send_email or END, adding io_mappers between them
    add_io_mapped_conditional_edge(
        sg,
        start=acp_mailcomposer,
        path=check_final_email,
        iomapper_config_map={
            "done": {
                "end": acp_email_reviewer,
                "metadata": {
                    "input_fields": ["mailcomposer_state.output.final_email", "target_audience"]
                }
            },
            "user": {
                "end": "prepare_output",
                "metadata": None
            }
        },
        llm=llm
    )

The IO mapper ensures that the output of the mail composer agent is appropriately formatted for the email reviewer agent’s input. In this case, the agent transforms the final email content and associated metadata into the required structure. 

Sending the email: API Bridge Agent 

After the email is reviewed, the next step is delivery. However, sending an email via a service like Twilio SendGrid typically requires writing custom integration code—handling authentication, formatting the payload, and managing the API call. 

The API Bridge Agent simplifies this by acting as a connector. It takes a high-level "send" command and translates it into the correct API call for Twilio SendGrid, handling the complexity behind the scenes. Without it, developers would need to manually implement and maintain this integration logic themselves. 

The API Bridge Agent node is instantiated like this: 

 # Instantiate APIBridge Agent Node
    sendgrid_api_key = os.environ.get("SENDGRID_API_KEY", None)
    if sendgrid_api_key is None:
        raise ValueError("SENDGRID_API_KEY environment variable is not set")
    send_email = APIBridgeAgentNode(
        name="sendgrid",
        input_path="sendgrid_state.input",
        output_path="sendgrid_state.output",
        service_api_key=sendgrid_api_key,
        hostname=SENDGRID_HOST, // Note: SENDGRID_HOST is where the API Bridge Agent hosted in this case.
        service_name="sendgrid"
    )

This API Bridge Agent uses SendGrid’s API to send the final email. It converts the processed data into the appropriate API request format, making it easy to trigger email delivery directly from the agent workflow. 

Build and launch the workflow 

Once the agents are integrated and all nodes are configured, the next step is to launch the entire marketing campaign workflow. Here’s how you can get started (Detailed link): 

1. Clone the AGNTCY GitHub repositories: Download the Agent Workflow Server and Agent Workflow Server Manager repositories.
2. Start the servers: Launch both the Agent Workflow Server and the API Bridge Agent.
3. Run the marketing campaign app: Once the setup is complete, you can execute the workflow, which will automate the process of composing, reviewing, and sending marketing emails.
4. At the core of this system is ACP and the Agent Workflow Server, which together enable a smooth, streamlined pipeline for email creation and delivery. The system configures the email reviewer agent with necessary settings (like an API key), deploys it locally using ACP, and ensures it communicates seamlessly with the mail composer agent.

AGNTCY’s components provide developers with a modular and efficient approach to building sophisticated multi-agentic systems. Whether you're working on marketing automation, code review tools, or other AI-driven solutions, this agent-based architecture delivers unmatched flexibility and scalability. 

By enabling seamless communication between agents and promoting the reuse of existing functionality, AGNTCY accelerates development timelines and boosts overall productivity. 

Below are a few of the components used in the example above, along with links to help you explore further: 

• Agent directory 
  A searchable registry for discovering and accessing publicly available or internal agents, eliminating the need to manually track or replicate functionality.
  • https://github.com/agntcy/dir  
• Agent Connect Protocol (ACP) 
  A communication layer that lets agents from different environments talk to each other. It supports data exchange, authentication, dynamic configuration, output chaining, context passing, and error handling.
  • https://github.com/agntcy/acp-spec  
• Agent workflow server 
  A runtime for deploying and orchestrating agents in real time. It allows developers to define and execute multi-agent workflows with minimal overhead.
  • https://github.com/agntcy/workflow-srv-mgr
  • https://github.com/agntcy/workflow-srv
• IO mapper agent 
  A translator agent that adapts outputs from one agent to match the expected inputs of another. It can handle tasks like data reformatting, summarization, translation, or field mapping.
  • https://github.com/agntcy/iomapper-agnt
• API Bridge Agent 
  An interface agent that converts natural language requests into API calls (and back), using OpenAPI specifications to dynamically choose and invoke third-party APIs.
  • https://github.com/agntcy/api-bridge-agnt 

Ready to dive in? Our Getting Started Guide walks you through each step. Want to explore how the sample app ticks? Watch our code walkthrough video for an in-depth look!   

Suggested resources 

• The 4 phases for successful development of multi-agent software
• Marketing Campaign Sample Apps GitHub
• AGNTCY GitHub
• Code walkthrough video