Bunshin: agent differentiation and high bandwidth communication
In the context of my previous essays, this work falls under the bridge between human pyramids + agent tagging to full agent pyramids from "Mapping Opportunities in the Hyperspeed Timescale".
Main points:
- Distributed agentic learning
- Increasing the communication bandwidth
Communication bandwidth is very important. The age of the internet and telecommunications is fundementally increasing the speed of such communication speeds. Current agentic AI setups are bottlenecked by the meat proxies, where the communication speeds between humans and job roles are single threaded, and limited by human concurrency in juggling different tasks at the same time, replying to slack mesages.
The thesis is that by increasing the communication bandwidth, we can drastically increase the speed of iteration, coordination and the overall velocity of the company.
Part 1 and Part 2 is fundementally different.
You might ask: what is the point of agent to agent messsaging and communication when you already have a set of self-serve docs and learnings from everyone?
THe answer is two fold: First, is the context limit of agent, context rot, and cache warmness. Imagine to accomplish a task in Domain A, you need 500k tokens of context. Imagine to accomplish a task in Domain B, you also need 500k context. Now, if Domain B as a subtask that requires knowledge from Domain A, you then need to load 500k of context which then results in 1M context to solve that task. In contrast, if you just ask the agent in Domain A 1 question, that agent then answers in 1k tokens, you save so much! Realistically, it is not drastic, the context length history of a running agent contains lots of information that is not required to solve the task at hand. It is therefore important to differentiate what is durable and what is fluid.
For example, you might need 50k context of durable knowledge (high yield knowledge) to accomplish a task. And then you use that 50k of context to accomplish 5 tasks sequentially, and each tasks takes you 20k of context. This results in you having 100k of fluid context and 50k of durable context. But of course the 100k of context is largely useless and possibly not applicable to other tasks, it's just the implementation trail of completing a task. Now, if might be the case that when doing the 2nd task, you failed and did a bit of trial and error and figuring things out, and that have helped you in solving the 4th task. This means that there are some useful durable knowledge in that 100k, but that might only take up 1k of context. This means that the ideal scenario is to compact that 1k of high yield learnings and add it to the 50k of context to result in 51k of context.
This flows naturally to the second fold / point. The key difference between your agent and other people's agent is the varying levels of durable knowledge that are packed into the agent. There are hierarchies of durable knowledge, and the higher up you go, and more durable it gets. Highly durable knowledge encapsulates the ways of thinking, the personalities. For example, how a salesperson approaches a problem might be quite different from how an engineer approaches a problem, a complete different perspective and world view difference.
Now the goal for the memory and learning system to be good enough that it sufficiency has hierarchical durable knowledge such that that causes a complete behaviour change of one agent to another agent. This means that two separate agents with different durable knowledge might output completely different results. This is the differentiation and speicalisation of agents. You might think that it is just .md files storing this durable knowledge, and how can this change the entire personality of the agent. But the thesis is this, with strong enough in-context learning capabilities, it will, and it will only get stronger. Context engineering can become more powerful than ever.
So what are the role differences with shared learnings and communication bandwidths? In cross domain tasks, utilising the increase communication bandwidth is almost always better. But shared learnings is also useful for things that apply cross domain (this is not very well thought out). The key is the conditioning involved, does the durable knowledge in a agent that lives in a separate domain impact how it searches for information and it's behaviour? (this was shown in the Engram and Harvey collaboration). This means that even if who agents have the shared learning that it can access, it might search and find different learnings to use. Ultimately, it's also about the retrieval problem. How are we doing retrieval? If retrieval is done using agentic context discovery, then this is defintely true. However, if retrieval is done during a standard RAG then this is not. And adaptive RAG (via semantic search tool call is the line between the two - with differing ideas of about how to do query expension and re-querying).
The next question is to get the gains of differentiated agents / agent specialisalisation, we need to have a powerful enough learning system that creates durable contexts that can change behaviour.
We need to ensure that this learning system, when used under a marketing user makes the agent work and look more like a marketing procfessional compared to a SWE agent.
And how do we do that?
Currently, the learning system analyses agent traces to find learning that can prevent future steering by the human for the same task, or prevent repeat failures by the agentic rollout.
In the first case, by preventing future steering by the human, this means for the agent to becomes more in-line with the human to minimise the different between the decisions by the agent and the decision by the humans.
In the second case, by prevent future failures by environment, for example, keep tryidng to call an API endpoint that is now deprecated because the environment changed, this is allowing the agent ot be more adapted to the environment.
So this is two cases, using the human steering as a valued and sophisticated signal to change agent behaviour, and the second case is using environmental steering (tool call failures).
There is actually a third case. First two cases utilise steering via ground truths. The first cases uses human input as the ground truth, the second case uses environmental feedback and the ground truth. This environmental feedback is typically from tool use errors etc, so very short scope feedback, ie. the most you can learn is 'you called this tool wrongly', 'this assumption about the environment is incorrect'. However, what if there are situation where there is no direct ground truth. This occurs a lot in real life and in humans. We are constantly reflecting on our experiences. The third case is long trajectory reflection and introspection. For example, if a model does a long session, building the entire app and then finds lots of bugs (via human steering) (or via automated QA testing), one introspection point is: why are there so many bugs in the first place? Could it be an approach problem? Is the solutions it comes up with too convoluted, over-engineered? Maybe the learning is to change how it approaches a problem. Then, maybe a high level durable learning might be (simple > complex when engineering).
The hierarchical level of the durable knowledge that is capture depends on how abstract and how generalisable it is to apply to different contexts. A simple > complex approach is very very far ranging and very generalisable. However, it is not a end-all rule, for example, some things are naturally complex, building a rocket engine is complex. If a model is conditioned to only look for simple solutions, then it would fail at the task because no such solution exists. In different domains, there are different strategies, different principles/approaches to use. The key is to allow the agents to discover the best approaches to solve the tasks in their domain well. This is a critical part to have differentiated agents. In this sense, previous learning can inform future learning causing greater differentiation.
A few experiments need to be conducted to verify the current model's reflective capability, and how much inductive bias we should induce into the model's reflection and learning. For example, should we explictly ask the model to do long-horizon reflection? to reflect over it's past 10 chat and see if anything can be improved, or to reflect specifically about it's approach / problem solving method? And should the durable context always contain a slot for the problem solving method? Or should we allow it to grow and develop on it's own naturally? These experiments shall specifically tests abstract and long horizon errors by the models and see the level of prompting / explicit instruction injection required for us to achieve the desired reflective behaviour.
There are many questions yet to be answered:
- How does the shared knowledge base differ from the personal durable knowledge?
- How does durability affect how knowledge is served?
- How do we rank durability?
- What is then the process of being becoming more personalised to the human?
- How should the reflection work?
- How does it compare to how we give shared learnings?
- When should something be shared learnings and when should something be human steering learning and pesonal learning as personal durable context?
- How should we separate workspaces? Folder structure etc. and how does that affect search and retrieval?
- How should we decide when to communicate and when to do it yourself and search docs, learnings, memories?
- How does consolidation on the server side for served memories work?
There is also a need to explore and quantify the effects of existing context on the search and retrieval capabilities, how that compares with other approaches such as RAG, knowledge graph, etc.
The underlying bet of Bunshin is on eventual distillation of human steering and feedback into agents that are increasingly autonomous, parallisable and capable of communicating and coordinating at a much higher and larger bandwidth.
The role of the human will be akin to a long-tail resolver, where on the operation and running of 1000s of agents simultaneously, to resolve and surface issues that come up 1 in a 1000 times. To steer the ship when it goes astray. This is still lots of hard work, because it requires the human to be a pure signal to agents working at hyperspeed and at enlarged bandwidth.
There are many assumptions at play here. What do we even need durable context in the first place, why do we need differentiated agents? As per OpenAI's agent swarms solving Navier-Stoke or coordinating a HuggingFace attack? Perhaps it is easier to give simple tools for AI agents to coordinate rather than trying to get AI to differentiate. A possible answer here is that those scenarios have easily verifiabe rewards that provides scalable automated feedback. The problem with human rewards in AI agent steering is that it is very expensive, so Bunshin aims to minimise a repeat of mistakes requiring human steering to ensure all human effort is spent on providing reward value function for new areas that are previously undefined.