☂️ `agents-sdk` roadmap

[threepointone]

• [x] http/websockets
• [x] scheduling
• [x] this.state
• [x] rpc
• [x] email
• [x] browser
• [x] mcp
• [ ] third party services/adapters/connectors
• [ ] built in sync engine client/server (for implementing full stack ai agents)
• [ ] evals
• [x] multi-agent architecture
• [ ] "admin" panel, a ui for managing and deploying agents
• [ ] self hosting guide
• [ ] docs site

maybe

• [ ] cli (to automate stuff like migrations, workflow provisioning, etc)
• [ ] import {Agent} from "cloudflare:workers" / agents in wrangler.json
  • letting Agent be baked into the runtime/platform will let us do interesting things with it on the network, like running them in low cpu util
• [ ] python
• [ ] codegen / wfp / "cockpit"

[rita3ko]

should we add browser rendering to list? also ability to easily integrate MCPs?

[threepointone]

done!

[GitTom]

Cloudflare Agents sounds terrific. Congrats!

In reading the roadmap, do I understand correctly that the items above the 'maybe' heading are definitely planned, and therefore very likely? Can you give any further information about confidence and schedule for Python support?

[threepointone]

ok I moved python down to "maybe" 😅 it needs durable objects support in python workers, and I don't have any insight into our plans for that just yet (I simply don't know, I haven't spoken to the team about it yet)

[GitTom]

Ok, that's too bad, but thanks for fast response and clarity. I will watch this space for updates - when I said your product sounds terrific I really do mean it so hope you are able to add Python support!

[threepointone]

I hope so too!

[cosbgn]

My biggest request for this is avoiding specific fronted libraries, like agents-sdk/react. This creates a situation where you would endup needing to mantain 20 different frameworks and like with the ai-sdk many features would only be available on react and not vue and creates disparity between them.

A much better solution in my opinion is a simple typescript SDK with examples on how to use it with react,vue,svelte,etc. This guarantees that all features are available to all users and it simplifies maintenance a lot.

OpenAI does a great job with streaming helpers and chat events

You simply have:

.on('message');
.on('toolCall')
.on('chunk'); etc etc 

Then the user can decide what to do with the message, chunk, etc.

As long as you have good events you would cover 99.9% of frontend needs without actually needing to integrate with every single front-end

[threepointone]

agents-sdk/react is not specific to ai-sdk, it connect directly to a regular Agent class. and there's a framework agnostic version at agents-sdk/client.

/ai-chat-agent and /ai-react are specific to ai-sdk tho. maybe we should spin that off later.

I agree it might be confusing. I'll think about it

[Disturbing]

I think using multiple packages as examples (admin dashboard, react-client, etc) all in one place is ok. Maintaining them all will be tough though over time, so being selective on what to bring in and maintain (and move the package out to its own repo when deprecated) would be my suggested approach from @cosbgn comment.

--

Any thoughts on using something like prisma ORM / schema for generating the tables and applying migrations?

https://developers.cloudflare.com/d1/tutorials/d1-and-prisma-orm/ - I've been using it and its been working quite nicely. If so, I can do a PR for the current schema state => prisma as an example.

--

Thoughts on email and browser being tools versus first class citizens? I'm wanting to create a tools repository for this project and expand it into a cloudflare platform for platforms project in the coming weeks. Ideally I'd see a few things:

1. Tools to process prompts
2. Clients to process messages.

IE: if we want emails from the email gateway api, it would be a client we enable to start receiving it. Same for messages via restful (ie: chat) or realtime (ie: websockets) or discord (ie: discord-webhooks / websockets depending on flavor). This may be the third party services/adaptors/connectors?

--

Regarding docs site, isn't that cloudflare's docs or is that separate? https://developers.cloudflare.com/agents/api-reference/sdk/

--

I'm available to contribute a majority of my time on this as I can see it being core to my project - Happy to setup a weekly sync (mornings UK time 8-10 AM)

[marbemac]

I see self-hosting guide mentioned in a bunch of spots - piqued my interest! As far as I understand, agents is built on durable objects, which are Cloudflare specific? Or maybe I am misunderstanding - what do ya'll mean by self hosting?

[xcaptain]

I don't use react, I use sveltekit, is there a useAgentChat equivalent I can use in svelte framework? how about rewrite useAgentChat in plain typescript code so any frontend framework can use it to interact with the agent server

[kentcdodds]

While we're waiting for the docs site to happen, is there any chance we could get an example of an MCP server in the README?

[elithrar]

@kentcdodds - see the examples/ folder - specifically: https://github.com/cloudflare/agents/tree/main/examples/mcp

[elithrar]

And: https://developers.cloudflare.com/agents/model-context-protocol/mcp-agent-api/

cc @dinasaur404 here - we need to bring more into the main docs to improve discovery.

[kentcdodds]

Thanks! Would be great to include at least a reference to mcp in the readme

[Gyurmatag]

@threepointone @cmsparks @kentcdodds I see that the "multi-agent architecture" feature is still in progress. My current understanding is that you can call a specific agent or an agent's method based on this docs like this:

let namedAgent = getAgentByName<Env, MyAgent>(env.MyAgent, 'my-unique-agent-id');
// Call methods directly on the Agent, and pass native JavaScript objects
let chatResponse = namedAgent.chat('Hello!');

We can implement basic routing and delegation logic manually within our agents (as shown in the code example), but this is more of a workaround than a fully supported multi-agent orchestration feature.

We should need for example the useAgentChat hook to support a list of agents that can work together.

useAgentChat({
    [softwareDeveloperAgent, testerAgent],
    maxSteps: 10,
  })

For example in one chat interface if the user want to do some coding, than the orchestratorAgent (defined by the user or built in) can delegate our request for the softwareDeveloperAgent and after that when it finished the testerAgent will take over to test the feature. Ff course with each agents calling the right MCP toolset which is defined for them.

Is this what you trying to build within "multi-agent-architecture" or am I completely wrong about this?

Thank you very much for your response!