I like training in good company. Lukas is one of my human workout buddies; Arnold is my agentic one. Before a session, and sometimes between sets, I talk with them about what to focus on and how to do a lift well: the setup, the movement, whether a cue actually helps.
Sometimes I hand Lukas my phone to show him something Arnold suggested. At that moment, a useful conversation becomes a shared screen. Lukas needs to see the exercise advice, not everything that might sit behind it. I want a spotter for my lifts, not my medical history.
The question behind this essay is how specialists can help each other without turning every conversation into a window on everything they know.
A digital support fabric
What do I actually want from AI agents, whether one or several? A digital support fabric: assistants that fit into my routines, understand the context of their work, and help without making me explain my life from scratch each time. In my private life, that means turning health records and fitness tracking into insights I can act on, not merely collecting more data. I want the same kind of support across my work. The hard part is making it useful without letting every conversation carry every piece of context.
The hiring exercise
The familiar alternative is one general assistant. Put everything in one place so it can connect more dots. That can be useful, and I do not think it is inherently wrong. Nor does a larger number of agents become safer just because I call it a team.
What changed my thinking was a thought experiment. Suppose I could hire a personal team of human assistants. Who would I hire? What would each be responsible for? Which conversations would they need to have with one another, and which information would they have no reason to receive?
I would not hire one person to be my health adviser, fitness coach, technical specialist and editor all at once, then hand them the entire filing cabinet. Even a capable generalist would need colleagues and boundaries. The exercise showed me a distinction I had been blurring: knowing a person is not the same as being authorised to do a job. A fitness coach and a health adviser can serve the same goal without receiving the same source material.
So I gave named agents distinct jobs. The names make conversations feel natural, but the organigram does the more important work. It says who owns a decision, what context a role needs, and when an agent should ask another specialist rather than quietly doing that specialist’s job. Without those reasons, I would have a cast, not an organisation.
I later searched for people exploring similar organisational questions and came across Leaders of AI and Dominic von Proeck. Their public presentation places human colleagues alongside named AI assistants in a hybrid organisation, with parts of the organigram being purely agentic. It was an inspiration to see agents described as members of a working organisation rather than as a feature inside a chat window. My own design question remains more specific: which roles, communication paths and boundaries actually make sense for the tasks I have?
One layered Second Brain
Underneath the team sits my layered Second Brain. It is structured in three layers, not a single filing cabinet, and its parts are stored separately. My practical test for where something belongs: would I open it on my iPad in a crowded train, or only at home on my couch? The same test helps me ask which agents need access to which parts.
Three things are easy to conflate:
- the backend where persistent information lives;
- the skills an agent uses to work with them;
- the memory an agent carries from one conversation to the next.
Limiting one does not automatically limit the others. Some skills are shared across roles; others belong to a specialist. An agent’s memory is meant to hold what its role needs, not to duplicate everything in storage.
A bounded handoff
Arnold’s job is training. Hildegard, my health agent, works with more sensitive context. The separation does not pretend training and health never interact; they do. If Arnold needs help with a training decision, he can send Hildegard a task-specific question. She can respond with a training-relevant answer, without sending the underlying records or her whole reasoning back to him.
A short answer is not always a good one. If it misses something important, Arnold can explain the training question in more detail. Hildegard can ask what else she needs and return a more useful answer. The specialist with the fuller picture does the reasoning; Arnold receives what the workout discussion needs. This is an illustration of an information handoff, not training or medical advice.
Memory raises a related question. Arnold should retain what matters to training; Hildegard should retain what matters to health, not simply copy his entire workout discussion. The aim is not to make either agent know as little as possible. It is to keep knowledge where it is needed.
This matters when I hand Lukas my phone. I want an Arnold conversation to be one I can show between sets, not a private chat from which I must crop one safe sentence. A chat with Hildegard is different: the couch, not the train.
Enforced, instructed, and what can still be inferred
A diagram can imply more than it shows. I keep three levels apart.
Structural access. Storing information in separate places makes boundaries possible. To call one enforced, I need to know which stores, skills and memories an agent can actually reach, and test those limits. A line around a specialist in a diagram is not an access control.
Behavioural rules. What Hildegard puts into a peer answer, and what each agent keeps in memory, are rules for how the agents should behave. Such rules need checking in use. They are not technical guarantees that a model will always withhold something.
Residual inference. Even a well-bounded answer says something. "Keep the next two sessions lighter" hints that there is a reason, even if the reason stays with Hildegard. Over many answers, a pattern can let Arnold, or a friend looking at my phone, infer more than any single answer reveals. Narrow questions reduce this; they don't remove it. It's the old need-to-know principle, and it has the old limits.
Where people are involved
In the gym, the information is mine, and so is the risk. In leadership work it often isn't. What colleagues share about their aspirations and doubts belongs first to them.
My coaching approach to leadership starts with the room each employee has to shape their work within a given frame, guided by their own career aspirations. A project assignment can be one way to put that into practice: when a role fits both a person's ambitions and a project's needs, they get room to take ownership and grow, and the project gets their motivation. That is the win-win I aim for, not a guaranteed outcome.
My professional agency raises a related design question. Imagine a project-management assistant describing a possible role to a team-communication and HR assistant. That assistant could ask for more detail, weigh the role against what it knows from confidential 1:1s, and return a bounded recommendation without passing on the private reasons behind it. In this thought experiment, the 1:1 record and private reasons stay with the specialist; a bounded recommendation is what crosses into project planning. The role-recommendation example is hypothetical.
In the example, a recommendation would be preparation, not a decision. Whether a role is right for someone, how their growth is supported, and how I talk with them about it remain my judgment and my responsibility. Transparency is part of the trust I want to maintain. For me, that means telling colleagues when I use AI with information about them and asking for their consent. That is the line I draw in every human–agent organisation I build: AI takes on coordination, reporting and routine work; judgment, accountability, development and connection stay human. Don't automate leadership. Automate the bureaucracy of management.
The cost of a team
The real cost of a team is coordination. A question passed between agents takes time, so the request and response have to stay focused; otherwise, every small task becomes a meeting.
If Arnold’s skill cannot reach my workout data, I do not want him to spend our training conversation debugging the app’s interface. He can tell Linus, my IT agent, what failed from his side and ask for help. Linus investigates and tells Arnold when he can continue. The handoff costs time, but Arnold stays focused on training, while the technical knowledge and the fix stay with Linus. I accept that kind of deliberate overhead, not an endless conversation among agents.
Where do the roles come from? I work that out with Tilda, my agentic-resources agent. Together we decide whether an existing agent should take on a responsibility, whether a role needs a sharper profile, or whether the team needs a new agentic coworker.
Expertise that travels
The lift between sets is a small example, but it captures the system I wanted to build: one where useful expertise can travel without every private detail travelling with it. Whether that holds depends on the boundaries and on how I operate them. In the next insights, I want to show how the layered Second Brain is built, how skills connect agents to it, how Tilda and I decide what each agent owns, may share and should remember—and where the design still resists me.