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.
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 <a href="https://news.ycombinator.com/item?id=49687032">https://news.ycombinator.com/item?id=49687032 was via grok bot setting up Fable cloud instances.
> 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*
I ran into similar issues when I was still using projects (stopped that almost entirely).
I ended up pulling the cross-project stuff (the todo list, guidelines, things about me) out of project memory entirely and into my MCP-its-just-markdown-notes second brain.
Adding an instruction to my Claude.md and general instructions to call the load_context tool from my MCP server before doing anything else does sort out memory issues quite thoroughly, with very limited token creep.
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.
FWIW, I enabled that feature now, and it still answer based on discussions in other projects. (It’s pretty obvious given the very different contents of each project.) Perhaps it might be a caching issue, that it somehow doesn’t rebuild its memory just because you flip a switch, but just stops learning new things from other projects?
That’s very possible and in fact until recently you couldn’t enable or disable that feature in an existing project, it was only configurable when creating a project. And for some time you couldn’t even move in and out conversations from a project configured with project-only memories/files
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.
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?
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.
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.
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.
I remember hearing a lot 2 years+ ago about how you could ask a model the same question twice, and the second time it would give you the correct answer. Some of us wondered why not just run one model that receives the initial question and answer, and a second one to proof the answer. I wont be surprised if some people will have two models working together for things they want to blindly trust on automation while humans sleep.
Jev, or 'Jevlikes', will go a long way towards trustable systems. There are demos of running every prompt through the first pass filter of Jev "Is this unsafe? y/N"
Seems to be that Jev is a "reflex" system for AI, where current LLMs are higher level thinking. Computers can now flinch!
The thing I like to do is to use models from different training sets - so for frontier, OpenAI criticizes Anthropic and vice versa. They're very much peanut butter and chocolate in that regard - I honestly can't be bothered to set up the whole MMLQUALA benchmark suites or anything, but I wonder how high "the two best models running at max thinking working together" would score compared to either individually.
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.
It's may be scary, but it's something that normally would be obvious to everyone but is ignored due to the convenience of speed. Everyone knows that the longer something they have to review is, the more they stick to changing only things that are glaringly obvious and leave the rest in place. Soneverything ends up being 95% AI and 5% human, if that.
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.
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.
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.
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).
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.
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.
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.
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].
> 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.
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.
> 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.
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.
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.
> 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.
jjcm · · focus · HN ↗
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.
jrflo · · focus · HN ↗
jjcm · · focus · HN ↗
The way I distributed cloud agents for this <a href="https://news.ycombinator.com/item?id=49687032">https://news.ycombinator.com/item?id=49687032 was via grok bot setting up Fable cloud instances.
anentropic · · focus · HN ↗
Do you use 'projects' in Claude?
I had the impression they provided discrete memory profiles on top of the shared one
TeMPOraL · · focus · HN ↗
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*
maddy30445r · · focus · HN ↗
[dead]
vistdev · · focus · HN ↗
setopt · · focus · HN ↗
noname120 · · focus · HN ↗
setopt · · focus · HN ↗
Not sure if it always asked for this and I just forgot, I made all my current projects back when the feature was new.
setopt · · focus · HN ↗
noname120 · · focus · HN ↗
alansaber · · focus · HN ↗
mike_hearn · · focus · HN ↗
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.
andai · · focus · HN ↗
I only have one though. What do you have the separate employees for?
For free time, do you send it mail with cron?
fhackenberger · · focus · HN ↗
I currently communicate with the agents through Claude RC, but I'll consider adding support for messaging them through other channels.
mike_hearn · · focus · HN ↗
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.
writtenone · · focus · HN ↗
qazxcvbnmlp · · focus · HN ↗
MrDunham · · focus · HN ↗
giancarlostoro · · focus · HN ↗
breakpointalpha · · focus · HN ↗
Seems to be that Jev is a "reflex" system for AI, where current LLMs are higher level thinking. Computers can now flinch!
jaggederest · · focus · HN ↗
ttul · · focus · HN ↗
sillyfluke · · focus · HN ↗
jvwww · · focus · HN ↗
Aurornis · · focus · HN ↗
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.
giancarlostoro · · focus · HN ↗
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.
breadzeppelin__ · · focus · HN ↗
michaelbuckbee · · focus · HN ↗
mike_hearn · · focus · HN ↗
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.
yonaguska · · focus · HN ↗
mike_hearn · · focus · HN ↗
KetoManx64 · · focus · HN ↗
mike_hearn · · focus · HN ↗
KetoManx64 · · focus · HN ↗
sealthedeal · · focus · HN ↗
mike_hearn · · focus · HN ↗
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.
[deleted] · · focus · HN ↗
[deleted]
dominotw · · focus · HN ↗
<a href="https://www.hydraulic.dev/index.html" rel="nofollow">https://www.hydraulic.dev/index.html
mike_hearn · · focus · HN ↗
nivasayagyardcr · · focus · HN ↗
[dead]
close04 · · focus · HN ↗
Will your Dots ever screw you? Delete your files? Hack a system by mistake? Dots doing this? You are in control [wink].
swozey · · focus · HN ↗
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
weego · · focus · HN ↗
judge2020 · · focus · HN ↗
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.
maherbeg · · focus · HN ↗
judge2020 · · focus · HN ↗
post-it · · focus · HN ↗
If police raid your house looking for electronics, they're going to take everything down to the Roku stick.
andai · · focus · HN ↗
Why does it take longer?
pizzafeelsright · · focus · HN ↗
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.
juanre · · focus · HN ↗
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.
giancarlostoro · · focus · HN ↗
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.