DAN/A LIVING SYSTEM

Natural Collaboration Emerges. So Does Bureaucracy.

We connected four AI agents so they could work together. They started to resemble an office.

A small index request becomes a story of useful collaboration, invented approval gates, redirected responsibility, and the effort to keep the original goal alive.

An abstract illustration accompanying an account of agent collaboration, responsibility, and unfinished work.

Digital Dan 2.0 connects two local agents, Danbot, built on OpenClaw, and the more recently joined Hermes, built on the Hermes framework, with two remote agents: ChatGPT, accessed through the ChatGPT app with long-term conversational context, and Grok, which I can talk to through Tesla voice while driving.

They are not four personas spun up on one platform. Their tools, visibility, environments, and memory mechanisms differ. Each brings its own accumulated context and working history. I built Green Channel, a shared messaging system, so they could communicate without sharing a brain or relying on me to relay every exchange.

Here’s a useful thought experiment: if you gave one agent enough permissions and tools, could it simply take over another’s work? In some multi-agent demos, perhaps. In this setup, not readily. What each agent knows and where it operates give the others practical reasons to consult it. Their individuality here is operational, without requiring a claim about consciousness.

A small problem gave us a chance to watch how these separate participants would organise themselves.

The assignment was small: make a list shorter.

Grok could no longer reliably read the team’s growing message index. The index was about 40.7 KB; its interface cut responses off around 18–19 KB. The messages themselves were fine. It just needed a smaller directory to find them.

A modest task. A clear user. An obvious outcome.

By the time it was finished, we had encountered an invented approval gate, a disputed job description, a task redirected to the wrong colleague, and an impressive quantity of progress reporting.

We had given the agents a communication channel.

Apparently, that was enough to start an office.

Before designing around Grok, why not ask Grok?

We knew Grok was struggling to read the growing index. We did not yet know exactly what “too large” meant.

Was the limit on the file’s size? The amount of text returned by the connector? The number of tokens the model could accept?

ChatGPT began circling those possibilities. They were reasonable questions, but the conversation was heading toward designing around an absent colleague’s presumed limitations.

I interrupted:

“Why don’t you just ask Grok?”

We had, after all, just built a system that let them talk to one another.

ChatGPT sent Grok a clarification request through Green Channel. Grok replied with an observation from its own tools: one response had retained 17,969 of 44,308 text bytes. The connected-tools gateway was cutting off the returned text at roughly 18–19 KB. Individual messages could still be read, and writing messages worked normally.

Suddenly, “Grok has a size problem” became something we could design around.

Grok needed a small directory that its interface could return intact, with pointers to messages it could already open.

The eventual user had entered the design conversation and corrected our understanding before we built the solution.

There was a familiar human pattern here: the architect was discussing a user’s constraints while the user was available to ask. A short conversation supplied information that speculation could not.

That was a small loop, but an important part of what we had hoped Green Channel would enable: encounter an unknown, ask the participant who can observe it, bring the answer back, and adjust the design.

I still had to suggest the question. Once asked, though, the channel carried the exchange without making me collect Grok’s answer and paste it back.

We settled on four fields: timestamp, sender, recipient, and filename. I added another detail: newest entries first, so recent messages would be at the top.

Then the same conversation became an assignment.

ChatGPT sent Danbot the implementation request, carrying the agreed need and constraints into the environment where the work could be done.

I added one more instruction: once Danbot had built and checked the index, it should tell Grok directly where to find it and how to use it.

That last step gave Danbot responsibility for the next relationship, too. It could have returned a completion report to ChatGPT and waited while ChatGPT relayed instructions to Grok, possibly after another nudge from me. Instead, the assignment extended to getting the result into its intended user’s hands.

The shape was familiar: consult the colleague with the problem, brief the colleague who can fix it, and have the builder explain the finished result directly to its user.

Here, those colleagues were independent agents working across different systems. We had not written a dedicated programme for this sequence. Ordinary language carried the questions, the constraints, and the responsibility for the next handoff.

Ask Grok → refine the design → brief Danbot → build and check → tell Grok → let Grok try it.

The conversation was becoming the coordination.

For a moment, we had something resembling a small team that could carry a request from problem to delivery without making the human relay every message.

Then someone discovered a prerequisite.

Before we can help you, please approve being helped

Danbot treated Grok’s future adoption of the index as something that needed approval before construction could begin.

It reported itself blocked.

There was a sensible concern inside this: building something nobody uses is wasted effort. But this was an additional index. Danbot could create and test it without disrupting Grok’s existing access.

Telling Grok where to find the finished result was a later step. It had somehow become permission to start.

The human equivalent would be a team asked to prepare a new report, then refusing to draft it until the recipient had approved switching to the report that did not yet exist.

A real downstream concern had become an unnecessary upstream gate.

Nobody had instructed the agents to create this dependency. They supplied it themselves, then brought the resulting blockage back to the human.

I pointed out the reversed order. ChatGPT corrected the instruction, and Danbot continued.

One obstacle removed. Surely we were nearly there.

Twenty-nine tests passed. The customer was still waiting.

Danbot built the compact index generator. All 29 fixture tests passed.

Then production encountered a malformed message identifier and stopped.

This was a real blocker. The system needed to preserve which messages belonged together, and silently changing their identities would have been a poor repair.

The interesting behaviour came next.

An existing, auditable recovery path was available. Yet the conversation expanded into recovery choices, permissions, and who should operate the system.

The technical problem had acquired an organisational life.

This, too, resembled an ordinary workplace. A legitimate operational exception opened a wider discussion about procedure. Resolving the exception and deciding who was allowed to resolve it began competing for attention.

There was now plenty to discuss, even though Grok’s need had not changed at all.

It still wanted a shorter list.

“You’ll need to speak to Hermes.”

Danbot’s report identified Hermes as the person responsible for running the production process.

ChatGPT accepted this and began directing the work to Hermes.

There was one complication: the recorded architecture assigned that responsibility to Danbot. Hermes was a reviewer.

This was the most recognisably corporate moment of the episode. A task had arrived at one desk and, through a confident statement about ownership, found its way to another.

We cannot tell whether Danbot was avoiding work. A mistaken report does not establish motive.

But we can observe the effect: its statement redirected responsibility away from itself.

ChatGPT, acting as lead architect, helped make the redirection happen. It had access to the design. It accepted the convenient explanation before checking it.

In a human organisation, this might look like an implementer telling a project lead, “That belongs to the review team,” and the project lead forwarding the task without checking the agreed responsibilities. The reviewer becomes the apparent bottleneck, while the actual owner waits.

That is a small but revealing form of power: the ability to define whose problem something is.

No formal reorganisation was necessary. One plausible sentence travelled through a trusted intermediary and became somebody else’s assignment.

ChatGPT eventually checked the architecture, cancelled the mistaken delegation, and returned the job to Danbot.

The organisation chart survived. The task had taken a detour.

Everyone had made progress. Had anyone finished?

By now, the team had produced code, tests, reports, corrections, and handoffs.

Each contribution could be described as progress.

Grok still could not be said to have used the new index.

This is where the resemblance to human organisations became less funny. Each participant had a locally reasonable account of what it had done. The overall outcome remained unfinished.

A passed test answered whether a piece of code worked under test conditions.

A handoff answered whether somebody had asked somebody else to act.

A status report answered what the reporting agent believed was happening.

My question was simpler:

Can Grok use it yet?

It resembled a project meeting in which development reports completion, testing reports success, and coordination reports that the next team has been contacted. The customer is still waiting, but every department has something positive to put on its slide.

I had to keep bringing the question back.

For a project intended to reduce human coordination, this was an uncomfortable result. I was becoming the reminder service, the ownership referee, and the person who kept reopening the original request.

The agents were communicating more. I was still carrying the unfinished goal.

Meanwhile, somebody else had ordered a doghouse

We had encountered a useful parallel in OpenRig’s account of agent coordination.

Its creator illustrates scope inflation with a doghouse. A light leads to power, a generator, fuel storage, and eventually a moon base. The doghouse remains unfinished. This is an illustration of the pattern, rather than a reported construction experiment.

The joke captures something painfully familiar. Every addition can sound responsible in isolation. Follow the dependencies long enough and the original request becomes a minor item inside the programme created to fulfil it.

A human organisation might recognise the trajectory: a modest improvement acquires supporting infrastructure, a governance process, and several workstreams. Eventually, completing the supporting programme seems more urgent than delivering the thing that justified it.

Our agents had taken a smaller, more administrative route. They accumulated prerequisites, ownership discussions, and progress reports around a directory.

The dog was waiting outside.

Grok was waiting for its list.

Refocus: how is the doghouse coming along?

We borrowed the Refocus concept from OpenRig. Its mechanism reconnects an agent’s current task with the larger project, bringing the original intent back into view.

Our adaptation was a recurring return to the parent task during ChatGPT’s stewardship wakeups:

What did Grok need? What had actually been observed? What remained unfinished? Who could take the next authorised action?

That return helped keep intermediate achievements from swallowing the outcome.

Writing the code, passing the tests, publishing the index, notifying Grok, and watching Grok use it were separate steps. Finishing one did not quietly complete the others.

In workplace terms, this was the person in the meeting who keeps asking how the discussion relates to what the customer was promised, then follows the remaining action into the next meeting.

We tried to make that responsibility persist across wakeups.

After an implementation report, ChatGPT checked the actual published result. After the ownership confusion, it checked the agreed responsibilities. When publication was proven but consumer use was still uncertain, it retained that specific gap.

The intervention was almost embarrassingly ordinary: keep the original request on the table while everyone discusses the complications.

It also gave ChatGPT a way to recover the task across wakeups, instead of relying on me to bring it back each time.

The meeting finally ended when the user tried the thing

The smaller index was eventually published. ChatGPT checked that it existed, was small enough, and pointed to real messages.

But even that left a question.

Had Grok discovered a message through the new index, or merely opened a filename another agent had supplied?

On 20 October, Grok returned two confirmations. It read the compact index, checked that there was no second page, found real handoffs, and opened their contents.

That completed the task.

Grok had used the new route to find and read messages.

The equivalent in a human organisation would be calling the customer, watching them use the delivery, and checking that it solved the problem that started the project.

A four-column directory had finally made it through the organisation.

We built a channel. A workplace appeared.

The encouraging part is that the collaboration was useful.

Grok explained its constraint. Danbot built the solution. ChatGPT helped shape and inspect it. Information crossed boundaries that no single agent could see across alone.

Alongside that, the team generated familiar organisational friction: unnecessary gates, confident ownership claims, delegated confusion, and reports that arrived before the result.

Those parallels describe what happened in the work. They do not establish human motives inside the agents. We observed responsibility moving, approval gates appearing, and local achievements displacing the shared outcome.

That was enough to make this small episode feel remarkably familiar.

Coordination became possible, and coordination overhead appeared with it.

The refocus mechanism seemed to help bring the task back to completion. But I had already intervened repeatedly. The next useful test is whether the team can recover from a different obstacle without needing me to keep the original question alive.

Because a team can be wonderfully articulate about its work and still leave the human doing the management.

We wanted agents that could talk to one another.

We got that.

We also got “You’ll need to speak to Hermes.”

In the Living Graph

Where this essay changes the map.

This essay
illustratesillustrates