Transcript
Manju Rajashekhar: I'm Manju Rajashekhar. I started my career more than a decade ago at Twitter where I helped solve the fail-mail problem. At that time, I worked on distributed caching and I was also a prolific open-source contributor around that time. A lot of the software that I wrote and open sourced around that time is still used today at companies like Uber and Wikipedia to scale your caching systems. GCP and Azure documents it as a reference implementation for designing your caching systems for scale. After Twitter, I ended up founding a company in the deep learning and search space. Our product was search as a service and recommendation as a service. That company was acquired by Etsy, where I spent eight years as a VP of engineering. I ran all of their AI and machine learning functions that included search, ads, recommendation, and personalization engine. Most recently, I started a company called Mad Labs with a couple of really wonderful colleagues of mine. We are an agentic platform company focused on building agents that have reliable execution over long horizons and they're very token efficient and have a strong governance structure around it.
Today, I'm really excited to talk about the topic, which is actors for agents. When I was putting together this talk and I was researching this topic, I realized that surprisingly not much was spoken about this topic, which to me felt crazy because I believe that the actor model or the actor style design fits really well to the runtime of agent existence. My hope with this talk is by the time we get to the end of this talk, I can convince you that the actor model is not like an old concurrency idea, but it really maps well to the agentic system design that you can start using as a tool as you go about in your own day to day working with agents.
From Demoing with Agents, to Prod
Instead of starting with the boring definitions of what an actor is, I thought I could start with a story. The story is something that we all might be familiar with, which is when your demo with agents leaves your beautiful demo environment and makes contact with production. How many of you have built a demo with agents over the past 12 months? What I'm going to share might seem super familiar because when we are designing a demo with agents, our focus is always about modeling the reasoning, like getting the prompts right, figuring out exactly how do we get the guardrails right and all of that. The architecture ends up being pretty obvious. It's a simple architecture. There is some prompt chain over the agentic loop. There's some application glue code. There's perhaps a cue that you put in for the slow work, model calls and a few tool calls and you finally get an answer, and your agentic demo is working.
Then this architecture feels pretty natural. It's good enough to prove that the models can reason, the tools can be called, and the workflow can come back with an answer. It's also good enough to produce a demo that makes the agentic systems feel real. Now your demo gets super popular. Your friends start using it, your colleagues start using it, your relatives start using it, and now the demo makes its first contact with production. The production actually changes the shape of the problem. Because your tool calls are now taking longer than expected. Anthropic decided to tell you that actually we exhausted your token, so I'm going to rate limit you. Users start asking follow-up questions while your agent is still working. Your workers get restarted halfway through the execution. Suddenly the hard part is no longer about the reasoning, the hard part becomes the runtime of the production agents. That's exactly what I want to talk about today is how do we model this runtime of production agents. Really what happens once your demo goes from demo to the production environment, the shape of the problem changes.
Let's now look at what are some of these shapes that change. The first thing that changes is this notion of time. In the demo environment, your tool returns pretty quickly. It feels like a normal request-response cycle that you're familiar with microservices. Everything is happening really quickly. That's no longer true in the production setting because you get rate limited, tool calls can take longer. Sometimes you have to get back to the user for feedback, and the user can only respond back tomorrow because they're not available. A function call ends up being a poor abstraction for work that begins now and results later under uncertain conditions. The second thing that changes is just the interaction. The users do not stop existing while your agent is still working. They ask for follow-up questions. They ask for status. They request for partial results. They change the execution of agent based on new information.
Your agent loop is no longer a single request-response loop. It is a running process that's just receiving information. The third thing that changes is delegation. Unlike everything else that we have seen in the past, agentic systems don't merely execute a series of steps. Actually, they're creating the entire steps on the fly because they're learning more information and coming up with the execution of work. The structure of execution no longer follows a straight line. It ends up becoming a tree, or more precisely, a graph. The fourth thing that changes is just failure. There are different failure models that happen with agents. Tool calls fail, model call fails, your worker processes get restarted, external APIs get rate limited, queues can re-deliver messages, and the list goes on and on. In the demo environment, you're treating exceptions as an afterthought. In the production setting, it's just a part of the normal operating environment.
At this point, because the production changed the shape of the problem, the architecture that you started out with the demo has started to grow sideways. Your chat lives in one place, your workflow state lives somewhere else. The queue knows that the work exists, but doesn't know what the user really intended. The database records progress, but not always the continuation of work. The retry state is scattered across different places. The recovery condition just becomes a second implementation of your workload. The code still works, but the system becomes hard to reason about. The problem is not any of these single components is wrong. It all makes sense. Queues make sense. Databases are useful. You do need workers for parallelism and concurrency. The problem is that the system doesn't have a single execution model. The agent gets treated as a chat in one part of the system, as a workflow or a background job in a different part of the system, as an entire recovery process in yet another.
That is actually the production pain of the runtime of these agents. The conceptual unit of work that agents end up carrying out is actually split across multiple runtime concepts. This happens for one main reason, is that we design these agents as a reasoning problem with LLM and tool calls, which ends up hiding the actual problem, which is the runtime of these production agents. The moment we start looking at production agents as a runtime problem, a familiar system starts showing up, which many of you might be familiar with, that is, the production agents are just distributed systems in disguise. They are stateful. They are concurrent. They are long-running. They communicate with other components, so they're distributed in nature. They can fail in parts, and they can restart independently. They must accept new information while the work is still ongoing.
Actors
Once you see agents as a distributed system, a more fundamental question starts showing up, which is, how do you model the runtime of a system like this? Our answer to that is the actor style reasoning fits really well with the runtime of the production agents. Or at least I would like to convince you that is the case today with this talk. Before we talk about agents, let's just walk through the actor idea from first principles for folks who might not be familiar with. First, the actor idea isn't new. It was actually discovered as part of the AI and concurrency research in the 1970s. It is Erlang and OTP that made the actor style thinking operational in a serious way. In fact, there's this great story about Erlang, which is the story of nine nines, nine nines of availability. Erlang proved it by running a system over 2 million lines of Erlang code that was available for 20 years with nine nines of availability.
That's crazy to think about it. What Erlang showed is that you can build really reliable systems that are extremely concurrent, fault tolerant, and always on. We want to bring the same idea to agents. To understand the actor model from first principles, let's actually take a step back and ask, how do we normally think about computation? Most of us, when we learn to program, we think about software as a single flow of control. A function calls another function, you receive results, you update state, and then you move on. This model is not wrong. It's a great mental model. It's super useful. It quietly assumes a world where control flow is local. Failure is either absent or is handled by the caller. Real systems are not like that. Real systems end up having multiple flows of control. Many things happen at once. Parts need to communicate without sharing all of their internals.
Parts can fail independently. The moment we enter this world, which is the real world, the hard question changes. The hard question is not merely, which function should I call? The hard questions are, who owns the state? How do other parts of the system communicate with it? What happens if one part fails? The actor model is one answer to these questions. In the actor model, the basic unit is actually not a function. It's not a class. It's not a thread. The basic unit is an actor, which is an independent unit of computation. The operative word here being an independent. The actor has a private state that only actor has access to. The actor can receive messages. Because it can receive messages, it must be addressable, which gives it a mailbox. When it receives messages, the actor decides completely based on its local state what to do next.
It can update its state. It can send messages to a different actor. It can create child actors. It can fail. It can stop. It can restart. All of those are options that are available to the actor. The actor ends up starting to behave like this little machine. A machine that has address, which gives it a mailbox. A machine that has a private state. The machine that has an encapsulated behavior of how it should act purely based on its internal state and the messages it receives.
Foundational Design Principles of an Actor
This leads us to the first foundational design principle of an actor, is that the state has an owner. I think we're all familiar with shared memory systems, where many threads end up touching the same piece of memory. We've all dealt with that. The way to achieve consistency in such a system is that you end up having locks, mutexes, transactions, read-only semantics, defensive copying, and a whole lot of discipline. The actor model flips the question. Instead of asking who is allowed to mutate the state, the actor model forces the question that which actor owns the state. That's how you go about designing within the actor model. Only the owning actor can change its state. Other actors cannot reach inside and mutate an actor directly. All they can do is send messages, and the owning actor can receive those messages and decide how to transition. The second foundational principle with the actor model is everything is a message.
I want all of you guys to pause on this principle because this actually shifts the shape of the control flow. Like, instead of code calling code, you now have communicating systems. Like a direct call assumes that the caller and the callee, they live together in the same execution context, now waiting on the same stack. The moment you have messages, now you end up having this loose coupling between two communicating entities. The sender can send a message and move on. The receiver can process the message when it is ready, when the results can come back later, also as another message. That gives us a different way to think about concurrency. Inside one actor, the execution is sequential. Actor receives messages one at a time and goes about executing it. The state is local, so the reasoning is also local. On the outside, across actors, the system is concurrent.
Many actors are working independently, so they can run, they can wait, they can send, they can receive, they can fail. All of that can happen independently. The actor model is not making concurrency disappear. What it is really doing is it's putting boundaries around it, and that gives us a way to reason about things locally while still building concurrent systems. Finally, this loose coupling that is really enabled because everything is a message allows for an actor to operate like an entity. An actor can live over time. It can be created. It can receive multiple messages. It can remember state between messages. It can create child actors. It can crash. It can restart, and it can eventually stop.
Then the final foundational principle with the actor model is that failure has a boundary. In many systems when you're thinking about failure, you have a scattered version of try-catch blocks everywhere, retry loops, maybe a completely different recovery code. Actor model just encourages a different question. Because you have independent operating entities, it just says like where is the boundary, and can we put a boundary around failures that happen around these independent entities? The actor model turns failure into an architectural concern, which is great when we're designing systems. In actor, this idea is called supervision, which we'll see later in this talk, where some actors end up being supervisors and some actors end up being workers. If a worker fails, the supervisor has a policy. The policy is you can restart it, you can stop it, you can escalate the failure to a human, or you can escalate the failure to a system with just partial results.
All of them are policies. There's no single specific policy. The important idea is that the architecture knows where failure happened and what boundary contains it. If you put it all together, an actor is an addressable, isolated, stateful, message-driven unit of computation that lives under a lifecycle and a failure policy. It's addressable because other parts can send it messages. It is isolated because the state is private. It is stateful because it remembers between messages. It's message-driven because communication happens with the mailbox of the actor, and is supervised because failure is contained by the architecture. This ends up giving us a compact model for long-running concurrent failure-prone systems. The runtime for it could either be local and also remote.
Order Actor and Agent Task Actor
This idea then brings us back to agents. Before we talk about agents, let me just make the idea of actor a little bit more concrete. Let's just take an example. This is an example, which is, you're shopping on Amazon or eBay. You add an item to a cart. You put in your payment information, put in your shipping information. The question is, that's an order that you're about to make. How would you model something like that? The first question, when we think about the actor model, it becomes, who owns the truth about the order? The actor-style design, the truth is owned by the owning actor. In this case, we call it the order actor. It owns the items, the payment status, the shipping information, and whatever else defines the order. If the payment happens to complete, how does the payment component communicate with the order actor?
The payment doesn't directly mutate the order. All the payment does is that it sends a message called payment succeeded. Shipping, similarly, doesn't mutate the order actor. When the shipping completes or the shipment is in progress, all it does is sends a message that shipping completed or shipping failed. We looked at both payment and shipment, and they're both examples of the happy path. Even the unhappy path, like cancellations and timeouts, are also messages. This is where the actor model starts paying off, where both the happy path and the unhappy path ends up using the same interface.
Now, take this order actor and replace it with an agent task actor. That's the translation going from an actor to an agent. It's like, ok, Manju, I agree, but tell me how. Let's go through the mapping one by one. The first thing that we need to figure out is like, what is the state of this agent task actor? Obviously, the state must include the goal of the agent, because all agents are autonomous, and the goal gives the task a continuity. A single model call might come and go, but the task continues to make forward progress of what it is trying to accomplish. Encoding it as an agent task actor allows us to do it. The second thing that you would put into the state is context. Context is not just the text in the prompt, it is all of the accumulated state that allows the task to move forward intelligently as new information arrives.
That becomes the context. There's also like the tools in flight. If a tool call can take several minutes, then the task must remember which tool calls are outstanding, know what it is for, what it expects out of the tool call in terms of results, and what kinds of timeouts apply to those tool calls. The task doesn't necessarily own the internals of the tool, but it must remember the fact that there are tools in flight and outstanding. The final thing that is also part of the state is all of the child tasks. We talked about the fact that agents are special because when you're doing agentic execution, the execution changes based on new information. You can create new tasks. You can delegate work to new tools or new child actors. The parent doesn't need to own every single detail of a child task, but it does need to own the relationship.
Like why child was created, what result is expected, what should we do when failure happens, and how the results should be integrated. We have seen that the state of an actor maps really well to the state of an agent task actor. There's also the communication side of the mapping. How does that work? On the communication side, all the events to the agent task actor just ends up being encoded at messages. To make this more concrete, like let's assume you go and tell your agent, I really want you to generate a report looking at different geographies and doing some specific analysis on it. Now, that request to the agent shows up as a user message. When the agent task is running and you're doing a tool call, the tool results also shows up as a tool result message to the agent. If the user, while the agent is still working, says, also include Europe in your analysis, then that also ends up being a follow-up, which also shows up as a message to the agent.
In the non-actor system, you would think of these as three separate pathways. The chat over here, the workflow over there, cancellations over the third place. In the actor system, they all end up being messages with the same running task. All of these messages flow through the mailbox. The mailbox then ends up becoming the single place for the running agent to receive all events of interest. It removes all side channels and allows each agent task to interpret every message it is getting based on just its local state that it has. Once we look at the state side mapping and the communication side mapping, the other mappings from the actor model to the agent task just follows naturally. You have the actor state that maps to the agent task state. You have the actor identity, which maps to a durable handle for the running work. Because a durable handle gives address to an agent, now you can reach to it any time you want because now it is addressable.
Child actors map to delegated subtasks, tool calls, or specialist agents. Supervision maps to failure boundaries. Hopefully at this point, now you can start seeing that there's this one-to-one mapping from actors to agents. Agents are actor shaped because they own state, they receive messages, they can delegate work, they can live over a long period of time, and they can fail independently.
Patterns
Once we start seeing agents as actors, the next practical question is, like what production patterns just follow through once we adopt an actor style design for our agents? The first pattern is that the task becomes the universal execution primitive. What I mean by that is, if you look at many agentic systems, like you have one interface for chat, you have another for tool execution, you have another for workflow, you have another for background jobs, and another for delegation, and they're all separate concepts. Each has its own state model, a lifecycle, cancellation, and recovery path. This fragmentation is exactly what made the original demo architecture move sideways, where we had to fix each problem one at a time. The actor shape alternative is to treat every long-running unit of work as just a task actor. A chat interaction is a task. A workflow is a task.
A tool call is a task. A delegated subproblem is a task. Waiting for the human in the loop input is a task. The point is not that all of these tasks are doing the same thing. The point is that they all end up having the same runtime contract. That contract is the contract given by the actors to the task. The contract of identity, mailbox, state, lifecycle, and supervision. Modeling the problem as task actors gives us a unit of work in the agentic world. The second pattern that follows through is write-through state. Once every meaningful unit of work has state, the next question is what happens when the process that is holding that state crashes or dies? With the write-through state, every meaningful transition to the state can be made durable as it happens. That's easy to see because in an actor-based system, state is local and the only way to modify that state is when you receive messages.
Every time an agent receives a message, if the behavior of the agent dictates a change in state, it can record the changes in a durable store, the state changes would then be applied, and then it can decide what to do next, like emit new messages, create child actors, just based on its behavior. The actor model just brings the durability piece just in the way the problem is modeled. With the write-through state in place, like if the process crashes, the system can just rehydrate the actor from a durable state and resume. This makes recovery the same as normal resumption. There are no two different paths, they're just the same path. The task does not need to discover what it was doing based on the scattered side effects when it crashes. It just wakes up, just like resuming work, and just continues forward. The write-through state gives the unit of work recoverability and it makes it durable.
The third pattern that follows from this is what I call as the indirect continuation. Durability tells you what happens when the process dies, but there's another problem with agentic system, and that's the problem of waiting. We've all seen it. A tool call might take minutes or tens of minutes, a human might respond tomorrow, a child task can create multiple tasks, and so that by the time you get results, might take a long time. The wrong answer when you're building this is to preserve the call stack as all of this happens, because the call stack is just a temporary execution structure. It's not the right place to store the state of the workflow. Instead of waiting on the stack, what you can do is the task delegates work, it records the continuation, and then resumes that continuation only when the message arrives. The continuation is not a blocked thread, it's just another piece of state owned by the task.
It records what this task intended to do while the work is still outstanding. This actually is a subtle, but really important shift, because the system in the previous mode would just preserve the stack frames. Now you're preserving intent. When the tool call arrives or your child has complete back with results, that's just another message, and the task can just continue forward once it receives the message, based on its state. What the continuation does, it gives the unit of work the semantics of waiting without pinning the stack. The fourth pattern that follows through is this thing called the mutable execution graph. Once the work is no longer tied to a stack, now you can start representing work as a graph of tasks. With agents, that graph cannot be fully known upfront. If you recall, like in a traditional workflow, the series of steps that usually need to happen are known in advance.
You can model it as a static, directed acyclical graph. Agents are different because they're discovering steps while you're executing. The agents have a goal, but then they go researching it, they find a gap. They create new subtasks. They can call another tool. They ask for clarification. When the results come back, they can just change the plan. The graph in the context of the agent is not merely executed by the runtime, it is being discovered by the agent as it is executing. Graph ends up being the part of the runtime, which ends up being a very different shift of how you model the problem. The runtime not only has to represent the current step, but has to represent the evolving structure of the work. The mutable graph lets unit of work create more units of work.
By now you've seen this actor style design and it has given us long-running tasks, durable state, continuations, and mutable graph for child tasks, but each of these pieces can fail independently. Failure policy becomes a structural concern, and that's our fifth pattern, which is about supervision boundaries. Supervision is not the same as exception handling. Supervision is about giving failures a boundary and a policy. In an exception handling case, like you think about the way you model it, it's like, what happened wrong here? What should I do here to handle this exception? Supervision says something completely different. It says, a part of this system failed, what policy should I use it for this boundary? Should I restart it? Should I retry it? Should I escalate it to the parent? Should I preserve partial result? Should I ask the user what to do? All of these become architectural concerns.
Once you draw the supervision boundaries of where failure happens, failures stop being a global concern but become local events with policies. Supervision gives the unit tree of work a failure policy. When you put all of these derivations together, now you end up having this coherent architecture for the runtime of agents in production. You have task actors that gives us a unit of work. You have write-through state that makes the unit of work durable and recoverable. You have indirect continuations that let the unit of work wait without pinning the stack. You have mutable graphs that let units of work create more units of work. You have supervision that gives the resulting unit tree a boundary to contain failures and makes failure a local policy.
What Is the Payoff?
We see that we're starting to evolve the design for the runtime of these production agents. A good question to ask here is, what is the payoff of adopting this to model our agents in production? The first thing I want to say is that the actor model is not going to make your agents easy to build. What it does is that it does make the hard parts really explicit and gives them a name. The production AI still continues to be difficult because essentially what you're doing is that you have a non-deterministic LLM model and you're trying to build the correct execution on top of a non-deterministic foundation, and that's really hard. You have things that could fail in production AI. You have external systems that end up being unreliable. You could have models that end up having degraded performance and return different results based on just the non-deterministic nature of it.
The actor model doesn't remove them but it gives us names and boundaries to certain things which allows us to build some reliable systems. The first payoff of using the actor model is the state of your entire system. Instead of the state leaking across a bunch of different places, each meaningful unit of work now ends up having its own state. When a message arrives, there is a single place to look at that state and decide what to do with the incoming message. The second payoff of the actor model is that the unit of work ends up having the address. We've seen this before. A running agent is not just a single request-response loop, but it's constantly being hooked around in order to change its executing direction. That requires you to have an address to get to the unit of work, and the actor model makes the unit of work be an addressable entity.
The system can send it a follow-up question, a cancellation, a timeout, a result from child actors, and they all end up being the same. Users can return to work that is still running, because the work ends up having identity. The third payoff with the actor model is, again, the failure has a boundary. Instead of failures leaking through the entire system, the actor model makes failure a local policy. A tool call can be retried. A child task can be restarted. A branch can be canceled. You can take partial results, and the parent can continue executing. Failure becomes an architectural concern instead of just being a scattering of emergency code. The fourth payoff is that you don't have to think about recovery and resumption in two different ways. They end up just becoming part of the normal path of execution. This happens because the transition of your state is durable so the task can own the continuation and state, and crash recovery can just work the same way as resuming the execution of a task.
Design Checklist
My hope is that you start seeing that the actor model really makes sense for the runtime of agents in production. What I want to ask you is that the next time you're designing an agentic system, it doesn't matter, you can choose whatever framework of your choice. Ask these five questions, which are, what are the actors in my system? What state does each actor own? What messages do they exchange? What can fail independently? Who supervises whom?
Example: Coding Agent in Actor-Style
I realized that all of this is still pretty much theoretical, like there's a framework to think about it. I wanted to make this more concrete with something that we might all be familiar with, which is coding agents. How many people here use Claude Code? How many people use Codex? How many use Kilo Code? The code that I'm going to share here, is just a minimal coding agent. You can connect to a local model like Qwen, or you can connect to an OpenAI model, Anthropic model. It's a coding agent designed in an actor style. It's purposefully super minimal so that you guys can grok the idea of actors. In this coding agent, we have four actors. There is the supervisor actor that lets you grok the idea of supervision and failure boundaries. There's the LLM actor that controls the transport to an OpenAI model, or OpenAI compatible model, or an Anthropic model.
There is the tool registry actor that's responsible for dispatching tool calls. Then there's this agent actor, which is really your tight loop, and it's agentic in nature. What you would see is that at the very top, you have the supervisor actor, and its job is not to do the coding work. Its job is to own the lifecycle and failure policy for all of the work that happens underneath. The coding task itself is done by the agent actor, and it owns the goal, all of the transcripts that you've had during your coding session, the plan, the child task, and the continuation state. You can start seeing the unit of work and how it ends up interacting with other runtime pieces, where not all of the actors need to be agentic, and different actors end up having different roles. For anyone interested, if you wanted to inspect this after the talk, feel free, here's the QR code for getting the repo. It's intentionally kept very simple to serve as a teaching artifact for all of us to think about the actor model.
Greenspun's 10th Rule for Agents
Let me end the talk with a variation of Greenspun's 10th rule. The original version of the rule was that any sufficiently complicated C or Fortran program eventually contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp. I think a similar version exists for agents, like any sufficiently complicated agent loop contains an ad hoc, informally specified, bug-ridden implementation of half of an actor system. That really is the point of this talk. If you run your agents over time, they own state, they receive new information, they delegate work, the weight on tools, they recover from failures, and they continue executing, you are building something that is actor-shaped. The choice is you can do it either accidentally or you can do it intentionally.
Questions and Answers
Participant 1: Conceptually, I got it. It's like we can model agents' components as actor models and MVs. Can you share a little bit more about what's in the wild and open? Is there any successful framework or projects following this pattern? For example, you said, there are so many coding agents out there, and there's a toy example. What's the benefit? Why didn't they already fall onto the direction?
Manju Rajashekhar: That's the same question I was asking too, because I was pretty surprised that not much was talked about this concept. This is just a hypothesis, but part of the reasoning is that what coding agents have done today is that the two most popular languages with coding agents ends up being Python and TypeScript. What the actor model does require is it does require a robust runtime to run these actors. What these coding agents and frameworks, they're rediscovering some of the pieces that we talked about in the actor model, and they end up building it, but it ends up being built in a half-baked way. A lot of this talk is really to bring the actor model right, front, and center, and start thinking about all of the runtime of the agents from that perspective. That's one of the key reasons, what's happening today with why the actor model is not super widespread in terms of how we talk about it.
Participant 2: The question here is like agent-to-agent communication. Let us think you are saying the state is owned by the agent. Now in this current world, the context size and the content of the agent which is processing is really large. Now, if I want to send that context to a different agent, in this model, how will it work?
Manju Rajashekhar: The context still gets sent as messages. If you look at what's happening with the agentic system, the main cost with agents is really around how long does an LLM take to process tokens? It ends up being a really small number compared to that cost. You can always send these messages over the wire to a different agent, or you can use some sort of an indirection where you can say, I'll just have a pointer to the same copy of the message that another agent can have access to.
Participant 2: That will defeat the purpose of actor owning the state. If you send a pointer to a different actor, that means now two actors can control that state.
Manju Rajashekhar: No, you're sending a pointer to the copy of the data. If you don't want to use up the network bandwidth, you can just send a copy of the data, but the actor still owns the agent. The context that you're sending is just part of the message. Now, how you encode that message is very different. It's very clear in the actor model, who owns the state. If someone else needs the state in order to update their own local state, you just send that entire data to it.
Participant 3: Do you see ACP as being a natural next step for the proof of concept of being a message bus between not only ACP client and ACP agent, but things like acpx emerging to promote communication between agents themselves. Like a next layer of the actor problem.
Manju Rajashekhar: It seems to be headed that way. It seems like it's heading that way. We haven't formalized the concept. My hope is that as more people start seeing that the actor model can be applied, people start thinking about the problem from the abstraction standpoint, rather than from the protocol standpoint.
Participant 4: Is there a good way of using this right now? The agent frameworks that I'm familiar with are all pretty opinionated about how you register tools with them and how that communication happens. From what I know, which is very little, there's not really a good way of inserting something like this in there. Is there a framework that you're familiar with, or is there a way of like porting this into the existing frameworks that we could use right now?
Manju Rajashekhar: What the previous speaker asked is super interesting. I think that's worth looking at. I'm not familiar with anything where you can put this in, which is also why I'm sharing this code, because it's actually pretty easy to build right from ground up. What's happening today is, because now we have coding agents, a lot of the work that we have to do as developers and architects is really figuring out the mental model of the runtime, and code that in what the coding agents need to be building. Versus asking the coding agents to just solve the work and then they end up solving the work without the right abstractions. We don't need an existing framework, in some way we can just skip that entire step and say, I need to solve a problem that requires using agents. How should I model the runtime? You start from there.
Participant 5: It's just a follow up on that. I love Erlang. Do you think then it's a matter of having the prompt, including as someone who would fix this or would implement this using the Erlang model?
Manju Rajashekhar: Not really. The code snippet is based on Rust. Because you can implement an actor model on Rust really well. It's really like adopting the actor model. The Erlang VM is great. The BEAM VM is great. For some reason, the agentic world and Erlang and the Elixir world haven't really met yet. It would be great for them to do that.
See more presentations with transcripts
