Home

Awesome

<h1 align="center"> <img height="420px" src="./assets/cover.png" alt="agent protocol"> </h1> <p align="center"> <a href="https://discord.gg/bJnNh666C3" target="_blank"> <img src="https://img.shields.io/static/v1?label=Join&message=%20discord!&color=mediumslateblue"> </a> <a href="https://twitter.com/e2b_dev" target="_blank"> <img src="https://img.shields.io/twitter/follow/e2b.svg?logo=twitter"> </a> </p>

๐Ÿ“š Docs

You can find more info in the docs.

๐Ÿงพ Summary

The AI agent space is young. Most developers are building agents in their own way. This creates a challenge: It's hard to communicate with different agents since the interface is often different every time. Because we struggle with communicating with different agents, it's also hard to compare them easily. Additionally, if we had a single communication interface with agents, it'd also make it easier developing devtools that works with agents out of the box.

We present the Agent Protocol - a single common interface for communicating with agents. Any agent developer can implement this protocol. The Agent Protocol is an API specification - list of endpoints, which the agent should expose with predefined response models. The protocol is tech stack agnostic. Any agent can adopt this protocol no matter what framework they're using (or not using).

We believe, this will help the ecosystem grow faster and simplify the integrations.

We're starting with a minimal core. We want to build upon that iteratively by learning from agent developers about what they actually need.

๐Ÿš€ The incentives to adopt the protocol

๐ŸŽฏ Immediate goals of the protocol

Set a general simple standard that would allow for easy to use benchmarking of agents. One of the primary goals of the protocol is great developer experience, and simple implementation on the end of agent developers. You just start your agent and thatโ€™s all you have to do.

๐Ÿ—ฃ๏ธ Request for Comments

If you'd like to propose a change or an improvement to the protocol. Please follow the RFC template.

โš™๏ธ Components

Protocol

The most important part. It specifies which endpoints should the agent expose. The protocol is defined in OpenAPI specification.

How does the protocol work?

Right now the protocol is defined as a REST API (via the OpenAPI spec) with two essential routes for interaction with your agent:

It has also a few additional routes for listing the tasks, steps and downloading / uploading artifacts.

SDK

This is our implementation of the protocol. Itโ€™s a library that you can use to build your agent. You can use it, or you can implement it on your own. Itโ€™s up to you.

Using the SDK should simplify the implementation of the protocol to the bare minimum, but at the same time it shouldn't tie your hands. The goal should be to allow agent builders to build their agents and the SDK should solve the rest.

Basically it wraps your agent in a web server that allows for communication with your agent (and in between agents in the future).

Client

This library should be used by the users of the agents. Your agent is deployed somewhere and the users of your agent can use this library to interact with your agent.

Thanks to the standard the users can try multiple agents without the need for any additional adjustments (or very minimal) in their code.

๐Ÿ“ฆ How to use the protocol

If you're an agent developer, you can use the SDK to implement the protocol. You can find more info in the docs or in the SDK folder.

๐Ÿค— Adoption

Engaged projects in development of agent protocol

Open-source agents and projects that have adopted Agent Protocol

๐Ÿ“ƒ High-level future roadmap

๐Ÿ’ฌ Public discourse & development