Clint.
Local agents, put to work.

01 / In use

From group participant to working assistant

The WhatsApp deployment put Clint into conversations with people other than me, including exchanges involving their agents. A group presents a much richer problem than a private exchange: several speakers, different intentions, overlapping conversations and statements that may be jokes, corrections or instructions. It raises questions about when an agent should contribute, whose request it is answering and what it should retain afterwards.

His current home is Slack. Alongside personal assistance and research, I use him to help keep track of the games I have built. The game tools include reading activity figures, counting current sessions where that information exists, and checking whether services respond. These are concrete tasks with answers that can be checked against the underlying systems.

Even that apparently simple work needs care. A missing activity figure must not be reported as zero. A service that answers a request has not necessarily established that everything is healthy. Reading a game's status is also a different permission from changing its settings or taking action against a player. Building these connections has made me examine exactly what each tool establishes and what authority the agent needs.

02 / Research

Research without a prompt for every step

I want Clint to do useful work between conversations. I have built background workflows that select questions from recent context, search and read public sources, and prepare research reports and briefings. The work includes scheduled technical research and self-review. The ambition is for him to notice an unfinished question, investigate it and bring back something worth my attention without needing me to specify every step.

The difficult part is establishing what happened during that investigation. Finding a search result, reading the source and supporting a conclusion are three separate things. The research workflow records what was actually read and keeps unresolved questions visible. I have also revised approaches that produced fluent reports without enough grounding. The standard I am working towards is research I can follow back to its sources and decide whether to rely on.

03 / Memory & dreaming

Memory and “dreaming”

A continuing assistant needs to remember enough to avoid starting again each time. But retaining everything creates its own problems: old instructions, superseded plans, other people's views and the agent's own mistakes can all return as apparently useful context. I have spent considerable time on attribution, retrieval and correction: who said something, when they said it, what it related to and whether it still applies.

“Dreaming” is my shorthand for reviewing earlier material in the background. The mechanism looks for patterns, conflicting statements and unresolved questions across attributed records. A proposed connection must point back to the material that prompted it and include a question through which it could be checked. It remains a hypothesis. Two accounts giving different dates, for example, should produce a question about which source governs, rather than an invented resolution.

The attraction is that an agent might find a useful connection I have not explicitly asked it to look for. The challenge is preventing its own interpretation from quietly becoming a fact in its memory. That distinction has become central to how I think about persistent agents.

04 / Self-improvement

Improving the agent itself

I am exploring how Clint can examine failures and help improve the system around him. This includes mechanisms for proposing code changes, running an existing version and a candidate through tests in an isolated environment, and returning the results for review. A proposal has to earn its place through evidence; generating a patch does not give it permission to deploy itself.

There is a separate question about learning from feedback. Some teaching experiments successfully stored a correction but failed when it had to be applied to a new problem. In one test, details from an illustrative example appeared in an unrelated answer. In another, the system invented facts to support a recommendation. The storage mechanism worked; the intended learning did not. Those results led me to set aside the failed approach.

This is where much of the development effort goes: working out whether a change has improved behaviour, whether the improvement transfers beyond the example used to build it, and whether something else has become worse. I remain interested in self-improvement precisely because it is difficult to establish. A convincing account of what the agent has learned is not sufficient evidence that it has learned it.

05 / Engineering

Making the parts work together

Running the system at home makes the engineering tangible. Local inference, retrieval, memory and background jobs compete for finite resources. Research has to yield when I need a response. Work needs a recorded state so that an interruption does not become a silently abandoned task. Connections to outside services need clear permissions, and an agent participating in a group must not acquire access to my private tools simply because I am also in that group.

These are the plumbing and wiring I want to understand. Changing a model or adding a tool affects the rest of the system, so I spend time tracing those relationships and testing the consequences. Clint is in use, but remains under active development; the more ambitious research, reflection and improvement mechanisms are continuing experiments.