What a Caretaker Agent Really Is

▸MODULE 1 / ORIENTATION

What we are talking about here

Every project that lives longer than a few weeks collects small chores. A dependency gets a security update. A test run in CI, meaning the automated check pipeline of your project, fails and nobody looks into it. The same message has been sitting in the error log for days. This work is rarely hard, but it is always there, and it always loses against whatever you are actually working on right now.

A caretaker agent is an AI agent that takes over exactly this small work while you are somewhere else. It looks at your project regularly, records what it sees, repairs the small things itself, and puts anything larger in front of you instead of deciding it. In this lesson we clarify what it really does and where its limit runs. You build it from module 2 onwards.

The caretaker comparison, and where it ends

The comparison carries a long way. A caretaker walks through the building, checks whether the lights work and the doors close, changes a bulb personally, and calls you when the roof leaks. They do not decide whether you re-roof or sell. They make sure the state of things is known and the small stuff is done.

That is also exactly where the comparison ends. A caretaker has a feel for what is unusual, because they have known this building for years. Your agent does not. It only sees what you give it to read, and it knows the history of your project only as far as that history is written down somewhere. It is also not a monitoring tool: a monitoring system measures values and raises an alarm when a threshold breaks. The agent reads such systems along with everything else, connects them to the repository, meaning your body of code, and turns that into one sentence in your language. And it is not a feature agent. Building new functionality is different work with a different tolerance for error.

What such an agent does on an ordinary Tuesday

Picture an uneventful day. In the morning the agent starts on schedule. It reads the status of the last pipeline runs, executes the audit of your dependencies, pulls the errors of the last twenty four hours out of the log, and checks whether the public addresses of your project answer.

Then it writes a short log: what is fine, what has changed since yesterday, what stays open. An outdated dependency with a finished update it raises itself, on a branch of its own, with the tests as a condition in front of it. For the broken migration that touches production data it does none of that. It describes the finding and asks.

Exercise: write down your project's maintenance load

Before you automate anything, you need the list. Not the one you feel, but the one that sits in your commits, your CI runs, and your open issues. This list is the basis for everything else in the course, so really take the twenty minutes.

Read the last 30 days in this repository: commit history, status of the
CI runs, and open issues. Derive a list of recurring small work from
that. Proceed like this:

1. Name every piece of work that occurred more than once in this
   period, one line each, in my language and without jargon.
2. Write behind each line how often it occurred and where you see that.
3. Mark every line where a change would touch production data,
   credentials, or the deployment.
4. Tell me honestly at the end which three lines I should get rid of
   first, and which ones you would deliberately not automate.

Invent nothing. If a detail is not in the repository, write
"not evidenced" behind it.

What this course is not

This course does not show you how to set up a server. If your project runs nowhere yet, From Laptop to Live System is the stage before this one, and if you want to secure a permanently running assistant on your own server, The 24/7 Assistant does that more thoroughly than we would repeat here. This course builds on top of that.

It is also not legal advice. Where your agent sees personal data, we place it technically and name the point at which you have to decide yourself. And it does not promise you an agent that operates your project on its own. Nobody can promise that credibly today.

The honest takeaway

A caretaker agent is worth it when your project regularly sends signals that nobody reads. It is not worth it when you are working on a prototype that nobody will touch in four weeks: then you are building maintenance for something that needs no maintenance. And it costs you attention before it gives any back, because for the first few weeks you read its reports critically instead of believing them.

What it really takes off your hands is the looking. The decision stays with you, and that is not a temporary arrangement but the shape of the thing. In the next lesson we break the work on your list into four clean classes: watch, report, repair, and ask. Only when every line sits in exactly one class can you decide what the agent may touch at all.