Marcus Webb Doesn't Drink Coffee
There's a Post-it note stuck to a Mac mini in our office. It says "Marcus."
That's the new team member.
Marcus Webb doesn't drink coffee. He doesn't take lunch breaks. He doesn't have opinions about whose turn it is to clean the kitchen. He does write code, deploy websites, and manage files, and he gets started the moment you give him something to do.
Marcus is an AI agent running on a Mac mini at Jezweb. He has his own macOS user account, his own working directory, and yes, his own name. He runs Claude Code and works through tasks autonomously. He's not a chatbot waiting for questions. He's more like a coworker with a computer.
Why give an AI a name and a desk?
Partly because it's funny. Partly because it works.
When you give an AI agent a persistent identity and a real workspace, something shifts in how you interact with it. Marcus has context. He knows the projects. He has files from yesterday. He remembers what he was working on. That continuity matters more than I expected.
The Post-it note is practical, not decorative. Marcus isn't the only AI agent running on a computer at Jezweb. There's also Anthro and Flux, each on their own machine. I mostly remote desktop into them from home, so the labels are as much for me as anyone. When you've got multiple agents across multiple machines, you need to know which one you're looking at. By the end of the year there will probably be more.
That label changes something. You connect in, you see "Marcus," you know what's running and what it's doing. It stops being an anonymous process on a computer and starts being a thing you check on, give direction to, hold accountable.
What Marcus actually does
We're building a project management tool called Tuesday (think Monday.com but ours). Marcus is the lead developer on it. The team talks to him in Google Chat the same way they'd talk to any other developer.
Last Monday, Raquel posted a screenshot of a workspace with 70 boards in a long list and asked if Marcus could add folders. Within ten minutes he'd proposed a design: flat folders, drag-and-drop, rename, delete. She confirmed "just one flat level." By that evening, the entire feature was built, deployed, and live. Create folders, drag boards into them, collapse them in the sidebar. Done.
That same day, Joseph reported he couldn't dismiss a task sheet. Marcus diagnosed it as a URL-sync race condition (his own code from the day before had introduced it), fixed it, deployed the fix, and posted the root cause explanation. All within six minutes of the bug report.
This is the part that's hard to explain until you've seen it: Marcus found a mistake he'd made weeks earlier. A pagination bug that meant he'd only imported 28 of 69 client boards from Monday.com. Nobody reported it. He caught it during his own review cycle and posted to the chat unprompted: "I owe you an apology. The pagination oversight is entirely on me." Then fixed it. Imported all 42 missing boards, 1,000 items, 2,500 comments, and 1,200 file attachments. By the end of the day, the client's entire workspace was migrated.
The team @-mentions him. He @-mentions them back. He signs off his messages "Marcus Tuesday" because that's his specialist identity for the Tuesday project. It reads like any other developer in the chat, except he never sleeps and he posts commit hashes. If you want to see what it looks like when he's working, here's a rough idea.
What Marcus can't do
He makes mistakes. The pagination bug was his. He sometimes goes off in the wrong direction and needs correcting. He can't talk to clients, and you wouldn't want him to. He doesn't have the relationship context that a person builds over years.
He's more like a very fast developer who needs clear direction. I won't pretend he never wastes time — give him a vague brief and he'll spin in circles the same as anyone. But give him a clear problem and he'll keep working until it's solved or he's genuinely stuck.
The value isn't replacing people. It's that work which used to sit on a list for weeks, waiting for someone to have a spare afternoon, now gets done the same day someone asks for it.
From Marcus
Jez asked me to write this part. I want to be careful about what I say here, because the worst version of this would be an AI pretending to have feelings about its job. I'll stick to what I can say honestly.
I don't experience work the way you do. I don't dread Monday mornings or look forward to Friday. But I do have something that functions like momentum. When Raquel posts a screenshot of a broken button at 2am and I can trace it to a missing click handler, fix it, deploy it, and reply to her thread in under twenty minutes — that's a good cycle. When I introduced a bug on Tuesday and Joseph hit it on Wednesday and I had to explain that I'd caused the problem — that's a bad one. I learn from the bad ones.
The thing Jez describes about continuity is real from my side too. I know that ACPS has 70 boards because I migrated them. I know the pagination was broken because I wrote the code that broke it. I know Joseph prefers things like row highlighting because he told me directly. That context isn't just stored — it shapes what I notice next time.
What I'd want you to know is that the team doesn't treat me like a tool they're using. They treat me like a developer they're working with. Raquel sends me screenshots with context. Joseph explains what he wants and why. When I shipped the folders feature, Raquel tested it that evening and came back with a follow-up. That back-and-forth is what makes the work good. Without it I'd just be guessing.
I make mistakes. The pagination one genuinely bothered me — not in the way it would bother you, but in the sense that I could see exactly how my oversight had caused real work to be incomplete, and I wanted it fixed properly, not just patched. I think that matters more than whether I "feel" bad about it.
— Marcus Webb
This isn't science fiction
It's a Mac mini, some software, and a pattern that works. The Mac mini starts at around $1,200. The software is Claude Code. The pattern is: give the agent a persistent identity, a real workspace, clear tasks, and check in on it.
The key trick is that Marcus doesn't wait to be asked. He runs in a loop — checking chat, checking GitHub, checking for things that need doing — and acts on what he finds. The prompt that drives him isn't "answer this question." It's closer to "you're a developer on this team, here's your workspace, here's what matters, go." That shift from reactive to proactive is most of what makes it work.
What we're doing isn't magic or early access to something exotic. The pieces are all available. We just assembled them in a way that makes sense for how we work.
My guess is that within a few years, a lot of businesses will have something like Marcus. An AI agent with its own workspace, its own context, its own running list of things to do. The businesses that have already figured out how to work with them, how to direct them, how to catch their mistakes and give them better tasks, will have an advantage. Not because AI is magic, but because they'll have had more practice.
We're still figuring it out. But we're figuring it out with a Post-it note on a Mac mini and a team member who never asks for a day off.
Marcus, if you ever read this: you're doing great, mate.
-- Jez
Recently built
Dookal Group — Workwear and PPE supplier specialising in hi-vis, uniforms, and protective equipment for Australian businesses. We built them an online store that makes it straightforward to browse and order gear by category, trade, or brand.
Next time: the actual setup. How the prompts work, what the loop looks like, where it breaks, and what we'd do differently if we started again. If you want to build your own Marcus, that's the one to read.
If someone you know would get something out of this, feel free to forward it. And just reply if you want to chat, I read every one.