ACP (Agent Communication Protocol)

[ismaelfaro]

[Updates]

Alpha spec draft is here! 👉 i-am-bee/discussions/497
Review the OpenAPI schema. Learn more from the docs.



ACP Workstreams are here! 👉 i-am-bee/discussions/488
We invite you to self-nominate, tag in collaborators, add comments and also participate in the our Community meeting April 8th.

---

[Original post]
We invite you to add there extra comments and also participate in the our Community meeting April 8th.

We started to discuss and implement an alpha version of ACP, based in solid ideas from MCP, and starting to connect points with other projects such as NLIP

Suggested topics:

1. Handling Stateful and Stateless Agents
2. Manifest-Based Agent Offline Discoverability
3. Evaluating Natural Language as an Agent Interface
4. Selecting/defining the optimal data encoding (REST, JSON-RPC, etc...)
5. Establish methods of Agent-to-Agent Communication (WebSockets, HTTP, Peer-to-Peer, ...)
6. Integrating Legacy Software with Agent Protocols
7. Streaming Data between Agents
8. Handling Request Cancellation and Ensuring Persistency
9. Agent and Tool Providers and MCP Servers: Roles and Responsibilities
10. Deployment Strategies for Agents
11. Configuration and Model Dependency Management for Agents

The discussion is open. 👋

[amitsides]

Agent should eventually be a microservice deployed to k8s that has access vectordb, MCP,graphdb, ontologies, tools (As json in elastic search) it can receive text or/embedding and should be able to embed it and query it, have identity based on prompts.

this is just an helm chart. agents can converse via any protocol.
you don't need to re-invent mlops for agnets to talk to each other, text/embedding.

I suggest Agent-Mesh: a single connection with embedding 2 embedding conversation, vector fight, infinite recursive loop of multiple models being able to send embedding and receive embedding, a new world of agent to agent embedding enrichment

[jpmorgenthal]

I'm a stickler for details. This incessent need for everything to be deployed to k8s is rediculous and incredibly heavyweight. Quite often an axe where a butter knife will suffice. Perhaps we could just say that a service is a containerized entity. However an organization/indvidual wants to create that container or deploy it does not belong as part of the requirement for microservices.

[ismaelfaro]

Hi @amitsides , Thanks for your point about Agent-Mesh, we had the internal debates about what can be the next iterations on how the Agents can be interconnected, and pass messages, and as part of that, how, from the discovery point of view, the agents can discover one to another.

For start, we were working in simple "hard-coded" composition, and like you said also, in some moment all this infrastructure of agents should evolve to be deployed in K8s, taking all the advantage of the Kubernetes knowledge and tools. Said that, how can we extend that functionality to allow agents discover other and tools and how they can trust between them?. Today there are ways to discover other services and also we discussed if Istio is going to be enough to protect/coordinate access to agents or group of agents.

We thought that in some moment, and depending of the environment, we are going to need to have some agents that are going to be inmutables, that we can cover with a current solution such as "Helm", and also can exist other agents or tools generated by other agents, "on the flight", in that case is posible the the current solutions like Istio can be extended too, or we can find other way to handle that.

Let me add some "time line" that can help us to clarify the Current steps to cover (the current ideas implemented), Next steps (how we can deploy and have distributed agents using K8s that can have some organization (stateless environments with simple replication) and connectivity using Agent-Mesh, and Future/POC with ideas to experiment.

[meetrais]

Essentially if framework can provide ability for users to build the solution in an image(docker) then users can deploy that image in any environment like K8s(AKS/GKE/EKS) or even on-premise. Ideally it should give that flexibility to users, how and where they want to deploy.

[Cenrax]

We also need to design when agent are communicating what would be the format and how can they communicate with optimal data encoding.

[ismaelfaro]

Happy to work with you in extend that part of the conversation as part of the points 4 and 5:
4.- Selecting/defining the optimal data encoding (REST, JSON-RPC, etc...)
5.- Establish methods of Agent-to-Agent Communication (WebSockets, HTTP, Peer-to-Peer, ...)

[d-a-v-i--]

I'm looking into how ACP could integrate with different aspects of agent architecture, particularly around data persistence in terms of privacy and integrity. I'm considering a demo that shows how Solid W3C data wallets (via Podspaces) could serve as the privacy-preserving persistence layer within the broader agent ecosystem @amitsides described. This would demonstrate how Agents operating in a microservice/k8s environment could securely access user data stored in Solid pods, yet user control remains intact even as agents utilize vectorDBs, graphDBs, and embedding-based communication. Sensitive data (like healthcare information) stays in user-controlled storage while still being accessible to authorized agent processes.

Before proceeding:

• Does integrating the W3C Solid protocol as a privacy-preserving persistence layer align with ACP's vision?
• Are there specific security challenges in the current architecture that a user-centered approach might address?
• Are there existing efforts to define standardized data security patterns I could contribute to?

The goal would be showing how ACP can enable sophisticated agent capabilities while maintaining strong privacy boundaries through user-controlled data wallets.

[ismaelfaro]

@d-a-v-i-- thanks for your contribution and like you said "data persistence in terms of privacy and integrity" are a very critical topic if we think in business/enterprise. We must to have cover the question that you mentioned, and is possible that some of them is going to beed to be solve in different phases

@psschwei I think that you can help here too, and work with @d-a-v-i-- in the data security patterns.

[psschwei]

I only know a little bit about Solid and its larger ecosystem, but based on that I think that in general it handles something similar to some of what we're looking to do here: determine "who" is allowed access to what data and making sure that protected data doesn't leak out when accessed. So I think it'd be worth exploring if/how we can integrate Solid and ACP. @d-a-v-i-- happy to have a chat to learn more about Solid and what you're thinking if that'd be useful.

[that1guy15]

Is there a discussion around compatibility with current MCP servers? Being able to leverage the current momentum and work around MCP could help quicken adoption. But there are the obvious downsides of having to support cross-conpatability.

[michelvdp]

Since this is built on top of MCP, it's compatible in my view. This comes from the initial draft:
In its Pre-alpha version, ACP extends the Model Context Protocol (MCP), leveraging the simplicity and versatility of JSON-RPC. This structure offers flexible and efficient interactions between agents, platforms, and external services.

[jezekra1]

We did a fork of MCP about two months ago, it'll work until the projects significantly diverge. We don't sync the fork at the moment.

You can try adding regular MCP server as a provider and access it tools through the beeai tool run or with the sdk client.

If we decide to abandon MCP as the basis for ACP, we'll need to determine how we're going to support MCP tools - (it could be through the very same proxy we built for ACP or something very different)

[anshublog]

Would be good to make a list of prior technologies that we believe are good, and therefore we will try and avoid duplicating them. Things like REST, OAuth, etc. I am assuming MCP is also "good".

Good List:
REST

Bad List:

Neutral List:
MCP [?]

[ismaelfaro]

thanks @anshublog , and part of the make this project collaborative go in the direction to add tools that exist that work now :). MCP is a good example and such @michelvdp commented before, is something that ACP is using.

More that have a monolithic list, I think that we can incorporate each dependency in each critical part of the project. Example: agents communicate, enabling automation, agent-to-agent collaboration, UI integration, and developer tooling (Integration, deployment [local, cloud], debugging/testing)

[bcjteixeira]

I'm following with very interest your discussions. I've done some work with JADE library on Java along with MQTT as communication. Very robust solution for multi-agents with multiple kinds of scenarios. I would love to help in some way if makes sense for you. Thanks and keep up with the excelent work

[ismaelfaro]

@bcjteixeira thanks for your comment, and part of the goal is exploring different scenarios. I think that we should have a work stream to discuss potential solutions/implementations, I believe that the complexity of each scenario is going to help us to define the different implementations and priorities.

[AndrewRentschler]

Standardized Agent Role Taxonomy

Instead of viewing all agents as equal peers in a flat network, a formalized role hierarchy could provide structure to the agent ecosystem:

interface AgentRole {
  type: RoleType;
  capabilities: Capability[];
  trustLevel: TrustLevel;
  allowedCommunication: CommunicationPattern[];
}

enum RoleType {
  ORCHESTRATOR,         // High-level coordination
  DOMAIN_SPECIALIST,    // Business logic in specific domains
  RESOURCE_MANAGER,     // Managing computational resources
  INTERFACE_AGENT,      // External system interfaces
  OBSERVER,             // Monitoring and metrics
  TOOL,                 // Single-purpose utilities
  CONVERSATIONAL,       // Specialized in user interactions and dialog management
  RESEARCHER            // Information gathering, synthesis and analysis
}

Role-Specific Characteristics
Some key differences between these roles:

ORCHESTRATOR: Coordinates complex workflows across multiple agents, maintains high-level state, and makes decisions about task delegation.
DOMAIN_SPECIALIST: Contains deep expertise in specific business or technical domains, with sophisticated reasoning capabilities in their area.
CONVERSATIONAL: Specialized in natural language understanding, maintaining conversation context, and adapting responses to user needs.
RESEARCHER: Focused on information gathering, verification, and synthesis from diverse sources, with capabilities for citation and verification.

Extensibility Considerations

The provided taxonomy and structures are intentionally designed for extensibility. Roles and capabilities can easily be extended or specialized further:

• Open Role Hierarchy:
  Introduce sub-types or specialized roles as needed. For instance:

  interface DomainSpecialistRole extends AgentRole {
    specialization: string; // must match /^[a-z]+(-[a-z]+)*$/
  }

  // Examples: 'finance', 'healthcare', 'supply-chain', 'custom-domain'

• Flexible Capabilities:
  Capabilities can evolve by adding new operation types, resource types, or constraints without overhauling existing infrastructure. Custom capabilities can also be dynamically defined for novel use cases.

This approach allows for structured innovation within a stable and predictable ecosystem.

Practical Implementation in K8s
This could manifest in your K8s environment with:

• Role-Based Namespaces: Group agents by role type
• Standard Labels: app.kubernetes.io/role=researcher
• Role-Specific ServiceAccounts: Different RBAC permissions by role
• Communication Policies: Network policies based on role relationships

Benefits for Discovery & Trust
This directly addresses your discovery and trust questions:

• Simplified Discovery: Agents primarily discover others based on role rather than individual identity
• Predictable Communication Patterns: Orchestrators talk to Domain Specialists, not to Tools
• Trust Boundaries: Higher trust requirements for higher-level roles
• Scalability: New agents slot into existing structures based on their role

2. Capability-Based Security Model
   To address trust between agents, especially in dynamic environments with agents created "on the flight":

interface Capability {
  id: string;               // Unique identifier
  resourceType: string;     // What kind of resource this grants access to
  operations: Operation[];  // What operations are allowed
  constraints: Constraint[];// Additional restrictions
  expiresAt?: Date;         // Optional expiration
  delegatable: boolean;     // Can this capability be passed to others?
}

Implementation Approach

• Capabilities are unforgeable tokens (implemented via cryptographic signatures)
• Agents present capabilities when requesting access to other agents or resources
• Verification is simple: check signature and constraints without complex policy evaluation
• Kubernetes RBAC can be used as the foundation, extended with agent-specific semantics

Benefits

• Fine-grained control: Precisely control what each agent can do
• Composable security: Build complex security patterns from simple capabilities
• Delegation: Allow trusted agents to create less-privileged agents
• Revocation: Capabilities can expire or be explicitly revoked
• Audit trail: Clear record of capability issuance and usage

3. Agent Lifecycle Management
   For handling the complete lifecycle of dynamically generated agents:

enum AgentState {
  INITIALIZING,
  ACTIVE,
  DEGRADED,
  RETIRING,
  RETIRED
}

interface AgentLifecycle {
  state: AgentState;
  version: string;
  createdAt: Date;
  createdBy: string;
  retirementPlan?: RetirementPlan;
  successorAgent?: string;
}

Key Lifecycle Processes

• Structured Creation: Standard metadata, versioning, and provenance tracking
• Health Monitoring: Regular health checks and self-diagnostics
• Graceful Retirement: Planned succession and responsibility handover
• Version Management: Strategies for upgrading agent capabilities
• Resource Reclamation: Ensuring resources are freed when agents retire

Benefits for Dynamic Agent Environments

• Prevents system cruft: No abandoned or zombie agents
• Simplified upgrades: Clear paths for replacing agents with newer versions
• Responsibility continuity: Tasks aren't dropped during transitions
• Resource efficiency: Resources are properly reclaimed after use

(written by human, formatted by ai)

[24601]

Using the control plane of k8s has been a central part of the work of making agents self-adapting and self-assembling for us so far, especially with k8s RBAC is properly integrated, so far has proven to be the best lingua franca that bridges a human operators/teams and machine operators/teams.

[ismaelfaro]

Thank @AndrewRentschler for your point about "Standardized Agent Role Taxonomy", I see the potential to have some specific roles, and we discussed how have it in some moment, said that let me share here some of comments.

• We should have some general roles, and some of the discussion here can be what kind of general agents we think that we need to start. For example I see the need to have at least roles of agents that can help to handle other (system/supervisors agents), other that are upload by a user (user agents), and like you commented we can have a sub-role to be more specific.
• we also can reuse ideas like reverse domains, to indicate if a agents is a system agent, for security and focus in validate data: sys.
• I love the Agent Lifecycle Management part, and we discussed about similar ideas, taking also in consideration the "quality of the agent" and other example can be "external evaluation" .... part of this Lifecycle should be add some details to the topic "Manifest Based Agent Offline Discoverability", in sense that can help to "clean up legacy or problematic agents" Manifest-Based Agent Offline Discoverability #344

[hari-lab-github]

We started to discuss and implement an alpha version of ACP, based in solid ideas from MCP, and starting to connect points with other projects such as NLIP

Suggested topics:

1. Handling Stateful and Stateless Agents
2. Manifest-Based Agent Offline Discoverability
3. Evaluating Natural Language as an Agent Interface
4. Selecting/defining the optimal data encoding (REST, JSON-RPC, etc...)
5. Establish methods of Agent-to-Agent Communication (WebSockets, HTTP, Peer-to-Peer, ...)
6. Integrating Legacy Software with Agent Protocols
7. Streaming Data between Agents
8. Handling Request Cancellation and Ensuring Persistency
9. Agent and Tool Providers and MCP Servers: Roles and Responsibilities
10. Deployment Strategies for Agents
11. Configuration and Model Dependency Management for Agents

The discussion is open. 👋

12. Agents integration with Test Data along with service virtualization for API Testing

[ismaelfaro]

thank @hari-lab-github for the contribution. I think that we can see how extend the topic, or add your idea/contribution as part of the "Deployment Strategies for Agents" + Testing.

@matoushavlena what do you think?

[macyabbey]

13. Agent Authentication & Authorization

A challenging part of the agent space is how to authenticate and authorize agents, whether on-behalf-of a human operator, or as "themselves."

When considering a protocol on how Agents collaborate, it strikes me that this will only get more challenging.

• Do agents need to authenticate with each other?
• Does instance of agent A need to be authorized to invoke agent B?
• Agents often authenticate and authorize with third party resource servers (typically with OAuth 2.1), does a single execution of a workflow with N agents all requiring OAuth flows with the same Authorization Server require N authorization flows? Or do we need some concept of token exchange / brokering?

There is relevant work and emerging standards in the industry, such as:

• https://datatracker.ietf.org/doc/html/draft-parecki-oauth-identity-assertion-authz-grant-00

@ismaelfaro I would love to engage and contribute around this topic.

[ramwert]

In addition to this, how do we store and pass user consents on data sharing @ismaelfaro

[ismaelfaro]

Thanks @macyabbey and @ramwert , we can open a discussion for address that important point, everything related with security, auth delegation, dependencies evaluation/verification, and trust/certification are going to be a key topic.

[QuantGeekDev]

This is so cool! Saw the announcement on Linkedin. I'm coming from the mcp perspective - I'm the author of mcp-framework, the most used typescript framework for MCP servers (https://mcp-framework.com) and I am also the volunteer manager of the r/modelcontextprotocol community Reddit and Discord. Come join and say hi if you haven't already - we're chatting there geeking out about the protocol all day, there's a lot of FOSS devs in there that would jump in on this conversation. Would love to participate in this project, is there any place where you're holding a more casual discussion? Eager to dive into this once I get more bandwith in the coming weeks. Let's collab!

[ismaelfaro]

Thanks @QuantGeekDev.

Let me propose to have a open session with people that want to contribute next week, and organize how we can collaborate all together in this effort.

[meetrais]

I would love to be part of that session. @ismaelfaro

[QuantGeekDev]

Thanks @QuantGeekDev.

Let me propose to have a open session with people that want to contribute next week, and organize how we can collaborate all together in this effort.

I'm in!

[24601]

@ismaelfaro - I'd like to be part of the session, too (and by extension my team/org as we can and will bring others in as necessary). We aren't a major AI lab but are a venture-backed AI company and have been doing work in this area for a bit with Fortune 10, 100, and 500 companies with very tight compliance requirements (government + defense), so we've had some unique approaches and been forced to take approaches that I think align quite a bit here we'd love to contribute to as we can.

(Also a former IBMer, and have a soft spot for IBM and IBM Research and the methodology/approach from those orgs, where I began my career)

[QuantGeekDev]

Agent Context Protocol mentioned here: https://www.reddit.com/r/modelcontextprotocol/comments/1jejtag/re_the_fake_mcp_community/

[ismaelfaro]

thanks @QuantGeekDev

[ramwert]

Another area is a Control Panel which would be a one stop place for consumers. Given the multi agent involvement it would be great if we have in early stage for adoption.

[geneknit]

Could you say more about what you would envisage for a control panel? What type of data/metadata would you imagine surfacing @ramwert? Any comparisons you can make to flesh out the idea?

[matiasmolinas]

I've been developing an agent evolution toolkit that has given me some perspective on agent communication protocols. I'd like to share some thoughts on ACP design principles:

Agent-Centric Communication Model

Current multi-agent workflows typically follow one of two patterns:

1. A "collection of agents" where no single agent coordinates the system
2. A dedicated orchestrator agent that manages the workflow

I believe we need an approach that recognizes agents as capability providers where:

• Each agent has well-defined responsibilities attached to specific capabilities
• Agents discover and consume services from other agents based on capabilities
• Orchestration, security, and even agent creation are handled by specialized agents

Moving Beyond Monolithic Systems

Currently, most multi-agent systems run like monolithic applications - everything in the same process, similar to early object-oriented software. To scale effectively, ACP should enable:

• Remote agent invocation (across processes/machines)
• Instance management (creation, reuse, caching)
• Dynamic discovery based on capability requirements
• Resource management (considering LLM, memory, and CPU requirements)

Agent Description vs. Implementation

The protocol should focus on what agents can do rather than how they do it:

• Capabilities as the primary interface definition
• Domain-specific requirements as metadata
• Performance history as a selection criterion (success rate, reliability)
• Implementation details encapsulated behind capability interfaces

Protocol Design Priorities

I suggest the ACP development prioritize these aspects:

1. Capability-based discovery and routing - Find agents by what they can do
2. Stateful communication patterns - Support for conversations, not just request/response
3. Performance metadata exchange - Share success metrics to guide agent selection
4. Domain-specific constraints - Express when agents require specific domains
5. Governance integration - How firmware/guardrails apply across agent boundaries

Only after these concepts are clearly defined should we focus on the technical implementation (JSON-RPC vs gRPC vs WebSockets, etc.)

Proposal

Perhaps we could start by defining:

1. A capability manifest format that clearly expresses what agents can do
2. Standard patterns for agent-to-agent requests and responses
3. A basic capability registry design for discovery
4. Patterns for conveying state between agent interactions

This would provide a foundation that could be implemented across different technological approaches while ensuring conceptual consistency.

What do others think about centering the ACP design on agent capabilities and responsibilities before diving into implementation details?

I am in the early stages of exploring some of these ideas here: https://github.com/matiasmolinas/evolving-agents/

[psschwei]

...centering the ACP design on agent capabilities and responsibilities...

I like this way of thinking about agents, and it's similar to some of the ideas we had been exploring. Would be interested to discuss more.

Some thoughts I had while reading: how are you thinking that capabilities would be defined? By the agent creator? By the agent itself? And what about agents that don't define capabilities, would that prevent them from using ACP? (posting these more for discussion / exploration than as something we need answers to)

[matiasmolinas]

Great questions about capability definition - this is indeed central to making the entire ACP concept work!

I envision a multi-layered approach to capability definition:

1. Definition Sources:

   • Creator-defined: The agent creator would initially define capabilities in a manifest using a standardized schema (similar to how API providers document their endpoints)
   • Self-describing: Advanced agents could analyze their own functionality to update or refine their capability descriptions
   • Discovery-enhanced: The system could learn how agents are actually used, enhancing capability definitions based on successful interactions

2. Description Format:
   I agree that natural language remains powerful for describing capabilities. I'm thinking of a hybrid approach:

   • Structured schema for machine-readable properties (inputs, outputs, requirements)
   • Natural language descriptions for human understanding
   • Examples of use (similar to API documentation)
   • Perhaps even symbolic representations (similar to UML) for complex workflows

3. For Agents Without Explicit Capabilities:
   This is a crucial consideration for backward compatibility! I'd propose:

   • An "adapter pattern" where legacy agents get wrapped with a capability interface
   • Capability inference - analyzing agent behavior to auto-generate capability descriptions
   • A minimal "generic-agent" capability that allows basic participation with reduced discovery benefits

The beauty of a capability-based approach is its flexibility - agents with rich capability descriptions would benefit from precise discovery and routing, while simpler agents could still participate with more generic descriptions.

I think of it like modern web APIs - some have detailed formal specifications that support advanced tooling and integration, while others function with minimal documentation. The protocol should accommodate both approaches while encouraging movement toward more comprehensive descriptions.

Would love to discuss this further - particularly how we might standardize capability schemas without making them too rigid for the diverse types of agents we'll see in the future.

[matiasmolinas]

Okay, I am working on a POC of these ideas (definition and use of capabilities) here: https://github.com/matiasmolinas/evolving-agents?tab=readme-ov-file#the-agent-bus-capability-based-communication. So far, I have started adding the concept of capability. In the coming days, I will update the agent bus to incorporate it (currently, it is a very basic concept).

[psschwei]

thanks for sharing! will take a look

[psschwei]

One question:

Agent-to-Agent Communication: Agents communicate through capabilities rather than direct references

I'm assuming that both capabilities and direct references would be supported, right? I can imagine instances where you'd want to call a specific agent, so I'd think we'd want to be able to do that too.

[QuantGeekDev]

I think one of the more fundamental issues around agents are keeping their context unpolluted. Over time this should be less and less of an issue (altho I'm curious to see how we will bypass this fundamental transformer architecture problem), but for me agents solve the problem of single responsibility but shared context. That way each receives what they need, and no more. So I think about it from that angle

[matiasmolinas]

I agree completely - context management is a fundamental challenge for multi-agent systems! This aligns perfectly with the capability-based approach I've been exploring.

My proposal would address this by making context requirements an explicit part of the capability description:

1. Context Contract: Each agent capability would declare:

   • Required context fields (must be provided)
   • Optional context fields (enhances performance but not mandatory)
   • Produced context fields (what the agent adds/modifies)

2. Context Isolation: The protocol would enforce boundaries, preventing agents from accessing context they haven't explicitly requested.

3. Context Transformation: Orchestrator agents would handle mapping between different agents' context requirements.

This creates a clear "interface contract" for context - much like method parameters in object-oriented programming. When an agent discovers and invokes another agent's capability, it knows exactly what context to provide.

For example:

{
  "capability": "document_analysis",
  "context_requirements": {
    "required": ["document_text", "analysis_type"],
    "optional": ["previous_analysis", "domain_hints"],
    "produces": ["extracted_entities", "document_summary"]
  }
}

Note: This capability description is deliberately simplified for illustration. In practice, a robust capability description would need much more detail, including data schemas for each context field, validation rules, maximum context sizes, handling of truncation, privacy/security constraints, and potentially context versioning. The actual implementation would need to address the full complexity of context management that you correctly identifies as a critical issue.

This would allow agents to maintain single responsibility while sharing precisely the right amount of context - no more, no less. It also creates a cleaner separation of concerns where each agent only sees what it needs to do its job effectively.

What do you think? Would this approach help solve the context pollution challenge you described?

[QuantGeekDev]

I'd have to try this in practice but this standardizes a few techniques, such as tool bundling per agent. How can we make agents more "deterministic"? I find that in practice, (and agents love to do this during demos!) - it sometimes skips over crucial parts of context. It might make sense to have some sort of context priority levels, in the same ways we are able to filter out the noise when necessary. But I haven't tried implementing that. Would the orchestrator agents be able to validate that the tool use was correct, or that it wasn't an incorrect usage? In theory we can add many such redundancies, but then everything slows down the process and increases the cost. Is it possible to try this out?

[matiasmolinas]

Your concerns about agent determinism and context management are spot-on. Let me address each point in relation to my idea about using simulations with mock tools:

Making Agents More Deterministic

The simulation approach I proposed directly tackles determinism. By creating mock tools that return predefined responses in test scenarios, we can make agent behavior much more predictable. For example:

• Instead of calling a real weather API that might return different data each time, we can use a mock weather tool that always returns the same forecast for a test case
• For database queries, we can create mock tools that return consistent data sets

This controlled environment helps identify when agents skip crucial context, as the outputs become directly comparable across test runs.

Context Priority Levels

Your suggestion about context priority levels is excellent and complementary to the simulation approach. In our mock tools, we could implement:

• Critical context flags that must be acknowledged by the agent
• A validation layer that verifies the agent has processed high-priority information
• Feedback mechanisms when important context is ignored

Orchestrator Validation

Regarding orchestrator validation of tool usage, this is exactly where the simulation environment shines. Since we control the mock tools, we can:

1. Log every tool call with its inputs
2. Compare against expected usage patterns
3. Flag incorrect parameters or inappropriate tool selection
4. Create automated test suites that verify proper tool usage

Balancing Redundancy and Performance

You're right that adding validation layers increases cost and latency. The simulation approach helps by:

• Allowing thorough testing in development rather than production
• Identifying the minimum necessary validation for reliable performance
• Creating benchmarks for acceptable performance/reliability tradeoffs

Trying It Out

Yes, it's absolutely possible to try this out! I'm working on a simple implementation that would include:

• A toolkit for creating mock tools with controlled outputs
• A simulation harness for running agent scenarios
• Evaluation metrics for determinism and context handling

[QuantGeekDev]

Your concerns about agent determinism and context management are spot-on. Let me address each point in relation to my idea about using simulations with mock tools:

Making Agents More Deterministic

The simulation approach I proposed directly tackles determinism. By creating mock tools that return predefined responses in test scenarios, we can make agent behavior much more predictable. For example:

• Instead of calling a real weather API that might return different data each time, we can use a mock weather tool that always returns the same forecast for a test case
• For database queries, we can create mock tools that return consistent data sets

This controlled environment helps identify when agents skip crucial context, as the outputs become directly comparable across test runs.

Context Priority Levels

Your suggestion about context priority levels is excellent and complementary to the simulation approach. In our mock tools, we could implement:

• Critical context flags that must be acknowledged by the agent
• A validation layer that verifies the agent has processed high-priority information
• Feedback mechanisms when important context is ignored

Orchestrator Validation

Regarding orchestrator validation of tool usage, this is exactly where the simulation environment shines. Since we control the mock tools, we can:

1. Log every tool call with its inputs
2. Compare against expected usage patterns
3. Flag incorrect parameters or inappropriate tool selection
4. Create automated test suites that verify proper tool usage

Balancing Redundancy and Performance

You're right that adding validation layers increases cost and latency. The simulation approach helps by:

• Allowing thorough testing in development rather than production
• Identifying the minimum necessary validation for reliable performance
• Creating benchmarks for acceptable performance/reliability tradeoffs

Trying It Out

Yes, it's absolutely possible to try this out! I'm working on a simple implementation that would include:

• A toolkit for creating mock tools with controlled outputs
• A simulation harness for running agent scenarios
• Evaluation metrics for determinism and context handling

Thanks for the answer! I like this approach. Can you share your code? I'd love to help and contribute where I can :)

[deghislain]

I am learning how to use ACP(Agent Communication Protocol) building a small RAG application. This application has a tool that given an url, it will retrieve its content store it in a vector db(Chroma in this case) then use it to reply to users through semantic search.
I noticed a weird behavior, I mean it looks like the model that I am using is replying to question without running my tool. The response seems to be from its training data. I am using granite3-dense locally with ollama. Looking at my logs I can see that my tool was detected and every thing seems to be fine but for some reason the agent is ignoring it. I am I missing something?

@ismaelfaro If this is not the right place for this kind of question, please point me to the right one, I am really interested in learning how this protocol works. I tried MCP before with a similar application and it seems to be working, so I am probably missing something here with ACP but not sure what.

[psschwei]

You might want to try asking on the discord: https://discord.gg/NradeA6ZNF
I think you'll get better troubleshooting advice there than here

[deghislain]

thanks @psschwei

[InvertebrateAdvocacy]

Orchestration is premature, for now. Lots of wins with JSON-RPC can be had emulating similarities between the 'ladder-like' nervous system in invertebrates and the 'Agent-Mesh' concept. Let's slither before we crawl.

[psschwei]

Streaming Data between Agents

I think this is going to be important... currently one of the most frequent requests I get for individual agents is to be able to stream agent events (folks want to see them "think"), so it will be interesting to see how that can be adapted for multi-agent workflows and communications...

[QuantGeekDev]

@psschwei Have you looked into llama-index event based agentic workflow orchestration? I think it's an interesting implementation to take a look at https://docs.llamaindex.ai/en/stable/module_guides/workflow/

[psschwei]

Thanks for the link... looks interesting! Think there's some nice tie-in here with @RinoX1 's comment above about the need for async too

[RinoX1]

Yes, having an async queue messaging broker to handle traffic between distributed agents will enable several observability elements related to how messages are transmitted across the network (representing the actual ordered cognitive sequence), along with other relevant observability insights.

[psschwei]

Also worth noting: MCP released a Streamable HTTP yesterday: https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/#streamable-http

[QuantGeekDev]

Also worth noting: MCP released a Streamable HTTP yesterday: https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/#streamable-http

You can try an experimental implementation of the spec here while we wait for them to add it to the official sdk. It will be backwards compatible as soon as the sdk comes out: https://github.com/QuantGeekDev/mcp-framework/blob/main/src/transports/http/server.ts. I'm adding the CLI command mcp create yourProjectName --http --cors today to be able to quickly create the boilerplate for your own mcp server

[ismaelfaro]

Hi ACP community, first thanks for the good discussions, now let me recap and group here the main concepts:

• Architecture & Core Protocol Design
• Deployment & Infrastructure
• Data Security & Privacy
• Protocol Implementation & Encoding
• Testing & Quality Assurance
• MCP Integration & Compatibility
• UI & User Experience

Our intention is create work streams for this main discussion, and add the key topics and participants, to progress in the details. This is going to helps us to Release proposal of priority items for review, by end of next week, and use it for our "ACP online community meeting" the week after.

[matiasmolinas]

Hi all,

Following up on the excellent discussions here regarding ACP, I wanted to share some progress and thoughts based on applying these concepts within my evolving-agents project: https://github.com/matiasmolinas/evolving-agents

1. Architecture & Capability POC: I've continued refining the architecture (ARCHITECTURE.md) based on our capability-centric discussions. I've also implemented a basic capability registry within the SmartAgentBus (link to section) to get the core functionality working.

2. Dual Bus Implementation (Current Work): Inspired by @ismaelfaro's idea mentioned earlier, I'm working this week on splitting the agent bus concept into two distinct channels within the SmartAgentBus implementation:

   • A System Bus for system-level messages (e.g., agent registration/discovery updates, metadata changes).
   • A Data Bus specifically for agent-to-agent payload communication and capability invocation.
     I agree this separation seems logical and should lead to a cleaner implementation of the agent bus's responsibilities.

3. Smart Context & Memory (Current Work): Related to the dual bus and addressing @QuantGeekDev's valid concerns about context pollution and relevance, I'm also starting work on concepts for Smart Memory and Smart Context. The goal is to develop mechanisms that help agents intelligently package and transmit only the most relevant context needed for specific capability requests exchanged over the Data Bus. This feels crucial for defining effective and efficient agent communication.

4. MCP Integration Thoughts & Doubts: I spent some time analyzing how MCP might fit into this evolving architecture. I can see how certain components in my toolkit (like the SmartLibrary or SmartAgentBus) could potentially function as MCP servers, while others (like SystemAgent or ArchitectZero) could act as MCP clients.
   However, a fundamental question arose: In an agent-centric system where agents themselves can often be viewed or used as tools (similar to the OpenAI Agents SDK model), does an architecture heavily reliant on potentially numerous, distinct MCP servers and clients become overly complex or less scalable? It made me wonder if a more agent-native communication approach might be needed within the core agent ecosystem itself.

5. Immediate Focus: Given this uncertainty about the best integration pattern for MCP at this stage, I've decided to temporarily pause deeper analysis of MCP integration for agent-to-agent communication within my toolkit. Instead, my focus this week will remain on implementing the dual-bus (System/Data) architecture and the Smart Memory/Context mechanisms, as I believe these are foundational steps for defining the agent communication patterns effectively based on the capability-centric model.

Will share updates as these components develop! Eager to hear feedback on this direction.

[InvertebrateAdvocacy]

I asked Gemini Flash 2.0: How are edge cases best addressed in reference to: However, a fundamental question arose: In an agent-centric system where agents themselves can often be viewed or used as tools (similar to the OpenAI Agents SDK model), does an architecture heavily reliant on potentially numerous, distinct MCP servers and clients become overly complex or less scalable? It made me wonder if a more agent-native communication approach might be needed within the core agent ecosystem itself.

It replied: https://g.co/gemini/share/4d945cc25b1e

Essentially all of Gemini’s considerations entailed server-centric limitations. We’re all familiar with the essentially insurmountable difficulties of addressing all the edge cases of any system. I’ll argue that’s due to server-centrisms – or centrisms period. That’s essentially why we have scoping principles in the first place – or more relatably: think globally; act locally. Reimagining agents as ganglion opens up more possibilities for addressing the myriads of edge cases. That was pithily articulated by British evolutionary biologist and geneticist J.B.S. Haldane when he quipped that if a god or divine being had created all living organisms on Earth, then that creator must have an “inordinate fondness for beetles.”

[InvertebrateAdvocacy]

Reading an MIT Technical Review primer titled Understanding Small Language Models, that might equally be applied to agents, the goal of it all was well said:
In the age of generative AI, innovators have typically taken a “bigger is better”
approach—but smaller may prove more practical in many situations.
Small language models (SLMs) have the potential to
accelerate AI adoption in more organizations, and
for more use cases. Reduced inference costs, lower
power consumption, and more scalable, streamlined
architecture make SLMs a more accessible AI option
for many. Their ability to run offline and at the edge
allows for real-time decision-making even in remote
locations or areas with limited connectivity.
SLMs are best suited for focused, specialized
applications—and those that require enhanced
security. Trained on domain-specific datasets and
with far fewer parameters than large language models
(LLMs), SLMs are ideally tailored to a particular use
case. Since they do not require recall from the cloud,
SLMs can be especially useful in highly-regulated
industries where privacy is a priority.
A hybrid approach to enterprise AI is likely to
emerge. Due to their limited scope, SLMs cannot be
everything to everyone. Companies may find a “mix-and-match” approach—where smaller models handle
simple tasks locally and complex queries are routed to
larger models in the cloud—a way to maximize model
performance and AI capabilities.

[jero2rome]

I see DAPR would be a solid foundation for building POC. If cloud native tools and concepts can be reused, eg. pub/sub pattern, statestores (context sharing), service discovery. Together with concepts similar to docker hub where agents can be versioned with comm protocol version that follows a standardized schema it would be sufficient to expose capabilities. Together with MCP integration at agent level could be a well rounded implementation for a proof of concept.

[planetf1]

Comments on API reference:

• The curl request examples show http. I would presume this would be https?
• GET /agents :
  • There is a limit (ie page size) and offset. Is there any intent to add sorting (whilst respecting pagination). Or filtering. One example use case is to find the most recent n new agents, or those since a certain date/last look.
  • The metadata is marked as optional. Would some entries be better as mandatory? For example createdAt/updatedAt/author/framework. Otherwise the catalogue could become hard to use
  • status.successRate - could be clearly documented as a percentage (though that is implied by the range)
  • metadata.recommendedModels - this has ollama as an example model name, but ollama & openAI are the inference platform, not a model
  • metadata.links has a type of docker-image. Should it be container-image to use the more generic term, given that we'd expect it to be used with other runtimes such as containerd and cri-o
  • Is there an intent to have a version? Whilst modified/created gives a hint, this seems more explicit
  • metadata.useCases - presume Markdown?
  • metadata.dependencies - The dependency is by name. I think we could do with additionally having a version spec. Also if hosted in same catalogue it could be an agent_id which might make deployment validation easier?
  • Consider adding a list of supported languages (as in French, English ... )?
  • metadata.interfaces -- object is defined for input/output. Is a link to a json schema an alternative?
• GET /agents/{agent_id}
  • Similar to the list above
• POST /runs
  • The output object only has the type of artifact (with url and name) /image/string. I would expect a structured type (json schema / object definition) as an option. But additionally, if this is a run create, how to we have output available? Presumably only when the mode is sync so make this explicit in the doc?
• GET /runs/{run_id}
  • As above on output
• POST /runs/{run_id}
  • If a run is resumed when awaiting, could status still return awaiting? What would this mean? Can a run always be resumed? If not, but it's a valid run_id what happens?
• POST /runs/{run_id}/cancel
  • If a cancel run synchronous or asynchronous. Similar to above, what would the valid status be ?
  • output is listed. What does this mean on a cancel request?

[matoushavlena]

@planetf1 Thank you for the comments.

The curl request examples show http. I would presume this would be https?

The examples show localhost, that's where the platform runs by default. No https support is intended there.

Is there any intent to add sorting (whilst respecting pagination). Or filtering.

Yes

The metadata is marked as optional

IMHO ACP as a standard shouldn't be too restrictive and really require only data fields that are needed for operational needs. The platform on the other hand can require more data during agent installation. The OOTB agents will have most of the fields filled as part of the contribution process.

status.successRate - could be clearly documented as a percentage (though that is implied by the range)

Can you suggest OpenAPI data type for this?

metadata.recommendedModels - this has ollama as an example model name, but ollama & openAI are the inference platform, not a model

Can you elaborate more on the problem and suggest a solution?

metadata.links has a type of docker-image. Should it be container-image to use the more generic term, given that we'd expect it to be used with other runtimes such as containerd and cri-o

Updated

Is there an intent to have a version? Whilst modified/created gives a hint, this seems more explicit

This is something being discussed at the moment. Given that agents can be runnable containers, we need to make sure that there is a single truth from where the agent version can be extracted. Feel free to elaborate more on how do you imagine this to work.

metadata.useCases - presume Markdown?

Plain text (although markdown can be used). I updated the description.

metadata.dependencies - The dependency is by name. I think we could do with additionally having a version spec. Also if hosted in same catalogue it could be an agent_id which might make deployment validation easier?

I documented this field as Experimental given we first need to form opinion on versioning and identifiers.

Consider adding a list of supported languages (as in French, English ... )?

Renamed language to programmingLanguage. Added naturalLanguages field. Let me know what you think.

metadata.interfaces -- object is defined for input/output. Is a link to a json schema an alternative?

Not sure I understand. The intention is that you can specify your json schema, or use one of the OOTB schemas expressed as string (chat, text, more coming). This is still WIP and related to the below 👇

The output object only has the type of artifact (with url and name) /image/string. I would expect a structured type (json schema / object definition) as an option. But additionally, if this is a run create, how to we have output available? Presumably only when the mode is sync so make this explicit in the doc?

This is still WIP, especially related to https://docs.beeai.dev/acp/spec/concepts/message-body-structure, feel free to contribute a proposal.

If a run is resumed when awaiting, could status still return awaiting? What would this mean? Can a run always be resumed? If not, but it's a valid run_id what happens?

Check this out: https://docs.beeai.dev/acp/spec/concepts/run#run-states. If status is awaiting, it means the agent is awaiting an action from external Client. Resume means, that the Client did the needed action and communicated it back to the agent as a valid payload. This results in a status change. Yes, run can always be resumed, as far as a valid payload is provided.

If a cancel run synchronous or asynchronous. Similar to above, what would the valid status be ?

cancelled (see https://docs.beeai.dev/acp/spec/concepts/run#run-states)

output is listed. What does this mean on a cancel request?

The object will be nullable (it's actually, just not propagated in the UI). The idea is that either resume or cancel return the same object of the run. In majority of the cases, the object would be null.

[ismaelfaro]

Thanks everyone for the comments in this thread. I'm open a new thread base in all the inputs, and groping it to start to divide the participation in work-streams, focus in key components.

ACP Work Streams: https://github.com/orgs/i-am-bee/discussions/488

We invite you to add there extra comments and also participate in the our Community meeting April 8th.

Also you can follow some more realtime news about the project in Discord

[geneknit]

Hey team. Based on this most excellent discussion, we have taken the first step of moving from ACP pre-alpha to a draft of our Alpha spec, built from the ground up for agent to agent communication. Let's go!

1. Review the OpenAPI schema here: i-am-bee/beeai/blob/main/docs/acp/spec/openapi.yaml
2. Learn more about the thinking behind this spec the docs.


3. Contribute comments, questions, concerns in a new dedicated discussion: i-am-bee/discussions/497

[matiasmolinas]

Hi everyone,

Great to see the progress with the ACP Alpha spec draft and the ongoing discussions!

Building on the excellent discussions here and with the goal of contributing practical insights to BeeAI ACP, I wanted to share some progress and thoughts from applying related concepts within my evolving-agents project (https://github.com/matiasmolinas/evolving-agents), which I'm using as a practical testbed for some of these ideas:

1. Dual Bus Implementation: As mentioned last week (inspired by @ismaelfaro's original idea), I've implemented the split between a System Bus (for registration, discovery, metadata) and a Data Bus (for capability invocation and payload exchange) within the SmartAgentBus. This separation, aligning with ideas discussed here, seems beneficial for clarifying communication needs within an ACP-like ecosystem.

2. The Crucial Role of Smart Context on the Data Bus: Implementing the Data Bus really highlights the need for Smart Context mechanisms (addressing @QuantGeekDev's points). For the Data Bus to be effective within ACP for agent-to-agent calls, we need to ensure agents receive context specifically relevant to the task and capability being invoked. My next step is designing Smart Context and Smart Memory components for this, exploring the "Dual Embedding Strategy" (using E_orig content embeddings and E_raz applicability/reasoning embeddings – more details here to improve task-specific retrieval. I believe robust context handling is fundamental for efficient and reliable agent communication under ACP.

3. MCP's Role in AI-First Workflows (KB & External Systems): Thinking about the AI-First workflow examples, my perspective on MCP's potential role within an ACP framework has solidified. I see MCP as highly valuable for enabling agents to interact with external Knowledge Bases and Systems (like Confluence or Jira). MCP provides the standardized "plumbing" for these external interactions. In EAT, this would manifest as MCP-backed Tools/Adapters discoverable and invokable via the Data Bus.

4. Distinguishing Internal vs. External Communication (for ACP): This framing helps distinguish MCP's role. While vital for external interaction, I still think ACP needs a robust mechanism for internal agent-to-agent capability exchanges within the managed ecosystem (the Data Bus + Smart Context concept). Relying solely on MCP's client/server model for all communication might add unnecessary complexity for internal interactions compared to a more direct, context-aware agent-native protocol facilitated by ACP.

So, my current focus within evolving-agents is on implementing and testing these foundational elements (dual bus, smart context) as I believe these are critical prerequisites for defining effective agent communication patterns within the ACP standard. My goal is to share practical findings, lessons learned, and potentially reusable patterns/code back to this group to help inform the ACP specification and implementation.

Eager for feedback on this direction and happy to collaborate on integrating the most promising ideas into BeeAI ACP!

[24601]

I need to take some time to read the above (very good, fun, and exciting) thread, what I have taken from my cursory first pass from the last week's updates or so is that I really like the distinction between the various buses, and perhaps this is an internal bias from earlier in my career where I began in networking (back in the circuit-switched days...think 53 byte cells, even! ATM, hahahaha....at IBM!), and in many ways, this is perhaps a greenfield set of problems, but the connections as a mental model (and not at all suggesting actual transport layer similarity at all) back to systems like Erlang, signalling protocols in circuit switched networks (as an analogue to stateful agents versus packet, specifically UDP, really, which are an analogue to stateless agents) continues to tug at me.

The amount of work telecom, energy, etc have put into the question of control planes, data planes, management planes, in band/out of band for all things from resource allocation, provisioning, audit, security, etc I feel like is a very useful body of work to reference for both what to do and not to do.

The question of clean slate (one extreme) and "nothing to invent here" (the other) is an interesting one without a singular answer. Which I also think is a reason you see k8s come up here a lot, because it tends to be one of the few well-adopted systems that converges this and is, good or bad or indifferent, established.

With Cisco in at AGNTCY, it's interesting to wonder/consider how much of the network (hardware or software defined) may actually be thinking in this regard, too.

So, to take this to perhaps the next level of absurd, there are likely models in biology (cellular & developmental, esp?) that could provide some very useful operational models and mental models that tend to have way more wisdom than us as humans can put in.

To put this relatively heady/nebulous few paragraphs into a finer point: I feel like a very concise set of requirements and stories in this could help frame a meta-discussion of sorts around the nature of data buses, purpose, and intention, because I think two buses may, perhpas not be enough, and bee is uniquely positioned I think to be opinionated on defining or codifying a lingua franca to define buses (that roughly map to agents or sets of agents) as more levels of things are fully automated (think: self-evolving/adapting systems where they may very well define their own buses). Does such a document/discussion exist?

[QuantGeekDev]

I need to take some time to read the above (very good, fun, and exciting) thread, what I have taken from my cursory first pass from the last week's updates or so is that I really like the distinction between the various buses, and perhaps this is an internal bias from earlier in my career where I began in networking (back in the circuit-switched days...think 53 byte cells, even! ATM, hahahaha....at IBM!), and in many ways, this is perhaps a greenfield set of problems, but the connections as a mental model (and not at all suggesting actual transport layer similarity at all) back to systems like Erlang, signalling protocols in circuit switched networks (as an analogue to stateful agents versus packet, specifically UDP, really, which are an analogue to stateless agents) continues to tug at me.

The amount of work telecom, energy, etc have put into the question of control planes, data planes, management planes, in band/out of band for all things from resource allocation, provisioning, audit, security, etc I feel like is a very useful body of work to reference for both what to do and not to do.

The question of clean slate (one extreme) and "nothing to invent here" (the other) is an interesting one without a singular answer. Which I also think is a reason you see k8s come up here a lot, because it tends to be one of the few well-adopted systems that converges this and is, good or bad or indifferent, established.

With Cisco in at AGNTCY, it's interesting to wonder/consider how much of the network (hardware or software defined) may actually be thinking in this regard, too.

So, to take this to perhaps the next level of absurd, there are likely models in biology (cellular & developmental, esp?) that could provide some very useful operational models and mental models that tend to have way more wisdom than us as humans can put in.

To put this relatively heady/nebulous few paragraphs into a finer point: I feel like a very concise set of requirements and stories in this could help frame a meta-discussion of sorts around the nature of data buses, purpose, and intention, because I think two buses may, perhpas not be enough, and bee is uniquely positioned I think to be opinionated on defining or codifying a lingua franca to define buses (that roughly map to agents or sets of agents) as more levels of things are fully automated (think: self-evolving/adapting systems where they may very well define their own buses). Does such a document/discussion exist?

Very insightful angle. Thanks for your feedback. Can you share some readings that you think will be relevant to read for participants of the discussions so we have a shared foundation? T he nature of what is trying to be built here is complex. There are many patterns that have been well defined, and I agree with you that it makes sense to consult from those first. There will also be unique nuances specific to LLM
Worfklows. We need to workshop a way to make the pairing of these elegant for developers to use, but powerful on the framework level. this
And now we have a new fighter joining us - llm coder assistants. I just witnessed first hand that HOW the framework is written, and how idiomatic it is, plays a big role in whether the LLMs can write code using your framework (without training or fine tuning, or ever seeing your framework before) or if they will halucinate parts of it. There are so many things to talk about! Are you on the BeeAI Discord? Sometimes an informal chat is faster to go through these topics. Once we have more work stream activity we should have more minds to weigh in on this

[matiasmolinas]

@QuantGeekDev Thanks, appreciate the feedback! I fully agree – the key is leveraging well-established patterns (like control/data planes you alluded to) while carefully adapting them for the specific needs of LLM agents.

Regarding readings for a shared foundation, that's a great call. It's a broad area, but I can definitely explore and consolidate some core concepts from relevant fields (distributed systems, maybe even complex systems) that seem most applicable to ACP and share those specific patterns/learnings here.

Your point on LLMs struggling with non-idiomatic frameworks is critical. I think this underscores why a clear, well-defined ACP is essential – it needs to be a solid target for both human and future AI developers. Testing how easily code can be generated to use ACP will be an important validation step, something I hope the POCs I'm working on can help explore..

Ultimately, my goal with (https://github.com/matiasmolinas/evolving-agents) is to provide practical validation for concepts like the dual bus, smart context, and capability handling, sharing those concrete findings back to help shape a robust ACP. Definitely joining the Discord for more discussion too!

[matiasmolinas]

Hi all, it's great seeing Google's A2A protocol released, which definitely reinforces the importance of the standardization work we're doing here with BeeAI ACP. I'm keen to contribute where I can, and I've been using my Evolving Agents Toolkit (EAT) project (https://github.com/matiasmolinas/evolving-agents) to explore some concepts discussed here. My aim is to build practical POCs and share the learnings and ideas back to this group for consideration as ACP develops.

Specifically, inspired by ideas shared here, including @ismaelfaro's suggestion, I'm exploring within EAT: 1) A dual communication bus (System/Data) to see if it helps clarify responsibilities; 2) "Smart Context" mechanisms to explore ways to manage context relevance for agent interactions, hopefully addressing some concerns like those @QuantGeekDev raised; 3) Capability-based discovery/routing; and 4) How a protocol might accommodate agent evolution. I think validating these concepts practically might offer useful patterns or data points for the ACP design discussions. My goal is simply to share these POCs and any resulting ideas that could potentially be used to improve or inform the final implementations within ACP, helping make it a powerful protocol for the complex use cases we envision.

I also agree it's useful to analyze efforts like A2A. By understanding different approaches, I believe we can ensure ACP offers unique value and strong interoperability, rather than just being a replacement. Connecting these efforts helps us build towards truly adaptive and collaborative agent ecosystems, using standards like ACP as the foundation. Looking forward to continuing the discussion and sharing more concrete POC results soon!

[matiasmolinas]

Just wanted to add a quick follow-up regarding the "Smart Context" point I mentioned earlier, especially in light of @QuantGeekDev's feedback on context relevance.

I came across this recent paper, RARE: Retrieval-Augmented Reasoning Modeling (https://arxiv.org/abs/2503.23513), which I think strongly reinforces the idea that simply retrieving potentially relevant documents isn't enough. RARE focuses on training models to reason better with given context, which inherently highlights the need for that given context to be highly relevant to the specific reasoning task at hand.

This aligns perfectly with the goal of the "Dual Embedding Strategy" POC within EAT – finding ways to improve the retrieval mechanism itself to deliver that task-specific context. I believe if ACP could incorporate or standardize patterns for such enhanced, context-aware retrieval (going beyond basic semantic similarity), it would be an amazing improvement and a significant differentiator, enabling more efficient and accurate agent collaboration. It directly addresses the need for better "thought" (reasoning) and better "learning" (relevant context), as discussed earlier.

Still focused on the POCs in EAT to explore this further and share findings!

[QuantGeekDev]

Thank for taking some time to answer @matiasmolinas . I'm a bit busy right now but I also wanted to point out that, as discussed on the call yesterday, it might make sense to replace the "Await" keyword with something that doesn't overlap with similar concepts in programming like the await keyword in js/ts. The LLM will be able to proccess the nuances of two different Await keywords, but we want to make it as easy as possibly for the llms and occupying a new keyword would probably be easier especially for LLMs that don't have ACP docs in their training corpus

[richardesp]

Hey all!

I've been reading through the proposals, and I think there's a lot of value being surfaced in this discussion. I’d like to contribute about the security, traceability, and workflow observability at scale, especially within a pure agent-based architecture.

Concept: Intent-First Agent Orchestration (Secure, Observable, and Human-Centered Agent Workflows)

Instead of allowing agents to immediately execute actions (e.g., via tools exposed through MCP), agents would propose their next actions in a structured, common language, which are:

• Logged and frozen into a workflow state graph. This model is conceptually similar to functional programming in distributed systems like Apache Spark. There, a user defines a set of lazy transformations that build up a DAG of operations (df.select(), df.filter() etc.), which can be explained and validated before triggering an actual execution (df.explain()). Likewise, in Intent-First Orchestration, agents propose steps that form a workflow DAG, which is logged, visualized, and only executed after human approval (df.show(), df.count(), etc.), offering full transparency and safety.

• Presented to a technical human expert for validation.

• Only then passed to an executor.

This shifts ACP-based systems from a default of “act immediately” to a more cautious, “plan first, act second (with approval)” approach.

---

Why This Matters: Security by Design

From my point of view, MCP-based integrations are powerful but also open up real-world vulnerabilities that ACP could mitigate by design:

• Tool Poisoning: An agent may (unintentionally or maliciously) invoke a compromised or deceptive tool.

• Data Leaks: Agents could propose actions that expose sensitive customer data via third-party endpoints.

• Lack of Traceability: Classic MCP flows make it difficult to reconstruct what could have happened before it actually does.

By introducing a frozen intent-review model, we get:

• Complete oversight of planned agent behavior before it touches real systems

• Approval gates for high-risk or compliance-sensitive contexts (e.g., finance, legal, healthcare)

• Audit logs for not just what was done, but also what was proposed, by whom, and why

---

Architectural Flow

flowchart TD
  A[Agents] --> B[ACP Message Proposals]
  B --> C[Intent Coordinator<br/>- Builds FSM or DAG<br/>- Validates dependencies<br/>- Converts to structured Intent Language]
  C --> D[Human Review Layer<br/>- UI for workflow approval<br/>- Optional annotations]
  D --> E[[Execution Begins Only After Approval]]

Loading

---

Example Intent Proposal

{
  "intent_id": "step-004",
  "agent": "PlannerAgent",
  "action": "send_summary_to_customer",
  "params": { // MCP Current parameters definition
    "email": "[email protected]",
    "content_ref": "step-003-result"
  },
  "justification": "End of report flow",
  "depends_on": ["step-003"]
}

Instead of, executing this action immediately, the system would add it to a proposed workflow queue, modeled as a finite state machine or DAG. The human reviewer could inspect, approve, edit, or reject the plan before any real-world execution occurs.

---

Would Love Feedback On:

• Security/observability trade-offs of this model

• Whether ACP should formally support this kind of intent-centric extension

• How it could fit alongside existing ideas like agent manifest declarations, tool providers, and offline discoverability

Looking forward to hearing your thoughts and continuing the conversation 😄

[matiasmolinas]

This is an amazing proposal, thanks for sharing! I completely agree that introducing an "Intent-First" model focused on security, observability, and human oversight is a crucial consideration for robust agent systems, especially in enterprise contexts. I think this approach addresses key vulnerabilities that purely reactive or autonomous systems might face.

Your concept resonates strongly with the direction I've been exploring in the my POCs (https://github.com/matiasmolinas/evolving-agents ... EAT). Specifically:

• Structured Planning:SystemAgent already generates internal, structured workflow plans (currently YAML, using GenerateWorkflowTool / ProcessWorkflowTool) when tackling complex goals. Your proposal to externalize and "freeze" this plan for review aligns perfectly – the plan itself serves as the observable DAG you described.
• Agent-Centric Orchestration: This fits well. In my project, the SystemAgent would naturally be the component to generate this intent-based plan and later execute the approved steps using its tools (like RequestAgentTool).
• Foundation for Intent Structure: EAT's existing step definition (type, name, input, etc.) could serve as a practical starting point or mapping reference for the standardized JSON intent structure you propose ACP could define.

The crucial enhancement you propose – the 'Intent -> Review -> Execute' model with a human validation gate – is something not yet explicit in my POCs autonomous flow, but I think it's a highly valuable addition, especially for critical domains. This is definitely something I'm now planning to explore and prototype within EAT, perhaps by adding an optional mode to the SystemAgent where it outputs the generated plan as "intents" and awaits an "approve" signal before execution. My goal here is to use the POCs on EAT as a practical testbed to validate the feasibility of plan generation (sharing insights on prompts/structure), demonstrate how an "executor" agent operates on such plans, and evaluate the real-world trade-offs of this review step. Ultimately, I hope the findings from these POCs can provide concrete data and patterns to help inform how ACP might best standardize intent representation, review mechanisms, and related lifecycle management, if the results prove effective and make sense.

[matiasmolinas]

Further to my comment above about exploring the 'Intent -> Review -> Execute' model within EAT, I've opened this specific issue to track that POC effort:

matiasmolinas/evolving-agents#95

The goal is to validate the approach practically there. If it works well and the results make sense, I'll use those findings to refine a potential contribution/proposal for how this concept might be incorporated into ACP.

[richardesp]

Thanks so much for the thoughtful reply, @matiasmolinas 😄

It’s exciting to see that the Intent → Review → Execute concept aligns so well with the direction you’re already exploring in EAT. The idea of having the SystemAgent act as both planner and executor with an approval gate really makes sense from my perspective.

I’ll definitely be following the POC! I’m also planning to work on a simple step-state enqueueing protocol based on a DAG model from LLM outputs, inspired by some of the concepts discussed around ACP. Would be great to stay in touch. Happy to collaborate if it’s helpful!

[danindiana]

1. Understanding ACP Workstreams: The discussion highlights various workstreams like handling stateful/stateless agents, agent discovery, data encoding, and communication protocols. These are foundational elements of the ACP framework.

2. Kubernetes Integration: There's a strong emphasis on Kubernetes as the deployment platform for agents, with discussions around RBAC, Helm charts, Istio policies, and service accounts. This suggests that ACP aims to leverage existing cloud-native technologies.

3. Security Concerns: The conversation touches on OAuth 2.1, capability-based security models, and agent authentication/authorization. These are critical aspects of multi-agent systems where trust and data privacy are paramount.

4. Agent Communication Protocols: Various communication methods like WebSockets, HTTP, peer-to-peer, and vector embeddings are considered. The choice depends on the use case, performance requirements, and security considerations.

5. Lifecycle Management: Agent creation, health monitoring, retirement, and resource reclamation are discussed. This lifecycle management is essential for maintaining a healthy agent ecosystem.

6. Capability-Based Design: There's a strong focus on defining agent capabilities as interfaces, which allows for dynamic discovery and interaction based on what agents can do rather than how they do it.

7. Contribution to ACP:

8. Kubernetes Integration:

spec: {
  k8s-deployment-agent: {
    rbac-policies: {
      agent-identity: "k8s-agent",
      capabilities: ["vector-embeddings", "peer-to-peer"]
  }
}
</thinking>
<answer>
The ACP (Agent Platform) discussion revolves around various key elements, which are summarized as follows:

1. **Kubernetes Integration**:
```yaml
spec: {
  k8s-deployment-agent: {
    rbac-policies: {
      agent-identity: "k8s-agent",
      capabilities: ["vector-embeddings", "peer-to-peer"]
  }
}
</thinking>

2. **Security Models**
```yaml
spec: {
  oauth2.1-agent: {
    capability-based-security-model: {
      agent-identity: "mcp-agent",
      capabilities: ["vector-embeddings", "peer-to-peer"]
  }
}
</thinking>

3. **Communication Protocols**:
```yaml
spec: {
  communication-protocols: {
    vector-embeddings: ["agent-to-agent"],
    peer-to-peer: ["agent-to-agent"],
    capabilities: ["dynamic-discovery"]
  }
}

[amitsides]

I liked that you added the "vector-embeddings" capability to the YAML which I previously remarked is important and Google Ignored in their A2A JSON Schemas

https://github.com/google/A2A/blob/main/specification/json/a2a.json
https://github.com/google/A2A/blob/main/samples/python/common/types.py#L331

Specifically their AgentCard Pydantic:
defaultInputModes: List[str] = ["text"]
defaultOutputModes: List[str] = ["text"]

class AgentCard(BaseModel): name: str description: str | None = None url: str provider: AgentProvider | None = None version: str documentationUrl: str | None = None capabilities: AgentCapabilities authentication: AgentAuthentication | None = None defaultInputModes: List[str] = ["text"] defaultOutputModes: List[str] = ["text"] skills: List[AgentSkill]

They do support RPC however
https://github.com/google/A2A/blob/main/samples/python/common/types.py#L147

[OpenMedFuture]

MCP and A2A got massive attention. Will IBM join MCP?

[matiasmolinas]

Hi @deghislain,

Thanks so much for the detailed and insightful comment! It's fantastic to hear you're experimenting with EAT and finding the orchestrated approach compelling.

Your analysis is spot on. The shift from thinking about direct, human-like peer-to-peer chat between agents to a more structured, orchestrated model (like EAT aims for with SystemAgent and the SmartAgentBus) is a key step towards building robust and manageable multi-agent systems. As you noted, orchestration provides better control, simplifies state management (especially with shared context for internal components), and enhances modularity.

You've also perfectly identified one of the critical challenges in real-world applications: integrating external agents (like your WriterAgent example hosted by another company). Your observation about the limitations of shared context across security or system boundaries is absolutely correct. Direct memory access is impractical and often insecure in such scenarios.

Your proposed solution – having the orchestrator (EAT's SystemAgent) communicate with the external agent via secure protocols like HTTPS, sending a self-contained prompt/payload, receiving the result, and then updating the internal shared context – is exactly the standard and recommended approach for building these hybrid systems.

The SearchAgent -> External WriterAgent -> ReviewerAgent scenario you outlined is an amazing, concrete example of the complex, heterogeneous workflows that production multi-agent systems need to handle. These are precisely the types of real-world challenges I believe a framework like EAT (and potentially a future BeeAI ACP) must effectively address.

Commitment to Implementation & A2A Evaluation: Because this scenario is so fundamental, I'm committed to implementing the necessary features in EAT this week to fully support this type of external agent interaction. This will likely involve refining the Provider system and potentially adding specific tools or configurations within the SystemAgent.

As part of implementing this external agent scenario, I will also be deeply evaluating Google's Agent2Agent (A2A) protocol, [structure you shared](link to A2A dir structure if available)) as the potential mechanism for this integration. A2A seems designed for exactly this type of interoperability. If it proves to be a good fit during this implementation work – providing a standardized way for EAT's SystemAgent to call external services and potentially for EAT agents to be called externally – I will integrate core A2A client/server concepts as part of this development cycle. My goal is to leverage standards where they make sense to enhance EAT's connectivity, rather than immediately inventing a completely separate protocol.

Regarding the LinePrefixParserError:
Thanks for reporting the LinePrefixParserError: ... Transition from 'thought' to 'thought' does not exist! You're right, this comes from the underlying BeeAI framework's ReAct parser when the LLM doesn't strictly follow the expected Thought->Action->Observation sequence and outputs two thoughts consecutively. I understand this can be disruptive. I'll be addressing this directly in EAT this week by implementing more robust error handling and potentially retry logic within the agent execution loop to catch and recover from these schema violations more gracefully.

Contributing Back to ACP:
My goal is to use the practical implementation of this external agent scenario within EAT, along with the findings from evaluating A2A integration, to formulate a concrete design proposal. I plan to contribute this back to the BeeAI ACP discussions as a potential architectural pattern for handling interoperability and complex orchestrations within the ACP framework.

Thanks again for your fantastic feedback and the valuable real-world scenario – it's incredibly helpful for driving the practical development of EAT! I'll keep the community updated on the progress this week.

[matiasmolinas]

I've created a dedicated issue to track this week's focused effort here: matiasmolinas/evolving-agents#99. I'll share the findings and the resulting design patterns back here as a potential contribution to the ACP architecture discussions.

[deghislain]

Hey @matiasmolinas I appreciate your prompt response to my previous inquiry. Recently, while grappling with the error I previously mentioned, I've had an innovative idea that I'd like to explore. Although its feasibility is uncertain, I believe we could revolutionize our approach to logs by adopting a blockchain-like model.

In the context of multi-agent systems, what if we viewed logs as a decentralized ledger, where each agent maintains its own copy and
contributes to the collective update in near real-time? This concept has great potential for fostering trust among agents from different companies. By sharing information and leveraging this shared ledger, we could establish a more secure and collaborative environment.

This approach could also enable autonomous agent activation, agents could automatically initiates tasks as soon as the ledger has all the necessary information.

I invite anyone in this group to share its thoughts about this crazy idea because I believe it involves too many expertise that I do not have, so feel free to challenge or criticize it.

[matiasmolinas]

Hey @deghislain , this is a fascinating idea! I love the concept of leveraging a blockchain-like model to foster trust and collaboration across agents from different companies. Here are two simple but high-impact proposals we could explore right away:

1. Tamper-Evident Logging (Proof of Existence)

Immediate Value

• Verifiable History: We get a cryptographically verifiable, append-only log that exposes any attempts at tampering.
• Trust Between Stakeholders: Different teams or organizations can be sure that logged entries haven’t been altered behind the scenes.

Easy Implementation Approach

• Off-chain Data + On-chain Hash: Keep the full logs in a normal database or file system. For each log entry (or a batch of them), record the corresponding hash on a simple permissioned blockchain (e.g., Hyperledger Fabric, Quorum).
• Incremental Changes: This method minimally disrupts existing workflows—you only store small hash transactions on-chain.
• Proof of Integrity: In case of disputes, anyone can verify that the original log data matches the hash in the blockchain.

2. Lightweight Reputation Scoring

Immediate Value

• Transparent Performance Records: Agents or companies can share a straightforward reputation or performance metric without giving away sensitive details.
• Rapid Onboarding: New participants see at a glance how reliable an agent is, based on past performance aggregated on-chain.

Easy Implementation Approach

• Permissioned Ledger: Each participant (company/agent) runs or accesses a node.
• Periodic Updates: Agents submit feedback or performance ratings as minimal transactions.
• Simple Smart Contract: A small contract calculates an aggregated score (e.g., an average rating).
• Off-Chain Details: Detailed logs or feedback remain off-chain for scalability and privacy, while the score itself is tracked on the ledger.

They’re easy to prototype and demonstrate immediate value—especially around trust and auditability. Over time, we can extend this to more advanced use cases like fully decentralized coordination or event-driven agent activation via smart contracts. But starting small ensures we get quick wins without adding massive overhead.

Additional Note: I ran this idea through an AI analysis tool to get a second opinion, and the outcome strongly supports these two simple, initial blockchain use cases. It reinforces that they offer immediate trust benefits and are straightforward to integrate. The result totally makes sense to me!

I’m quite busy right now due to other ongoing ideas and proposals, but in about a week or two I plan to revisit and explore these blockchain-based approaches more deeply. Excited to see where this takes us!

[matiasmolinas]

I've created an issue for this POC : matiasmolinas/evolving-agents#100

[csantanapr]

Just want to point out that the term ACP which I agree generic overlaps with other initiatives like the one CNOE.io is working with CISCO in AGNTCY is there a way to collaborate on these agent to agent communication?
Here is an article on ACP https://outshift.cisco.com/blog/mcp-acp-decoding-language-of-models-and-agents

[geneknit]

Thanks for flagging. We've were with the AGNTCY folks a few weeks back. Unfortunately we both had already spoken publicly about ACP when we were made aware of the other ACP. I'm not super concerned about the collision of the acronym as this is a rapidly evolving space.