Well, that took a while.
The Chief Agentic Officer Briefing is finally running. As of today, 11 October 2026, my newsletter workflow is live and sending emails. Grok Bot got the team up and running in about two hours.
Two hours. After all that.
But there is an important bit behind that number: I brought roughly a year's worth of work, experiments, mistakes and understanding to those two hours. This was not a blank page and a clever prompt. I already knew much more about what I wanted, what had failed and where the awkward bits were.
What I am excited about is not simply that another tool worked. It is that I can now spend my time improving the briefing rather than trying to deploy the thing that produces it.
This is part seven of my Agentic Operating System For Your Business journey. The previous chapter was Orchistra Was Meant To Run Everything. I Had To Stop. This is what happened next.
I wanted a briefing, not a second job in deployment
The idea behind the Chief Agentic Officer Briefing is fairly straightforward.
Gather useful research about agentic systems. Keep the sources. Work out what matters, what connects to what, and what it means for people running organisations. Then turn that into a useful, free briefing.
There is an audio companion too. And I want the research to accumulate, rather than disappear after an email has been sent. Today's research should help with tomorrow's questions, future articles and, eventually, other agentic work.
That is the job. Somehow, getting the machinery to do the job became a much bigger job.
The route I took
I started by writing the software from scratch to run on a server. Initially I used Cursor, then Codex. I could get things working locally, but moving them into production was another matter.
Different service structures. Deployment assumptions. Things that made sense on my machine and then did not behave the same way elsewhere. Fix one problem, find another. If you have followed the earlier chapters, you will recognise the pattern.
When I could not get that server version working satisfactorily, I ran the briefing using Codex itself. That was in July, and that route did work. It matters to include that: Codex was not simply a failure in this story.
It was also an earlier stage of my use of Codex. It has improved a great deal since then in my experience, so I would not use a July difficulty as a verdict on what it can do today.
Then I moved the work into OpenClaw. That took some setting up, but it worked reasonably well for a while.
The problem for me was maintenance. With the frequent upgrades I was applying, I kept finding that I needed to revisit and rebuild my skills. It felt as though I was doing that every week. Eventually I ran into corruption and problems in my setup, and I stopped that route too.
I cannot honestly say that I have proved why that happened. It could have been the way I built the skills, the way I handled upgrades, or a combination of things. I am describing the maintenance burden I experienced, not saying that OpenClaw upgrades break everybody's skills.
Finally, I decided to put a team together in Grok Bot. I used the knowledge I already had, explained the work, and got it running in about two hours.
That was a rather different afternoon.
| Stage | What happened in my setup | What I took forward |
|---|---|---|
| Bespoke build with Cursor and Codex | Local progress, but repeated difficulties getting the server deployment working. | A clearer picture of the workflow and its operational complications. |
| Codex run, July 2026 | The briefing worked through Codex itself. | A working route, and more understanding of the task. Not a benchmark of today's Codex. |
| OpenClaw | Worked for a while; maintaining my skills through upgrades became too much work. | What I needed from the environment, and where my setup was fragile. |
| Grok Bot, October 2026 | About two hours to get the team running, using the accumulated work. | Time to refine the briefing instead of constantly rebuilding its machinery. |
Why Grok Bot fitted this particular job
I needed an environment where the agents could keep working, use the browser, work with files and connect the stages together. I did not want to spend another stretch of time assembling the surrounding infrastructure before I could improve a single issue.
xAI describes Grok Bot as having a persistent cloud computer with a browser, command line and working files, which can continue working when your laptop is closed. That is a useful fit for this kind of workflow. It is the vendor's description of the environment, not proof that every task will succeed. Grok Bot computer documentation.
There is also a distinction worth remembering if you build a team: separate bot names do not automatically mean separate security boundaries. The documentation says files and credentials can be shared across the account's cloud computer. Permissions still need to match the job. Shared computer and account access.
For me, the result was a working briefing workflow, running on the server. Not a proposal for one. Not another local demonstration waiting for a deployment.
That is what made the difference.
The research should keep being useful
The newsletter is the visible output. The research underneath it matters just as much to me.
The workflow gathers information, stores the research, and uses my approach to decide what belongs in the briefing. My particular interests, my business experience, the connections I think matter: that is the part I want to keep refining.
I do not want a pile of AI announcements with a cheerful introduction. I want something that helps you understand what is changing, why it matters and what you might need to think about.
The wider workflow is intended to create an audio version for the podcast and distribute it through Spotify. The public podcast site describes the owned RSS feed as the canonical feed, with Spotify reading from it. That is the publication route, rather than pretending that generating an audio file is the same as getting it onto Spotify.
That page still showed a July episode when checked on 11 October. It does not independently verify a new October podcast from this setup.
I am also keeping the research for my own reuse, including agent-readable access through MCP. That means I can return to the information later, connect it to other questions and use it as context for future work.
That is different from offering everyone an open research archive. Public newsletter MCP access is still marked as planned on the site's agent information page. I would like to make the useful information easier for other people's agents to work with too, but I am not advertising an endpoint that is not yet publicly available.
Enough for this job does not mean enough for every job
Would I approach banking software in exactly the same way? No.
The consequences are different. I would want a much deeper understanding of the code, controls, dependencies and recovery behaviour before trusting it with that sort of work.
This is a free research briefing. Accuracy still matters. Subscriber information still matters. So do permissions, sending the right thing and being able to recover. But I can choose requirements that fit that job, rather than requiring it to behave like a bank before it sends its first useful newsletter.
The security arrangements look appropriate to me for the workload I am putting through them. That is my assessment of fit, not a security certification. Grok Bot's approval controls are useful, but they do not replace sensible access limits or my responsibility for what goes out.
On recovery, my arrangement uses daily snapshots. For this briefing, I am comfortable with an RPO of about a day and aiming for restoration in roughly half an hour. Those are the requirements I am willing to work with, not proof that the system has met them.
In plain English, RPO asks how much recent work you can afford to lose. RTO asks how long you can afford to be unavailable. They are objectives you set for the job, not results you prove simply by naming them. AWS's explanation of recovery objectives.
Daily snapshots could limit data loss to around 24 hours if every scheduled snapshot succeeds, includes the necessary state and is recoverable. That is a conditional data-loss window, not a demonstrated result. Half an hour is my current restoration estimate, not a timed, demonstrated recovery result or a Grok Bot guarantee. A proper restore exercise is how I turn that estimate into something I can rely on. Why recovery needs testing.
And recovery needs to include the newsletter's sending record, not just its files. I do not want a restored system cheerfully sending yesterday's issue again because it has forgotten what already happened.
This is not a verdict on every other tool
I am not saying OpenClaw is bad. It was not a brilliant fit for the way I had built and maintained this particular workflow. Someone else, with a different setup or better skills, may have a different experience.
Nor am I saying Codex could not do it now. My July route worked, and the product I use today is not the same experience I had then.
I do not have access to Dots. Perhaps it would help with this kind of work. Perhaps I would take a different route if I did. I cannot turn something I have not tried into a fair comparison.
Grok Bot was the tool I actually had available and could put to work. For this job, at this point, it got me to the outcome.
Now I can improve the briefing
That is the bit I have been waiting for.
I can spend time improving the sources. Connecting the stories. Making the newsletter more useful. Working on the audio. Figuring out which questions a Chief Agentic Officer really needs answered, rather than which deployment problem needs another afternoon.
There will still be things to fix. There will be things I get wrong. Running is not the same as finished.
But I am finally working on the thing I wanted to build, instead of spending all my time trying to make it possible to work on it.
So, credit where it is due: great work, Grok Bot. I am really happy with this.
You can join the free Chief Agentic Officer Briefing, explore the podcast, or find the show on Spotify.
I would love your feedback. What would make it more useful to you? What would you want it to cover? That is a much more interesting conversation than another discussion about why the deployment did not work.
Sources and notes
This is my firsthand account, dated 11 October 2026. The timings and deployment difficulties are my experience, not independently measured product benchmarks. The live newsletter status and snapshot arrangement are my account of my setup; the half-hour recovery time remains an estimate.
Product descriptions were checked against xAI's documentation on 11 October 2026: computer and apps, approvals, security and privacy, and recovery and troubleshooting. These are vendor sources, not independent reliability tests.
The briefing site provides the public subscription and podcast links. At the time of checking, its podcast page still listed a July episode; those links do not independently establish publication of a new October episode. Public newsletter MCP access remains planned. Recovery definitions and testing guidance come from the AWS sources linked above; this does not mean the briefing runs on AWS.