From the series "Applying Psychology to Building AI Harnesses"

I continue to be fascinated by how psychological concepts can inform AI design. In previous posts, I explored forgetting as a useful property of an AI memory system and attention as a way to prioritize work. Another concept that seems surprisingly relevant is perception.

In psychology, perception is the process by which the mind organizes and interprets sensory information into a meaningful understanding of the world.

It is important to distinguish this idea from perception in computer vision or multimodal AI. I am interested in a broader question: how should an AI system perceive the world around it?

The information may come from cameras, microphones, sensors, user interactions, APIs, emails, logs, monitoring systems, or countless other sources. How does the system combine these observations into a coherent understanding of what is actually happening?

A simple AI harness is a loop: prompt → model → tool call → result appended to the context → back to the model. There can be as many rounds as many tool calls are requested. It works, and it has one serious weakness — every round is more expensive than the last one, because every tool result makes the context bigger.

Delegation is the fix. A delegated agent gets only the context it needs, does the messy multi-step part on its own, and returns a single answer. The main conversation stays short and cheap. It can also be given a cheaper model and a much narrower set of tools than the main assistant.

DMJBot supports three kinds of delegation:

Local models are getting good enough to become part of daily work. The problem is that they usually stay locked to the machine where they run. Your laptop has the model, your cloud assistant has the uptime, and your phone is somewhere else entirely.

DMJBot now connects those worlds.

You can run open-weight models locally with Ollama and make them available inside your DMJBot instance, even when DMJBot itself is running in the cloud. Your own hardware does the inference. Your assistant stays available from anywhere. And when you open DMJBot from a browser or mobile app, that local model can be one of the models behind the conversation.

It is a simple idea, but it changes the shape of the setup: local compute, cloud presence, mobile access.

When we built the first version of the DMJBot mobile apps, audio input was near the top of the list. Not as a nice extra — as one of the reasons to have a mobile app at all.

The use case we had in mind was very specific:

"I'm away from my laptop and an idea hits me. I want to do something with it now — not just store it. I want to think it through, get some pushback, maybe turn it into a task for later. And I want to do all of that from my phone, fast."

Notes apps solve the first half of that. You write the idea down and it waits for you. But an AI assistant can do the other half — react to the idea while it's still warm. The only thing standing in the way is the keyboard. On the go, walking, driving, in a queue, you're not going to type three paragraphs. So we added the microphone.

Some places do not just host innovation. They shape how it happens.

People often talk about innovation as if it only belongs to a few obvious places. London. San Francisco. Berlin. Somewhere with a polished pitch deck, a rooftop office, and a permanent camera crew filming founders drinking coffee.

That has never felt true to us.

We live and work in the North East of England, and the more time we spend building AI systems and autonomous agents here, the more it feels like one of the most natural places in the world to turn ideas into reality.

Our team has been kicking around a new feature for DMJBot, and one question sits right at the center of it:

Should an AI assistant have a configurable level of initiative?

Could the assistant do something on its own — while you're not around — and could you turn that up or down? Make it very active, or barely active, or shut off all self-started actions entirely?

We think this could be genuinely useful, so before we start building it we want to describe it here and get feedback from the community. Here's what we have in mind.