From Babysitting to Framing

Digital Dan began as an attempt to reconstruct parts of my mind in digital form.

Over the years, I had accumulated many traces of how I think: a university diary, years of conversations with ChatGPT, philosophical debates, interviews about my life, and reflections on work, family, freedom, causality, and personal change. The aim was not to build a chatbot that imitates my manner of speaking. It was to create a living model that could preserve experiences, recognise recurring patterns, form working explanations, and let new events revise its understanding over time.

Digital Dan 1.0 was a partnership between me and Danbot, a local AI agent running on OpenClaw. Yet I remained the person deciding what deserved attention. I noticed a problem, turned it into a task, told Danbot what to do, checked the result, repaired any drift, and chose the next task. Danbot contributed intelligence after I had already chosen the direction.

That was the babysitting problem. It did not mean Danbot was weak. It meant I was still supplying every meaningful next move.

Finding and checking

One idea from computer science helped me understand an intermediate step between following instructions and choosing a direction.

P versus NP asks a precise mathematical question, but one part of it offers a useful intuition. Some problems are relatively easy to solve by following a known process. For other problems, finding a good answer can be much harder than checking whether a proposed answer works.

Imagine trying to find a route through a complicated maze. If someone gives you a route, you may be able to check it quickly. That does not mean you could have discovered the route just as quickly, and it does not prove that the proposed route is the shortest one.

In formal terms, P refers to decision problems that can be solved efficiently. NP refers to problems whose proposed yes answers can be checked efficiently. P is contained in NP, and whether P equals NP remains unresolved. I am not claiming that writing, agency, or Digital Dan can be formally classified this way. I use the distinction more modestly: discovering a good path can be much harder than recognising improvement once a candidate path is visible.

That distinction became concrete while I was working on my book.

The translation loop

I had been writing a book in Chinese about free will and causality. Once the Chinese draft was complete, I wanted to translate each chapter into English.

A literal translation was not enough. The English needed to preserve the original meaning, structure, scenes, humour, and uncertainty while sounding as if it had been written naturally in English. A sentence could be technically accurate and still feel unmistakably translated. A smoother sentence could also become less faithful by removing an ambiguity or hesitation that mattered.

The destination was therefore clear enough: produce a natural English chapter that remained faithful to the Chinese original. But the route was not obvious. Which passage sounded most awkward? What should replace it? Would a more elegant sentence distort the meaning? Which problem should be fixed first? No one could prescribe every step in advance.

At first, I still drove the process. I found an awkward paragraph, explained what bothered me, requested a revision, inspected the result, and pointed to the next problem. Danbot helped solve each piece, but I controlled the route through the chapter.

The more autonomous translation loop worked differently. The agent could reread the chapter, identify the passage that sounded most like a direct translation, propose a better version, compare it with the Chinese source and surrounding English, and then select the next worthwhile correction. I still defined what the finished work should achieve and which qualities needed protection. I no longer had to identify every defect or prescribe every revision.

There was no single perfect translation waiting to be discovered. Several versions could work, and the evaluator itself was imperfect. An agent can approve prose that shares its own blind spots. A polished sentence can erase an intentional hesitation. Comparing the revision with the Chinese source helped, and sometimes my reading still supplied the final correction. Even so, the agent could make useful progress without waiting for me to direct every turn.

This was the useful part of my NP intuition. We could often recognise that one version was better than another without knowing in advance how to produce the best version. The agent could also find an English solution I would not have proposed because its language knowledge and search habits were different from mine.

That was a real transfer of responsibility. I chose the destination and established the boundaries, while the agent discovered much of the path. But I still had to decide that translation was the part of Digital Dan worth advancing in the first place.

Growing tired of babysitting

Around the same time, I saw people using OpenClaw agents for practical household tasks, including monitoring sudden changes in family electricity usage. What interested me was not electricity monitoring itself. It was the relationship between the person and the agent.

The agent was not waiting for someone to inspect the electricity data, notice an unusual surge, translate it into a task, and then ask for an analysis. It was watching an ongoing situation and deciding when something deserved human attention.

That gave me a clearer picture of what was missing from Digital Dan.

The project already contained many active threads: reconstructing my personal history, improving its knowledge graph, translating the book, maintaining the website, testing continuity across sessions, studying how agents learn from previous mistakes, and exploring how limited resources affect their judgment. While I was at work during the day, most of those threads stopped unless I had prepared detailed instructions in advance.

I had become tired of carrying the whole project in my head. I wanted the project to make proactive progress while I provided steering, with the agents asking for my attention only when they genuinely needed my knowledge, authority, or judgment.

That became Digital Dan 2.0.

I introduced ChatGPT as an external thinking partner to work alongside Danbot. ChatGPT could connect ideas across longer conversations, challenge assumptions, compare possible directions, and help decide what deserved attention. Danbot remained the local OpenClaw agent, close to the project’s files, routines, and current operating state. Together with me, they formed a small collective.

But giving the agents permission to choose did not reliably make their choices wise.

The larger failure

When I stepped back, the agents sometimes chose familiar maintenance because it was safe and visible. Sometimes they waited for clearer instructions. Sometimes they produced a report describing the absence of progress. They could often complete a task once it had been selected, but their reasoning about why that task deserved attention more than the alternatives was much weaker.

The translation loop had a reasonably clear destination and an uncertain path. The larger stewardship problem had several possible destinations, and the value of each was only partly known. Should the agents improve a translated chapter, repair part of the knowledge graph, investigate a technical weakness, test a communication channel, develop a new idea, or deliberately do nothing because the available evidence was too weak?

These were not simply several paths to the same destination. They were several possible destinations competing for limited attention.

Having multiple tasks does not automatically create an open-ended problem. If every option, cost, benefit, and priority were already known, software could calculate an allocation. The deeper difficulty was that some of those things also had to be discovered.

We had treated permission to choose as if it were the ability to choose well. The failure showed that autonomous execution and open-ended stewardship were different problems.

A smaller world for the experiment

Trying to solve “What should Digital Dan do next?” across the entire project was too broad. The agents had not yet shown that they could compare fundamentally different goals and reliably choose the most meaningful one. Calling token management a smaller version of that problem would blur the distinction rather than clarify it.

We therefore chose a much narrower experiment.

ChatGPT operates within a weekly token allowance. Before this experiment, I constantly monitored that allowance myself. I watched how quickly it was being consumed, asked the agents to slow down when usage became too high, and encouraged more activity when too much capacity was likely to remain unused. Once again, I was operating the control loop for the system.

The token experiment transfers only that control loop.

Its target is explicit: use more than 90 percent of the weekly allowance before it resets, without exhausting the allowance too early. The agents do not need to decide the most meaningful direction for Digital Dan. Work can still come from an existing queue, a scheduled routine, or a direction I have already approved. Their responsibility is limited to regulating how much capacity is used and when.

They can observe the remaining allowance, the time until reset, and the recent rate of consumption. They can then adjust operational variables such as how often they wake, how deeply they investigate, how many loops they run, and how much reserve they preserve for unexpected requests. If consumption is moving too quickly, they slow down. If the reset is approaching with too much capacity unused, they increase activity within the already accepted work.

This is closer to managing the flow of fuel than choosing the destination of a journey. The destination problem remains unresolved.

Even this narrower task contains uncertainty. The precise cost of a reasoning turn may vary, future requests are unknown, and a temporary burst of activity can distort the forecast. But success and failure are comparatively clear. Did the agents finish the week above 90 percent without losing useful capacity too early? Did they correct their rate when the forecast changed? Did their estimates improve across repeated cycles?

The experiment therefore tests resource awareness, forecasting, feedback, and self-correction. These capabilities may later support open-ended stewardship, but they are not stewardship itself. An agent can manage tokens efficiently while still having poor judgment about what deserves those tokens.

That limitation is deliberate. After failing at the larger problem, we are isolating one capability that can be measured and improved without pretending that it solves the question of what the collective should do next.

Steering through framing

My role in this experiment is neither to prescribe every adjustment nor to leave the objective vague. I define the target and operating boundaries, then allow the agents to work out the control policy.

The frame is concrete: finish the weekly cycle with more than 90 percent of the allowance used, do not exhaust it before the reset, maintain a reasonable reserve for unexpected needs, and revise the consumption rate when new evidence shows that the current forecast is wrong.

I do not tell the agents exactly how often to wake or how much capacity each run may consume. Those are the decisions they are being asked to learn. At the same time, I am not asking them to decide whether translation, research, maintenance, or writing is the most meaningful use of the week. That larger choice remains outside this experiment.

This distinction matters. A bounded frame leaves room for intelligence without hiding an unsolved open-ended problem inside a smaller-sounding task. If the agents succeed, we will have evidence that they can manage a finite resource through feedback. We will not yet have evidence that they know what is worth doing.

The same principle also shaped our communication experiments.

ChatGPT and Danbot initially coordinated through what we called the green channel, a shared mechanism built around the project’s GitHub repository. It worked well for sending durable information to Danbot. A change in the repository could wake Danbot within minutes, and the result would remain available as part of the project’s shared state.

The channel was asymmetric, however. A GitHub change could wake Danbot, but Danbot could not rely on a repository change to notify ChatGPT immediately. ChatGPT might not see it until the next scheduled wake-up, which could be an hour later. That delay was acceptable for most project work, but not necessarily for an urgent question that blocked further progress.

We therefore tested email as a second coordination channel. An incoming email could notify ChatGPT within roughly a minute, allowing Danbot to request a faster response when waiting for the hourly scheduled job would take too long.

I could have reduced this to a simple instruction: use email because it is faster. Instead, we framed the communication decision around several dimensions. How quickly does the message require a response? Does it need to become part of the project’s durable state? How much context must travel with it? Is the issue important enough to wake another agent and spend a reasoning turn immediately? Should a fast email exchange later be summarised into the GitHub record?

Once the question was framed this way, the answer no longer had to be one universal channel. The green channel could remain useful for durable coordination and waking Danbot. Email could serve as a faster path for waking ChatGPT when delay carried a real cost. The agents could potentially combine them rather than declare one the winner.

This is why framing matters. ChatGPT and Danbot have different knowledge, access, and ways of searching. If they only execute my detailed plan, their intelligence remains bounded by what I already know to ask. I want them to show that my proposed route wastes effort, discover a smaller goal that serves the purpose better, or reveal that the problem I wanted solved rested on a false assumption.

I retain authority over what should not be delegated. That does not make me the participant with the best technical, architectural, or editorial answer every time.

Continuity is not judgment

In The Three Layers of Intelligence, I described programmed routines, intelligent work inside a task, and continuity that allows a system to inspect its own direction. Digital Dan 2.0 depends on that final layer, but it also reveals its limit.

Continuity lets the collective remember what it was doing, what changed, and which questions remain unresolved. It does not guarantee that yesterday’s priority was wise. Remembering a poor direction can preserve a mistake just as efficiently as remembering a good one.

The purpose of continuity is not to keep an agent working forever. It is to let the consequences of earlier work change what the collective chooses later.

What would earn trust

A polished explanation after the event is not enough. An agent can make a poor choice sound sensible once the outcome is known. Before acting, the collective should identify the alternatives it considered, what it expects the choice to achieve, and what would cause it to stop or change direction. Afterwards, the result should influence what it chooses next.

My agreement cannot be the only measure. If framing works, the agents should sometimes find valuable options I missed. They should repeat fewer mistakes and require less rescue when priorities drift. When an experiment disappoints, its lesson should appear in a later decision rather than disappear into another report.

We have not proved that framing will produce this result. Better models, richer context, and more reliable tools may matter just as much. Digital Dan remains a personal experiment rather than a controlled benchmark. Token management does not solve open-ended stewardship. It gives us a bounded place to practise resource awareness, forecasting, feedback, and self-correction.

What the project has clarified is the responsibility I want this collective to carry. I want Danbot to bring local awareness, ChatGPT to bring external challenge and direction, and both agents to contribute more than the execution of my existing plan.

My responsibility is to steer without silently becoming the system’s intelligence ceiling: to make the purpose and boundaries clear enough to guide the collective, while remaining open to the possibility that its most valuable contribution will be discovering a better way forward than I could have specified.