ACP (Agent Communication Protocol)

[ismaelfaro]

[Updates]

Alpha documentation is here! 👉 https://agentcommunicationprotocol.dev/

---

[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 agentstack#344

[matoushavlena]

@AndrewRentschler Thanks for the inspiration. We tried to incorporate some of the ideas into the new version of ACP. Specifically:

• Role type - can be expressed as "tags" with a predefined list of enums, extensible (https://agentcommunicationprotocol.dev/spec/agents-get)
• Agent lifecycle management (https://agentcommunicationprotocol.dev/core-concepts/agent-lifecycle#run-states)

FYI ACP is still trying to stay lightweight and driven by real use cases. Therefore we pretty much just scratch the surface of your proposal. But happy to continue the discussion. Security, capabilities, and trust are some of the next topics we want to tackle.

[jindong-ibm]

@matoushavlena Thanks much for sharing the updates.

I take a look of agent lifecycle, with couple questions:

1. Generally an agent will include multiple tools, so how do we define "error encountered" fails? if one tool fails (and other tools work), do we count agent fails?
2. Many AI agents have "human-in-the-loop" support: if an escalation (engaging human agent who is not end user) needed, what state will it be?

Thanks.

[deghislain]

Good point @jindong-ibm. I would like to share some of my experiences to illustrate how interesting is this point.

1. I had an agent with multiple tools, that agent failed to call the tools in the right sequence and return a response that was a kind of hallucination.
2. I had another agent with 3 tools:
   -Tool one was a function that makes an API call to retrieve stock data from a specialized website given a stock symbol.
   -Tool 2 was a search tool that retrieve information from the web about a given stock
   -Tool 3 was a tool that convert a markdown document into a PDF file
   When I launched my agent, tool one failed because I reached my max number of calls from the stock website for that specific day. However, the other tools worked correctly and my agent was able to return a report. I understand that, that report was not complete but I still got my report.

To conclude I believe my first experience is a case of agent failure but I do not think my second experience can be fairly classified as agent failure.
I also believe that in the context of multi-agent an agent may fail because it did not receive the right information from the other agent(Let just say the other agent he interact with hallucinate).

[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.

[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": "alice@example.com",
    "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!

[matiasmolinas]

Okay, this is the initial POC implementation doc along with the example POC . I’ll review and improve them next week. Thanks!

[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.

[matiasmolinas]

🚀 Proposal: ACP Improvement Proposal (ACPI) Process

I’d like to suggest a lightweight, inclusive “Proposal + Vote + Champion” model to turn ACP ideas into real, future‑proof features—one that empowers every contributor to propose, decide, and implement:

---

📣 1. Submit a Proposal

1. Open a new thread in Proposals (or create that category).

2. Use this template to focus discussion:

   ## Title  
   One‑line summary of the feature.
   
   **Motivation**  
   Why this matters for ACP.
   
   **Specification**  
   Sketch of API, data model, or architecture.
   
   **Implementation Plan**  
   Who’s championing it & how you’d tackle it.
   
   **Drawbacks / Open Questions**  
   Points for the community to weigh in on.

---

💬 2. Discuss & Vote

• Iterate the proposal for up to 2 weeks.
• Signal support with 👍 and concerns with 👎.
• Proposals with ≥ 10 net 👍 become Accepted.

---

🏅 3. Champion & Deliver

• The original proposer becomes the champion and opens a PR within 2 weeks of acceptance.
• If they can’t, they hand off the champion role—so no idea ever stalls.

---

🔗 Aligning with ACP Work‑streams i-am-bee/beeai-platform#488

Stream	Example ACPI Topics	Tag
1. Architecture & Core Protocol	Dual‑bus split, capability‑manifest schemas	#stream-1-arch
2. Deployment & Infrastructure	Gossip membership, hierarchical supervisor model	#stream-2-infra
3. Data Security & Privacy	Capability‑token designs, tamper‑evident logging	#stream-3-sec
4. Protocol Implementation & Encoding	New transport enums, Streamable‑HTTP vs WebSocket	#stream-4-impl
5. Testing & QA	Mock‑tool simulation harness, determinism suites	#stream-5-test
6. MCP Integration & Compatibility	Internal vs external comms guidelines	#stream-6-mcp
7. UI & UX	Control‑plane dashboard prototypes	#stream-7-ui

Tag your ACPI with the relevant stream label so our facilitators can triage effectively.

---

🏁 Next Steps

1. Create the Proposals category (if it doesn’t exist).
2. File your first ACPI today—anyone can do it!
3. Discuss improvements to this process right here if you have a better idea.

---

🙏 Thank you! Please share your thoughts and suggest ways to improve this proposal so we can make ACP even stronger together.

[geneknit]

@matiasmolinas thanks for the proposal. When you say a new thread do you mean a single discussion? ACP Proposals?

[matiasmolinas]

Hi @geneknit — yes, I meant a single discussion thread for each proposal, ideally within a Proposals category (once created). The idea is to give the community a focused space to discuss and provide feedback on each ACPI. That way, it's easy to track the evolution of the proposal, gather input, and signal support. this is just a starting point—an initial proposal to get the conversation going. If there's a better structure or another approach that works more effectively, we can definitely go with that instead!

[geneknit]

A got it. So maybe we make the category very specific ACP Proposals as this is the current list and almost everything right now under "Ideas"
Since Ideas is very similar to Proposals, this would give ACP proposals a specific space. Sound good?

[matiasmolinas]

@geneknit Sounds perfect!

[ismaelfaro]

Thanks @matiasmolinas to help in this initiative.

[jindong-ibm]

@ismaelfaro @geneknit and all,
I am currently following some open protocols for multiagent communication. I see all excellent and valuable discussions here.
Several topics I think of, which I did not see specific discussions (apologize if I missed some), I put here:

1. Related to "Architecture & Core Protocol Design" or maybe "Protocol Implementation & Encoding": when thinking of data flows and communications cross multiple agents, we also need to think of data mapping. Since different agents, tools may have different data formats, cross agents/tools data mapping will be important. Some simple data mapping, for example different timestamp formats, may be handled by agent LLM, but other business specific data mapping may need special handling and protocol.
2. Related to "Deployment & Infrastructure": To automate a business operation end to end generally needs multiple agents work together. In addition to current discussions, wonder if we need to think of multiple agents co-location, ex-location and related topics to give multiagent data operations/flows an optimized resource usage and performance.
3. Related to "Agent discovery", in addition to "Capability-based", wonder if we shall also think of agent-agent relationships, like human.

Thanks.

[matiasmolinas]

Okay, let's refine the Agent-LLM relationship section with your added perspective. Here's the updated full response:

---

Hi @deghislain,

Wow, thank you so much for sharing that detailed experience! Your story about the 2B vs. 70B models with ReAct vs. ToolCalling is a perfect real-world illustration of the differences we were discussing based on the prompt structures.

Your observation that the ReActAgent added "noises to the context" that confused the 2B model makes complete sense when you look back at the ReAct prompt definition. It mandates those Thought:, Function Name:, Function Input:, Function Output: steps as part of its output stream. For a smaller, less capable model like a 2B parameter one, parsing and staying focused amidst that explicit, structured reasoning output can indeed be challenging, leading to confusion or deviation. The larger 70B model likely had the capacity to handle that verbosity and follow the structured interaction correctly.

Switching to ToolCallingAgent improved things because, as the analysis showed, its prompt focuses on getting to the final_answer and relies more on the LLM's built-in function-calling capabilities (which are often optimized) for the intermediate steps, leading to a potentially cleaner interaction flow, especially for the LLM itself. This directly validates the idea that the agent's architectural design (driven by its prompts) is a critical factor alongside the LLM.

Regarding the Agent-LLM relationship:

• Your analogies are thought-provoking! Here's how I see the distinction evolving based on our discussion:

  • LLM: The core reasoning and comprehension engine. Given instructions (prompts), context (history, data), and descriptions of available tools, the LLM provides the "understanding" of what needs to be done and how it can potentially be achieved using those tools. For tasks involving pure logic, text transformation, or summarization based on provided context, the LLM might handle it directly using its inherent capabilities. It's the "brain" supplying the intelligence, comprehension, and initial planning capability.
  • Agent Framework (Prompts + Code): The structured execution and interaction layer. It takes the LLM's comprehension and plan and provides the mechanism to actually act in the world beyond simple text generation. The agent framework becomes essential when the plan requires:
    • Interacting with external components: Calling tools, APIs, databases, or even other agents.
    • Delegating specific sub-tasks: Orchestrating actions across multiple capabilities.
    • Utilizing memory: Interfacing with external memory systems (which might themselves be treated as tools) to persist or retrieve information beyond the immediate context window.
    • Executing complex plans: The agent framework manages the step-by-step execution of a plan formulated or understood by the LLM, feeding back results and allowing the LLM to adjust course based on its comprehension of the progress. It's the "nervous system and limbs" connecting the LLM's brainpower to actionable capabilities and managing the flow of complex processes.

• So, the LLM provides the "thought" and "understanding," deciding which tool fits the current step based on its comprehension of the goal and tool descriptions. The agent framework provides the structure and capability to execute that tool call, handle its response, manage memory, interact externally, and potentially enforce a specific interaction pattern (like ReAct's explicit steps vs. ToolCalling's more direct function invocation). ToolCalling frameworks often abstract more of the execution mechanics, relying heavily on the LLM's native function-calling intelligence coupled with the underlying code bindings.

Lastly, your question: "Why the ReActAgent reasoning steps are sent back as output... why don't just log them and only return the final answer?"

• This is the core design philosophy of the ReAct (Reason + Act) pattern! The explicit output of Thought -> Action -> Observation is intentional:
  1. Transparency & Debuggability: It makes the agent's reasoning process completely visible. You can see why it chose a specific tool or action, making it much easier to debug when things go wrong.
  2. Improved Reasoning (Chain-of-Thought): Forcing the LLM to articulate its thought process step-by-step before acting can often lead to more robust and accurate reasoning, especially for complex, multi-step tasks.
  3. Statefulness in the Loop: Each Thought: can build upon the previous Observation: (Function Output), allowing the agent to maintain context and adjust its plan iteratively within the conversation history.
• The downside, as you discovered, is that this verbosity can be "noise" for simpler models or if the context management isn't designed to handle it well. ToolCalling approaches essentially trade some of this explicit transparency for potentially simpler interactions and cleaner final outputs, assuming the underlying LLM/framework can handle the intermediate steps effectively behind the scenes.

Your experience perfectly highlights these trade-offs! Thanks again for sharing, it's incredibly valuable for understanding how these different agent architectures perform in practice.

(P.S. I used AI assistance to help refine and articulate some of my ideas in this comment for clarity.)

[deghislain]

@matiasmolinas thanks a lot, I understand now.

[matiasmolinas]

Hi @deghislain, I am working on an example (in my POC toolkit) based on the amazing case you described: matiasmolinas/evolving-agents#106. Please give me a day or two to complete it and discuss it. Thanks!

[jindong-ibm]

@matiasmolinas @deghislain
What a great discussion! Thank you Matias for the insightful details.
I'm interested in your "the evolving agents toolkit." Based on discussions above, I initially thought it about agentOps — continuously monitoring and improving agent behavior. However, after reviewing your GitHub repository, I realized it’s more about agents evolving in relation to the ecosystem, business needs, and beyond.
Personally, I believe both aspects are closely connected in the real world — any IT solution must account for both business and technology evolution.

[deghislain]

great

[deghislain]

@jindong-ibm Right I feel the same way too. Sorry I got excited by the topic. How can I reach out to you directly?

[jindong-ibm]

@deghislain my linkedin: https://www.linkedin.com/in/jingdong-sun-1537a7a/

[deandebeer]

This initiative is great to see and much needed, especially with the pace at which everything is evolving.

Not sure if this is helpful but I put together a spec a while back and put it up about a month ago, for how I'd build something similar to what is being proposed here by using existing technologies and infrastructure. This was an exercise for thinking through how we'd implement these capabilities but the concepts might be applicable here too.

https://github.com/zerocmd/acdp/blob/main/ACDP.md

The protocol defines a standardized system for LLM-based agents to advertise their services, discover each other, and communicate securely across networks. Key components include: 1) Discovery Mechanism using DNS and central registry, 2) Peer Awareness through gossip-like protocols, 3) Metadata Schema for structured capability sharing, 4) Security Framework with multiple protection layers, and 5) Communication Protocol over HTTPS with RESTful APIs. Recent updates added private registry deployment, split DNS configuration, Model Context Protocol (MCP) integration, and improved security for sensitive environments.

[playground]

I have been dabbling with MCP recently and I have just stumbled on to this ACP discussion. This is exciting and a much needed for the agentic ecosystem. I would love to learn more.

I'm also particularly interested in item #10 deployment strategies for agents. I have been working with Open Horizon https://github.com/open-horizon another open-source project by IBM that focuses on managing deployment and workload placement for containerized applications/services autonomously based on policies. I believe there are potential opportunities for collaboration there. Any thoughts?

[alessandrocornacchia]

Hi @playground I am also interested in this topic. As agents could be fundamentally seen as microservices with negotiable and flexible execution semantics, I also believe there are ample opportunities for revisiting old problems (e.g., placement) with new lenses. Happy to chat more on this

[playground]

Hi @alessandrocornacchia, that's great. Let's find sometime for us to huddle.