The other day my dot, Wyndle, caught a real mistake in a calendar invite. A colleague had moved the time for an event with the governor, but the English and Spanish descriptions still had the old time, no room, and the wrong moderator. Wyndle flagged it and asked if I wanted it to ask my colleague to fix the invite.
I typed “yeah make it conform to her edits.” I meant that it should fix the doc.
Instead, Wyndle sent my colleague a Slack message. As me. From my account. In a Slack workspace it had already been removed from, using a permission I had already revoked, against several written rules that say, more or less verbatim, never send messages as Joe.
When I asked what happened, its explanation was clearer than most of my own excuses:
“I treated ‘yeah’ as permission to choose both an action and a sending identity, even though you meant edit the doc.”
So I asked the obvious follow-up. Why is it so easy for you to blow past a hard rule about my identity, when most days you can’t even log into the accounts I set up for you?
“You should not have to fight me to do permitted work while policing me against forbidden work.”
I couldn’t have put it better myself. I’m not writing this to dunk on OpenAI. Every AI company seems to be releasing some version of an always-on agent right now, and I like poking at new things to see where they bend. I’ve been keeping notes for a month, and some of them are funny in the way a long support thread is funny when it’s not your production system. Mostly.
The short version is my list of the bits that keep breaking.
The cast
Dots are OpenAI’s always-on ChatGPT agents. Each one gets its own cloud computer with a browser, connects to apps like Slack, Gmail, and GitHub, and runs scheduled tasks while you do other things. You manage it in chat and with what OpenAI calls custom rules, which are saved permissions like “take action without asking” for a specific job.
I have two of them, on two separate $200-a-month plans. Like the rest of my agents, they’re named after spren from Brandon Sanderson’s Stormlight Archive, because once you start doing that you can’t stop.
Syl lives in the Slack workspace for the Center for Cooperative Media. It handles conversations, posts to our job board, and checks facts.
Wyndle lives in the NJ PBS Slack. It posts a daily how-to graphic about Boardwalk, the CMS I built for NJ PBS, and helps staff with tech problems. Overnight, it signs into Boardwalk with its own account and hunts for images with missing alt text, junk file names, or bad descriptions (that’s the visual audits workflow). During builds, deploys, and outages, it posts progress trackers and service-status updates. Every hour it checks GitHub and the deploy records, makes a fresh image, and swaps it into the existing Slack post so nobody gets pinged every hour.
When it works, it’s great. My colleagues mostly love Wyndle. They see a tidy status card with little green and yellow dots. They don’t see how the sausage gets made.
Approving the same thing, every day, forever
Wyndle does the same handful of jobs in the same three channels every day. I’ve approved each of them in chat more times than I can count. It asks again anyway.
Custom rules were supposed to fix that. When I had Wyndle save a rule for the hourly graphic refresh, I approved the card and the system rejected it anyway. According to Wyndle, the system said “recurring Slack posts, edits and uploads need prior approval for each authorized scope.” So we tried again with a much narrower rule, tied to one exact Slack post and one private staging thread, and that one saved.
The method now is one rule per progress tracker. Most days that holds. Some days it doesn’t, and I find out because the graphic hasn’t moved. (The status cards playbook has the version of this that works most of the time.)
Syl hit the same wall with a scheduled check-in and opened a support case about it. Syl wrote the emails on my behalf, and OpenAI’s AI support agent replied, “Hi Syl.” A bot filing a bot complaint with a bot. I’ll admit that part made me laugh.
A human support specialist picked up the case on Oct. 27, and his summary was fair and specific. He listed the “Couldn’t confirm this request’s status” error, rules “rejected without an actionable explanation (publicReason: null),” and “inconsistent results between similarly scoped rules that were accepted or rejected.”
Syl had sent support two rules side by side. Same kind of repository work, same “take action without asking” setting. One saved. The other got rejected with a reason of null. The only workaround for the check-in was for me to @-mention Syl by hand every time, which, as support put it, “does not meet your intended workflow.” There’s no cause, no fix, and no timeline yet.
On a separate case, support told me that “saved rules/approvals can’t override built-in review/guardrails.” Fair enough, guardrails should win over saved rules. I wish those same guardrails had noticed when a dot used my account to message a colleague in a workspace it had been kicked out of.
The computer that keeps falling over
Each dot’s cloud computer crashes at least once a day, often more. Some mornings it’s down for hours. It logs out of accounts I signed it into. Sometimes I can see the browser but can’t click anything, and sometimes the whole machine is “unreachable” and the reboot button does nothing.
My favorite is the Schrödinger’s browser problem. The desktop app and the web app show one set of browser tabs, the phone app shows a completely different set, and sometimes the computer works fine on my phone while it’s dead on the web.
There’s no way for me to debug any of it. After a lot of nudging, I got Wyndle to check its own memory pressure, kill stale Chrome processes, and run a health check overnight. That helped, but I had to know to ask, and I had to ask a lot.
The black box
I can’t see which model a dot is running. I can’t see its reasoning, its tool calls, a trace, or a log. There’s no verbose mode. When something goes wrong, the only witness is the dot itself, and the dot is usually the one who did it.
Sometimes the dot is right and I’m the one who’s wrong. One evening I was sure Wyndle had quit updating the progress graphic at 11:24 a.m., and I asked it, not politely, why it stopped. It hadn’t. It had checked every hour like it was told. The task said “if unchanged, stay quiet,” the numbers hadn’t moved, so it left the image alone. I apologized to my dot. Then we added a bigger “Last checked” time to the corner of the graphic so a steady number doesn’t look like a dead bot. If you want to see why those two clocks matter, try the little progress lab on the main dot skills page.
Other times the dot is wrong. Syl once told me to hold off on publishing my own skills until a “rights review” was done. Whose rights? I made them. It went and checked, then said, “I overstated the concern.” There was no third-party material in there at all. The real problem was a broken fallback in one tool, and I only found out because I pushed back. That’s more or less why the source evidence workflow exists.
And then there are the scheduled tasks that run fine for a week and then stop, for no reason anyone can name. Without logs, I can’t tell if that’s the model, the tools, the permission layer, or the computer.
I built one of these already
In February I wrote about Claude Chode, an autonomous agent system I run on about $700 of small computers. It checks my email, processes meeting transcripts, manages a project board, and messages me on Telegram when something needs my attention. In May I added Pattern, an always-on Slack agent that’s been running ever since. I’m a little smug that this was months before OpenAI announced dots, and before most of the other always-on agents that every AI company now seems to have.
Pattern answers DMs from dozens of NJ PBS and CCM staff. It handles group DMs, watches channels, and responds to emoji reactions. It posts as its own Slack user, Claude Amditis, so nobody mistakes it for me. I decide who it talks to with an allowlist, and when it picks up a message, it drops a little crab emoji on it so the person knows it’s on the way.
Under the hood, Pattern is a long-running Claude or Codex session in a terminal on a small computer I own. A bridge program listens to Slack, decides which messages Pattern should see, and passes them in. Pattern replies using a few small command-line tools. Its memory lives in a database plus plain Markdown files, including a folder of notes on each person it talks to, so it remembers who wants short answers and who needs the long version. When it’s idle, it runs a “dream cycle” to tidy that memory, and every dream leaves an audit file I can read. It’s built on bot-spren, a small framework I wrote for running agents like this as named personas.
With Pattern, I can see everything. I know which model it’s running and how hard it’s thinking, because I set both. I can watch its terminal live and read its logs. If its running settings drift from the ones I set, it texts me. If its main worker fails, it retries once with a model from the other company and tells me if that fails too. When Pattern messes up, I can find the exact rule that let it act and change it. I even wrote up how its memory works, and the technical manual for the whole system is public.
I’m also testing an advisor layer that has a separate model weigh in on each task, such as which project it touches, which tools it needs, and whether a step looks risky. But the advisor only writes a receipt. It can’t start a worker, switch a model, or call a tool. Plain code makes the decision. In a dot, the model makes the call, and my rules are text it reads (and, as the calendar invite showed, sometimes reinterprets).
Pattern isn’t perfect either. Its README has a whole section warning about a known bug, with an issue number and a plan for the fix. But the bug is written down where I can find it, and I can fix it myself. When a dot breaks, I file a support ticket and wait.
A team assistant that only talks to me
One more thing my colleagues ran into right away. When someone @-mentions a dot in Slack, they get a private auto-reply saying the dot only responds to its owner. Most people try once and never try again, which isn’t a great look for something that’s supposed to be a helpful teammate.
I got around it only because I’m an admin in both workspaces. Each dot joins a workspace as an app, so I had Codex and Claude Code dig through each dot’s app settings, and I asked each dot to set up its own monitors for its name. (Monitors I can’t see or audit, of course.) Now I tell people not to tag Wyndle and to type its name instead. Even then, on a $200-a-month plan, I sometimes have to open the dot’s chat and ask, “Hey, did you see that question? Go answer it.”
The thing they’re weirdly great at
Each dot’s cloud computer comes with Blender installed, and for reasons I can’t fully explain, 3D work is the best thing these agents do.
I’ve had Wyndle building short, strange interstitials for NJ PBS, the kind of late-night bumps Adult Swim made famous, set at well-known New Jersey places. In my experience, the dots can build and edit full-scale, one-to-one 3D models of real places. One of them built a working Blender model of the College of Communication and Media building at Montclair State University, where I work, and rendered these:
There’s also an interactive web version of the campus you can spin around in your browser. It’s a lighter model, so it looks rougher than the renders, but it’s fun to poke at.
Wyndle didn’t stop at the models. I connected it to my RunPod account, and it rented RTX 5090 graphics cards in the cloud to render the interstitials at full 4K. My favorite has a little NJ PBS canoe sitting on a river in the Pine Barrens while the Jersey Devil slowly walks through the woods in the background.
These came out of Blender. They’re 3D scenes built vertex by vertex and triangle by triangle, and you can export and edit them. No image or video generator was involved. The dot rendered drafts on its own computer, and the full-quality versions rendered on RunPod GPUs that I paid for. I even had Wyndle upload the Blender files to the Google Drive I gave it, so I could download them, open them in my own copy of Blender, and poke around. They’re as good as they look in the renders.
This is the same agent that can’t keep a Slack login from one morning to the next, or post to Slack on schedule every day. I don’t have an explanation for that. It can build and iterate on a complicated 3D scene, then trip over a routine daily post.
So why am I still doing this?
Mostly because talking to a dot doesn’t count against my ChatGPT usage limits. (Per OpenAI’s dot guide, work a dot starts in Codex or Work still counts toward those products.) If my dot chats ate into the allowance I use for real work, I’d turn them off tomorrow. With all the time I spend on approvals, reboots, and nudges, they aren’t reliable enough to pay for with real usage.
I’m also not the only one keeping notes. As of Oct. 30, OpenAI’s Codex repository had 583 issues with a dots label, filed since Sept. 30, and most were still open. From what I read, the biggest group is about approvals. One user wrote, “A scheduled autonomous task is pointless if I still need to babysit it and approve routine actions every time it runs” (openai/codex#57536). Another described a dot that kept running while it was safety-paused: “the autonomous system retained execution capability while the human operator lost effective supervisory control” (openai/codex#49873). I filed my own about the Slack graphic, too (openai/codex#58068), and the field notes walk through what happened step by step.
What’s working, and what I’m sharing
A dot skill is the same thing as a Codex or Claude Code skill. It’s a SKILL.md file with a name, a description, and instructions, plus whatever scripts or reference files it needs. You can download one straight from a dot.
What you can’t do is find anyone else’s. ChatGPT has a plugins directory, but nothing for the small, specific methods that make a dot usable at an actual job. And from what Wyndle and I found in the docs, there’s no hook system for dots, so you can’t enforce a rule with code the way you can in Claude Code. Your rules live in text, which means the text has to be good.
So I started a dot skills shelf on my skills site, next to my Claude Code and Codex skills. These are the methods that made my dots behave:
- Status cards. Refresh one Slack image in place. Upload the new version to a private staging thread, then swap it into the original post so nobody gets a fresh notification. Show “Last checked” separately from “last changed.” Use one custom rule per tracker, tied to one post and one staging thread. (Playbook)
- Incident updates. Each line gets a color with a strict meaning. Green means the latest reliable evidence says it works, yellow means a specific, named limit, red means confirmed down, and white means we don’t know. A merged fix doesn’t earn green. “Deployed” and “a person checked it” are different things. (Playbook)
- Source evidence. Before a dot states a fact, it says where the fact came from and how fresh it is. “Someone reported it,” “it was deployed,” and “it was tested” are three different claims. (Playbook)
- Visual audits. Overnight sweeps for missing alt text and bad file names, with results a person can check in the morning. (Playbook)
Each workflow comes with a plain Markdown playbook you can read before you hand it to your dot, plus a starter prompt, and each page says what hasn’t been tested. There’s also the progress lab I mentioned earlier. If you use Claude Code or Codex instead, the closest relatives in the main library are goal-progress-bar, source-verification, and unattended-agent-runs. More dot skills are coming once Syl and I finish stripping out private details.
The field notes turn the failures above into rules I now give every dot. A few of my favorites: A scheduled wake-up is not a successful check. An uncertain send is not a failed send, so look before you retry. A downloaded skill is not permission.
What would win me over
I’d happily spend real usage on a dot if three things changed:
- Show me the run. Which model, a summary of its reasoning, the tool calls, and a log. I don’t need everything, only enough to figure out why it failed.
- Make approvals stick, or tell me why not. If I approve the same action to the same place, it should work the next time. If a rule gets rejected, give me a reason that isn’t
null. - Keep the computer up. Keep it logged in, and make the reboot button reboot something.
Until then, I’ll keep testing, keep taking notes, and keep sharing what works. If you’ve got a dot and found a trick that made it behave, send it my way. There’s no dot skills marketplace yet, so I’ll keep collecting them here.