August 10, 2026
I Went to Italy for Two Weeks and Left My Laptop at Home
In July I spent two weeks in Italy. I brought an iPad and a phone. I did not bring a laptop.
I run a software company by myself. There is no engineering team to cover for me, no on-call rotation, no one else with production access. In a normal version of this story I either cancel the trip, or I bring the laptop and spend the vacation working, or I accept that two weeks of nothing happens.
None of those is what happened. While I was gone, thirty production releases went out. A hundred and sixty-seven pull requests merged across four repositories. The daily health check ran every morning, found real bugs, and shipped the fixes. My contribution was an hour or two most afternoons, from a hotel room, on a phone.
People keep asking me how. So this is the how, in enough detail that you could copy it.
A warning before I start: this is not a tool review and I am not going to tell you the setup is easy. It took months of building, and it broke in the middle of the trip in a way I will describe so it does not break for you.
What I actually mean by "personal AGI"
I use the phrase carefully, and mostly in private, because it sounds like a bigger claim than I am making.
I do not mean the thing the labs mean. I am not claiming a system that can do anything a human can do. What I mean is narrower and, to me, more interesting: I supply direction and taste, and a system of agents does the planning, the building, the testing, the shipping, and the watching. Every job in my company except judgment has been handed off. The work does not wait for me to be at a desk. It waits for me to have an opinion.
That is the shift. My hours at a desk used to be the ceiling on what my company could do. They are not anymore. What limits us now is how fast I can decide things, which turns out to be a completely different constraint with completely different solutions.
If you build this, the goal is not to work less. It is to make your presence the scarce input rather than your typing.
The setup, in parts
1. One machine that never sleeps
The single biggest unlock: the machine running the work is not the machine I carry.
I have a computer at home that stays on, plugged in, connected, and awake. That machine hosts every running session. My laptop, my iPad, my phone are thin clients. They connect to the host, give it instructions, and disconnect. When my phone battery dies, nothing stops. When I close a laptop, nothing stops.
Almost everyone gets this backwards at first. I did. If the sessions run on the laptop you carry, then closing the lid pauses your company. A MacBook sleeps on lid-close no matter what you have configured in Settings, so "I'll just leave it running in my bag" does not work. Move the work off the device that travels with you.
Two practical notes. Keep the host on AC power with the lid open if it is a laptop. And have more than one host if you can. I ran a Mac Mini and a laptop at home, both working, which meant a single machine falling over did not end the trip.
2. Authentication that outlives the trip
This is the part that broke, and it is the most useful thing in this post.
Halfway through Italy, every remote session appeared to need a login. I was on a phone, in another country, with no way to open a browser on the host machine. It looked like everything had died.
It had not. The sessions were fine and still running. What had expired was the authentication. Subscription logins expire on their own schedule and force an interactive browser sign-in, which is exactly the thing you cannot do from a thin client two thousand miles away.
The fix takes five minutes and you must do it before you leave. Run claude setup-token on each unattended host. It mints a token good for about a year, and you store it in ~/.claude/settings.json like this:
{ "env": { "CLAUDE_CODE_OAUTH_TOKEN": "<token>" } }New and restarted sessions read the token and never hit a login wall. Treat it like a password.
If you find yourself already stuck mid-trip the way I was, there is a way out that does not need SSH: tell a session that is still running on the host to run claude setup-token itself, have it print the URL, do the browser sign-in on your phone, and paste the code back. Only the sign-in needs you.
3. Written instructions the agents actually read
The agents do not know what my company is doing. They read it.
Every repository has a file at its root that describes how work is done there: the conventions, the branch rules, what to do before opening a pull request, which mistakes we have already made and how to avoid repeating them. There is a personal one above all of them for the things that apply everywhere.
This sounds like documentation and it is not. Documentation is written for humans who might read it. These files are read every single time, by everything, and they are the reason an agent working at three in the morning makes roughly the decision I would have made. When I correct the same mistake twice, I stop correcting it and write the rule down instead. The correction becomes permanent.
The roadmap lives in the same place: written down, in issues and plan files, specific enough to build from. Agents built against that roadmap all day in Italy because the roadmap existed before I got on the plane. This is the prep that matters most and it is not technical at all. If you are vague about what you want, distance turns the vagueness into wasted work.
4. One loop per repository, and isolation between them
I run a separate session for each codebase, and each of them works in its own checkout.
The reason is boring and important: two sessions sharing one working directory will clobber each other. One switches branches while the other is mid-commit and the work lands in the wrong place. I learned this the way everyone learns it. Now every session gets an isolated workspace, and there is a hook that physically blocks branch-changing commands in the shared checkouts so I cannot make the mistake again.
If you are running more than one agent at a time, solve this before you leave, not while you are away.
5. A loop that reads production, not just one that writes code
Building is the easy half. The setup only earns your trust if something is watching what you shipped.
Every morning a loop runs a health check against the live business: are the emails sending, are signups happening, did any deploy fail, are there errors in the queue, did anyone cancel, did anyone write in for support. It writes up what it finds, files issues for the real problems, and where the fix is obvious it ships the fix and cuts the release for me to approve.
This is what let me relax in another country. Not that agents were writing code. That something was reading production every morning and would tell me if the company was on fire.
6. An escalation line, written down in advance
The failure mode of working remotely is not too little contact. It is constant contact. Fifty small questions across a day is worse than being at a desk, because you are neither working nor present.
So I wrote down the short list of things allowed to reach me: production outages, security, data loss, billing, infrastructure instability, auth failures affecting users, irreversible changes, anything with real blast radius, and genuine product judgment calls. That is the whole list.
Everything else gets a rule instead: make the most reasonable call, make it cheap to reverse, write down why, and keep going. Ordinary ambiguity never becomes a question. If the same kind of call keeps coming back wrong, that is a signal to write a new rule, not to start asking.
The clearer this line is, the more moves happen while you are living your life. That is the whole trade.
7. Batched windows instead of checking
I do not have notifications on for any of this. I open the batch, work through it, and close it.
In Italy that was roughly one window a day, an hour or two in the afternoon, at a table with a cold drink. Decisions came to me pre-packaged: here is the state, here is what was investigated, here are the options, here is the recommendation, here is the specific thing only you can decide. Most of them I could answer in a sentence.
Bounded contact is compression. Continuous contact is leakage. If you build all of this and then check it every twenty minutes, you have built an expensive way to be at work all the time.
8. Know what cannot be delegated, and stage it
Some work genuinely needs a human with eyes and a keyboard.
For me that is anything where correctness means looking at it. On an iPad, with logins that need manual approval, I could not open the app as a real user and see whether a screen was right. So that work did not ship. It got built, held on a branch, and labeled "needs human visual verification" for when I was home. Backend work that a test or a database query can prove was allowed to ship normally.
The other one is releases. Normally I click the merge button on every production release myself, on purpose, because it is the last sanity check before thousands of people get new code. During the trip I relaxed that, but only with a hard condition: no release ships without a rolled-up post-deployment checklist and a monitoring issue attached, verified after the merge, rolled back immediately if anything failed. The checklist is the entire safety mechanism. Without it you are merging to production blind.
Decide your version of these two lists before you go. Being specific about what you are not delegating is what makes delegating the rest feel fine.
What it costs
I will give you the number I have, because nobody else seems to publish theirs.
Each merged pull request costs my company about seventy-one dollars of total burn, down from roughly four hundred and thirty when I had a team. About twelve dollars of that is the AI itself. The rest is everything else a company costs.
The interesting part is not that it got cheaper. It is what got cheaper does to what you are willing to attempt. When a build costs a fraction of what it used to, you can go after problems that were previously out of reach for a company this size. The ambition became affordable before the team did.
The honest limits
This is not AGI and I am not going to pretend it is. It is a lot of scaffolding around models that are genuinely good at some things and confidently wrong at others.
It requires more of me, not less, in a specific way. Every rule the system follows is a rule I had to notice, decide, and write down. The system is exactly as good as my judgment, and it now applies my judgment at a volume I cannot personally review. That is a real risk and I think about it a lot.
It is also lonely. Working this way removes most of the reasons to talk to another person during a workday, and I did not fully register that until I had been doing it for months. I have been deliberately fixing that this summer, which is a different post.
And two weeks is two weeks. I do not know what six months of this looks like. I know what happened when I got on a plane, which is that nothing bad happened, and that surprised me more than it should have.
Try the small version first
If you want to build toward this, do not start with the trip. Start with an evening.
Move the work onto a machine that is not the one you carry. Write down what you want built with enough specificity that someone who is not you could build it. Write down the short list of things that are allowed to interrupt you. Then go do something else for four hours and see what comes back.
You will learn more from what went wrong in those four hours than from any post like this one, including this one.
I run Groupthink, which is software for keeping up with the people who matter to you. I build it solo, with agents. If you are running something similar, or trying to, write to me. I would genuinely like to compare notes.