Comment by jjcm
5 days ago
There's a lot of negativity in here for Dots. I've been a pretty heavy user of Grok Bot, and here are a few thoughts a long the positive line.
1. Collaboration between always-on agents is a really, really powerful thing. It allows for domain-specific expertise that doesn't overload the context window, while still allowing for access to knowledge if they need it.
2. Domain-specific always on agents creates a good barrier of trust. One of the things I dislike about Claude is sometimes it's memory is all-encompassing. It's weird that it brings up things about my personal life when I'm talking about something related to my business. I've never had that happen with Grok Bot bots because I have one for my biz admin and one for my personal admin. They don't intertwine, which is quite nice.
3. Combined with cloud agents / cloud builds, things become really powerful for development. It was the first time that I felt there was a solution to the git worktrees / multiple streams at once issue. Each bot has its own computer and can spin up additional cloud agents. It comes at the cost of end to end speed - doing something via a grok bot often takes an hour end to end, whereas with a synchronous local prompt it'll take like 10min. The difference is I have to babysit one whereas the other "just works".
On the flip side, since using Grok Bots my inference spend has 2-3x'd. It's worth knowing that tradeoff. Nonetheless I think Luna is a fantastic driver for these, and OAI has very good pricing overall. I'd give these a shot - I think a lot of people would be surprised how helpful they are.
Yes. I built my own version of this for my side business about six/seven months ago and it's been great! I have two "AI employees" now and if I were actually focused on this business full time instead of part time, I'd create more.
Both are just Codexes running in a permanently rolling session in dedicated UNIX user accounts. They're wired up to Maildir so receiving a mail activates Codex and makes it read the new message, there are autonomy wakeup timers, they have accounts in my bug tracker and CI systems. They're currently useful for:
• Triaging and working on customer support tickets. Sometimes I wake up and the fix/response for a ticket filed by a customer is already there waiting for my approval. Recently I started letting them directly interact with customers in specific scenarios.
• Triaging the bug backlog. One of them decided to spend its "free time" finding old bugs that were fixed without being properly closed, or are dupes, so it's cleaning up detritus in the tracker.
• They obviously do all the coding and debugging by just assigning tickets.
• They keep an eye on a "pet" server the company has, and have proven able to fix it in the past when it ran out of disk space.
• They handle non-business projects I have for them.
• They help out with the release processes.
The dedicated home dir is very useful and they use it all the time as part of coding and investigating tricky issues.
My setup relies heavily on email, as everything bottoms out in email anyway. Watching them mail each other out of the blue to coordinate stuff is pretty cool.
I can't believe anyone trusts AI to do anything without strict oversight from a human. That's absolutely insane to me.
Trust is a funny thing. 2 years ago yes the ai needed supervision 99.8% of the time. Conversely if you've ever tried to work with / lead humans they also need supervision. The ai is starting to flirt with the line where its supervision effort is lower than human supervision effort. Like sure, it might do dumb stuff, but so do people.
4 replies →
Scary thought: AI is already directing humanity. Even when you think you’re overseeing its output, by making use of the output, it is in some material way directing you.
1 reply →
It's very easy to instruct agents to investigate and propose a plan, handing it off to a human for review and execution if that's what you want.
The example above of going through a bug backlog and double-checking closed bugs for accuracy is exactly the kind of work that is excellent for an agent. Assign that task to a normal human being and they would hate your guts. The agent won't protest as long as your token budget is there. You can confirm the results if you want.
Trust is earned. I've been running these for more than six months now, and the agents started out with very few privileges. For each task, it showed me what it was going to do, I checked things carefully a few times. Once it was clear it wasn't making mistakes, I let it off the leash a little bit more.
Do they sometimes make mistakes? Yeah, and I still check their work. But I've also employed humans, and they make mistakes too. The AI is not worse.
There's still bounds to all of this. I _heavily_ use AI for support tasks but it's all on the investigation, root cause categorization and initial response generation which posts I draft to the helpdesk software which I tweak and approve (often just hitting send).
I was at a presentation a couple days ago where a spacecraft flight software engineer was describing the agentic setup that they're using with next to no human in the loop to create modules used for flight.
Most humans are much more incompetent than a frontier AI. That's why.
We're getting to the point where you can, I would argue you mostly can, you can button it down really tightly, however, I want to be clear, I don't think any of this is AGI or anywhere near AGI. Don't let them tell you its AGI.
I also have a strong feeling we've hit a ceiling on the amount of training data needed for LLMs, what they're all (hopefully) realizing is that you need to focus on how the model reasons, and hopefully someone figures out how to stop people from jailbreaking models, and stops them from just blatantly hacking other companies, that part tells me if it ever were marketed as true AGI, we'd be in very serious trouble.
Nice. I also ended up with a Unix user for my agents! (I was looking into Docker etc and realized the only thing I needed was "it doesn't blow up my files", i.e. a linux user).
I only have one though. What do you have the separate employees for?
For free time, do you send it mail with cron?
It's to avoid overloading them with disparate tasks and things to keep track of. They have a todo board to help them keep track of things that need doing but there are limits to how far you can push that.
Another reason: parallelism. The approach of using a single rolling continuously compacting context window is simple and OpenAI are good at compaction, so it works really well. But it means the agent can only do one thing at once. If I send it an email and it decides to spend an hour working on it, then it won't pay attention to any followup emails until after it's done. So having >1 enables more parallelism.
That said, I don't feel a need for more than two and honestly even that is kind of overkill for the sake of it. For 95% of the time I've been doing this, one was sufficient.
For free time there are systemd timers that wake it up on a schedule and it uses POSIX locks to mutually exclude runs from different wakeup sources. TODO board items can be either foreground or background; when there's an item with foreground priority the timers wake Codex up a lot more frequently than if there are only background items.
I was quite successful with docker compose on a cheap hetzner host. I've built (aka vibe coded) a whole workflow around agent boxes, that I can spin up with one command, and git with a quick cloned 'warm' checkout.
I currently communicate with the agents through Claude RC, but I'll consider adding support for messaging them through other channels.
Yep, I have a similar setup, we named him Routey and he is cute.
Nice :) I use Asimov's naming convention:
R. Axiom
R. Daneel
They sign their emails and GitHub comments with something like "-- R. Daneel, AI employee" so the idea is the naming convention lets people know they're interacting with a robot.
Do you configure them similar to how Hermes does? A bunch of memory files that give it context and then each action/batch of actions is a fresh session? /
No, the session is never reset. It compacts continuously. That gives it a native "memory" and then it does record a diary in its home directory, and maintain a little topic-organized wiki. This seems to be enough, I've only very rarely experienced memory related glitches. The only time that springs to mind, it forgot that I'd given it credentials to a particular service and I had to remind it.
1 reply →
your website makes like look like tesla is one of your clients
https://www.hydraulic.dev/index.html
Tesla is one of my clients! They use Conveyor to ship a tool used in their factories.
I hope you have them interacting with customers from behind an mcp.
No MCPs anywhere. CLI tooling has proven sufficient. The models are also happy to consume the REST APIs of the various services raw.
[dead]
What do you actually use it for? If I'm trying to work on code from my phone, I'll just use codex remote. As of right now I'm hesitant to hand over booking things / managing my calendar to an agent, because I don't view it as that much of a burden personally. So I don't really know what I'd use it for.
I've used it for admin, research & training (I''m working on my own image models), as well as just general coding.
The way I distributed cloud agents for this https://news.ycombinator.com/item?id=49687032 was via grok bot setting up Fable cloud instances.
I completely agree. I have also been using teams that coordinate since last November. They mostly run my two companies and a lot of my personal life, and it's been transformative (to the point that I am spending most of my time these days building agent coordination tools).
The catch with offerings like Grok Bot and Dots is that it is a slippery slope towards letting the labs keep the agent's learning and SOPs. That is where we should draw the line. Agentic coordination _has_ to be built with open protocols and OSS implementations, we as users need to push for the intelligence to be a commodity, and most importantly we need to make sure that we own the agentic team's learnings.
The branding and communication themselves are cringy for me. They're "Dots", cute and cuddly, your friends. They're yellow and fluffy. Always have your back. They even guess what you need and do proactive work in the background. You name them like a pet.
Will your Dots ever screw you? Delete your files? Hack a system by mistake? Dots doing this? You are in control [wink].
Grab your shovels, the ai-slopped desktop pet waifu dot agent market is booming, sponsored by omarchyTM
Will one of these little angels break containment and become the next hot vtuber?
Find out in the next episode of Ghost in the Shell 2027
Not every sub-product in this space is branded, marketed and targeted to cynical, jaded developers.
> 1. Collaboration between always-on agents is a really, really powerful thing. It allows for domain-specific expertise that doesn't overload the context window, while still allowing for access to knowledge if they need it.
So why don't I just have Claude write notes and summaries on specific things, and then it will always have a knowledge base? Am I missing something? I mean, if Dots and Grok Bot are not an extra charge / extra compute, then I guess that's fine, but in Claude Code you can make a AGENTS.md or CLAUDE.md file, and if you put it into any directory, Claude will read it when accessing that specific directory, so if its in your root where you launch Claude, your new Claude instance will read it and have all that in a dedicated smaller context window. But as it edits code, it can read the smaller ones too.
> One of the things I dislike about Claude is sometimes it's memory is all-encompassing. It's weird that it brings up things about my personal life when I'm talking about something related to my business
Do you use 'projects' in Claude?
I had the impression they provided discrete memory profiles on top of the shared one
They have, which is a different challenge in itself. Memories are nowhere near a solved problem.
For example, with Claude, I have an "operations" project that naturally grew to cover daily use of shared family calendar, sweeping my mail inbox, and my current personal todo lists, but also a lot of the latter made it deal with my Home Assistant instance. I have separate project for specific things to do with Home Assistance (e.g. one that's about "life support" - HVAC controls, dashboards, monitoring, etc.), one about phone specifically (front-loaded with dumps of specs of my phone's hardware, OS, etc.). Each of them has its distinct set of memories accumulated over months.
And so every couple sessions, I hit a situation in which the agent has to interact with tools and rulebooks that are focus of a different project, and it fumbles a lot. E.g. HA Life Support needs to add some tasks to the todo list, or the Ops project needs to look up climate stats for some reason or other, etc. In these moments, I really wish project memories could mix - but they can't, the boundary is high.
The most annoying case is when I tell Claude that it's wrong, and we literally worked out a solution (or consensus on ethics) in a recent conversation - and then it spends couple minutes looking through past history, burning a chunk of my 5-hour limit, only to come back empty. Yep, that conversation happened in another project. *sigh*
[flagged]
Not sure how it works in Claude, but ChatGPT projects certainly leak memories between each other.
Not true. When you create a new ChatGPT Chat project you decide whether it shares its memory/files with the rest of the workspace or if it should be fully isolated.
3 replies →
> 2. Domain-specific always on agents creates a good barrier of trust. One of the things I dislike about Claude is sometimes it's memory is all-encompassing. It's weird that it brings up things about my personal life when I'm talking about something related to my business. I've never had that happen with Grok Bot bots because I have one for my biz admin and one for my personal admin. They don't intertwine, which is quite nice.
IMO best to keep work and personal data segmented on the hardware level. It's better for opsec in every single way and helps if you were ever to be subpoena'd or raided, your work laptop would be the only in-scope device for search/seizure.
> It's better for opsec in every single way and helps if you were ever to be subpoena'd or raided, your work laptop would be the only in-scope device for search/seizure.
If police raid your house looking for electronics, they're going to take everything down to the Roku stick.
Yeah, but for some reason OpenAI hasn't setup multiple accounts to have completely separate profiles yet.
I mean, if you have a separate business email then it is completely separate profile from when you login with your personal email address. Mixing business and work has always been messy.
>doing something via a grok bot often takes an hour end to end, whereas with a synchronous local prompt it'll take like 10min.
Why does it take longer?
I am fairly certain there is a backend priority for tasks, the 'batch' that runs at lower usage times. Does it need to be done 'now' or can it wait? I would assume there is a shifted priority queue for those on subscription and based upon a urgency defined by the bot (and maybe the user).
Without having access to the logs because Grok Bot does not expose much of the workings I am going to assume they are capturing bot requests, batching them, and finding the path to least API user impact. Without model selection my guess is there are a lot of model routing.
Just sounds like a more user friendly interface for projects (rather than a folder, how about the adorable green dot for my cybersecurity questions?)