Day two of building my AIOS was less about adding power and more about adding brakes. The main thing I built was a set of automation approval gates, because the more capable the system got, the more obvious it was that capability without control is just a faster way to make a mess.
The day before, I had built the foundation: a Markdown vault that any AI tool could read as a single source of truth. That solved the context problem. It also created a new one. Once AI tools can read my whole setup and act on it, the next question is not what can they do. It is what should they be allowed to do without me.
So June 12 was guardrails day.
I dropped Postiz and moved to Typefully
First, a tool decision. I stopped using Postiz and moved my social drafting and scheduling to Typefully.
This is not a takedown. Postiz just did not fit how I work. The interface kept getting in my way, and a tool I am supposed to use every day cannot feel like a chore to open. Typefully felt cleaner and faster for drafting and scheduling, so I switched.
I also spent time testing Claude Pro as part of the workflow. The point of having a vault that any tool can read is that I am not married to one assistant. I can try a tool, see if it earns a place in the workflow, and drop it if it does not. The AIOS makes swapping tools cheaper because the context does not live inside any single one of them.
The lesson here is small but real. Pick tools that reduce friction. A tool that technically does the job but annoys you into avoiding it is not actually doing the job.
Why automation needs dry-run rules
Before any automation touches something real, it should be able to tell me what it would do without doing it. That is a dry run, and I made it a rule.
When automation can reach WordPress, MailerLite, Typefully, my metrics, or anything public, just run it and see if it is not good enough. I want the system to be able to say, in plain terms, here is the action I am about to take, here is what it would change, and here is where it would land. Then I decide.
Dry-run mode sounds boring. That is the point. Boring is what you want from a system that can publish things on your behalf. The exciting version, where automation just acts, and I find out later, is exactly the version that eventually does something I did not want at a time I cannot undo.
The automation approval gates
The core of day two was sorting every possible action into three buckets. These automation approval gates decide what happens on its own, what waits for me, and what should never happen without my explicit yes.
The three categories came out like this:
- Safe and read-only. Reading files, summarizing, drafting, reorganizing notes, gathering information. These can happen freely because there are no public or irreversible changes.
- Needs approval. Anything that creates a draft in an external tool, changes settings, or moves work toward publishing. The system can prepare it, but I review before it proceeds.
- Never without explicit approval. Publishing, sending email, posting to social, scheduling public content, and anything that touches the public or spends money. These do not happen unless I clearly say so, every time.
The principle underneath all three is the same one I keep coming back to: draft first, approval second, publish last.
Reddit gets an even stricter rule. It stays manual. No automated posting, ever. Reddit punishes anything that feels automated, and more importantly, it is a place where being a real person matters. That is not work I want to hand to a machine.
The pieces that hold the gates together
Approval gates only work if there is somewhere to put work and a record of decisions. So I refined a few working notes to support them.
The Approval Queue is where items wait for my review, so nothing slips straight from draft to done. The Automation Experiments log is where I record what I tried, what worked, and what I decided not to keep, so I am not relearning the same lessons. The Metrics Log keeps the real numbers in one place. The Automation Plan ties it together and now carries the dry-run and approval rules directly, instead of keeping them in my head.
The theme is a paper trail. Good automation should create drafts, log decisions, ask for approval, and leave a trail I can read later. If I cannot reconstruct why something happened, the system is too opaque to trust with anything public.
The X lesson: replies beat posting
The other useful thing that happened on day two had nothing to do with automation. I learned that replying on X worked far better than posting into the void.
My follower count went from 8 to 26, and the growth came from replies, not from standalone posts. For a tiny account, that makes sense in hindsight. Posting to almost no followers is shouting into an empty room. Replying puts you into conversations that already have an audience, where a useful or honest comment can actually be seen.
I do not love social media, and I am not going to pretend a jump to 26 followers is a milestone worth a parade. But it changed how I think about the platform. For a small account, thoughtful replies are worth more than polished posts nobody sees. Conversations compound. Broadcasting does not, at least not yet.
That also fits the build-in-public idea. Showing up in real exchanges, about real work, is more honest and more effective than performing for an audience I do not have.
Practical takeaway
If you are automating any part of your work, build the brakes before you add more engine.
Concretely, that means three things:
- Make automation explain itself with a dry run before it touches anything real. If it cannot tell you what it would do, it should not do it.
- Sort actions into clear approval gates. Safe and read-only can run freely. Anything that creates external drafts waits for review. Anything public or irreversible needs an explicit yes every time.
- Keep a trail. A queue for what is waiting, a log for what you tried, and a plan that holds the rules. Automation you cannot audit is automation you cannot trust.
And on the social side, if your account is small, reply more than you post. Conversations reach people. Broadcasts to an empty room do not.
Final reflection
Automation without approval is just a faster way to make a mess. So the second day became about building brakes before adding more engine, and I think that order matters.
It would have been more fun to wire up something flashy that runs on its own. It would also have been the wrong move. I want AI to remove repetitive work, not quietly make decisions, and hope nothing weird happens. The gates make the system slower and a lot more trustworthy, which is the trade I want right now.
With the rules in place, the next step was finally building a pipeline that could move an approved idea into the right places. That is where day three went.
