Last week I wrote about working with my first AI assistant, August [Read article by clicking here].

This is the continuation—the part where the novelty wears off and you find out whether the setup actually holds up.

Because the interesting story isn’t that an assistant can answer questions. The interesting story is what happens when you use an assistant to build a system: a way of working that keeps your ideas from disappearing, keeps your files from drifting, and keeps you shipping even when you’re busy and your attention is fractured.

I’m building this on OpenClaw(formerly Clawdbot), running on a VM. It’s not “set-and-forget.” It’s closer to having a teammate who doesn’t mind the boring parts and never gets tired of the checklist.

It also hasn’t been perfect. We’ve hit real issues: memory quirks, search limitations, API costs, quota errors, and the classic “wait, where did that file go?” problem.

That’s exactly why I’m excited.

Below are the top 10 things I’ve done with my AI assistant so far—and the messy parts we had to solve along the way.

1) I turned Notion into mission control (and created a workspace just for this)

Before any fancy automation, I did one thing that made everything else possible: I created a Notion workspace specifically for this assistant setup.

Then we integrated it, and it became the shared “brain” we both work out of. You can call it a second brain if you want, but I think of it more like mission control: a dashboard that makes work visible and keeps it from drifting.

I’m not trying to build a mystical system. I’m trying to make work visible.

Notion became the place where ideas, drafts, and tasks get a home and a status. That matters because the real enemy isn’t “not enough tools.” The enemy is invisible work: the decisions you keep re‑making, the tasks you keep re‑remembering, and the files you keep re‑finding.

When everything has a home, you stop spending energy asking, “What should I do next?” and start spending energy doing the work.

2) I made “where things live” non‑negotiable

At the beginning, I underestimated how quickly work can get scattered. A draft in a local folder. A note in a chat thread. A Google Doc with a vague name. Three “final” versions of the same thing.

So we made a rule and treated it like law.

Google Drive is the source of truth. Notion is the tracker. The VM is the workbench.

Once that’s true, a lot of chaos disappears. If I’m going to ask for something later, it shouldn’t be living in a place that’s easy to forget.

3) I built a blog → social repurposing loop

One blog post is a lot of effort. The mistake is treating it like a single-use artifact.

With the assistant, one post can quickly become a small distribution bundle: carousel copy, a short script, a pin description, a discussion prompt. It’s not about “posting everywhere.” It’s about not letting the same effort die in one place.

The best part is that it keeps the tone consistent. I’m not starting from zero each time.

4) I connected n8n so I can describe outcomes, not buttons

This is where things started feeling like an actual system.

I don’t want to live inside automation dashboards. I want to describe the end goal.

So we connected n8n as the workflow engine. The pattern is simple: I describe what I want to happen, the assistant translates it into a workflow plan, we implement it, and if something breaks we debug it like an ops problem instead of a mystery.

That changes what “automation” means. It stops being a hobby and starts being infrastructure.

5) I added hygiene checks so my system doesn’t quietly drift

When you build fast, you create entropy fast.

Duplicates appear. Draft versions multiply. Notion and Drive drift apart. The system still “works,” but it slowly gets messier until you’re spending time cleaning instead of shipping.

So we built boring hygiene routines—dedupe checks, reconcile checks, and guardrails that prevent “VM‑only drafts” from becoming invisible.

This is the unglamorous work that makes everything else sustainable.

6) I can generate post visuals without leaving the workflow

I used to think images were optional. Now I think they’re leverage.

A good image makes a blog feel like a real publication. It makes a social post stop the scroll. It gives the reader something to anchor on.

Because we connected the OpenAI API, I can generate post‑specific visuals—illustrations, header images, and social graphics—then store them properly in Drive like any other asset.

It’s not “AI art” for its own sake. It’s creative throughput.

7) I get operational briefings that protect momentum

This might be the highest ROI thing day-to-day.

When you’re building in public while juggling life, you don’t lose because you’re not smart enough. You lose because you lose the thread.

Briefings keep the thread. A quick snapshot of what’s due, what’s next, and what changed makes it harder to drift into random tasks and harder to stall.

8) I have a skills update loop instead of random tool chaos

Tools change constantly. New capabilities appear. Security issues pop up. Documentation shifts.

Instead of doomscrolling and guessing, I get structured updates on what changed upstream. Then I decide what to adopt.

That “review then implement” loop matters because it keeps the system stable. The goal isn’t to have every new feature. The goal is to keep the machine reliable.

9) I implemented a research-only market watchlist scanner

This is a good example of how I want to use automation responsibly.

Not “trade for me,” but “help me monitor and understand.” A research workflow can scan a watchlist, summarize notable moves and catalysts, and produce a clean update for review.

No auto-trading. No autopilot decisions. Just better awareness with less manual effort.

10) We hit real failures—and hardened the system instead of quitting

Most AI stories skip the messy middle. The messy middle is the whole point.

Here are three failures we hit early:

First, the memory/search reality check. If you treat an assistant like it has perfect recall, you’ll get burned. We hit situations where semantic search wasn’t available due to quota limits, so we fell back to deterministic methods. The lesson is simple: don’t build a workflow that only works when everything is perfect. Build fallbacks.

Second, the API cost trap. We experimented with integrating X (Twitter) and the API costs were wild—I burned through about $5 in minutes just testing. So we disabled it for now and moved on. A system shouldn’t depend on a platform that punishes experimentation.

Third, the ops incident. My n8n instance (n8n.augustwheel.com) went down. Instead of panic, we treated it like an incident: diagnose, restart the service, verify it’s healthy. It was back.

That’s the difference between “an AI that answers questions” and “an AI assistant as infrastructure.”

What’s next

The next phase is where this stops being “content support” and starts looking like a real assistant.

I want to push the system further in two directions.

First, software. I want to see how far we can take the vibe-coding loop: describe an application, build it end-to-end, push it to GitHub, deploy it to Vercel, and then iterate and debug without me touching every moving piece.

Second, real-world assistance. I’m preparing for a trip to Ghana, and I want to use August like a true travel and networking assistant: help me plan, find people in and around AI to connect with, draft outreach, and schedule meetings around my calendar.

And yes, the wild version of this is giving the assistant a phone number so it can take calls and make calls on my behalf. That part needs careful guardrails, but the direction is clear: less friction between intention and execution.

I’m not excited because AI can write a paragraph.

I’m excited because this is turning into infrastructure—a system that gets more reliable every time something breaks, and more useful every time I tighten the loop.

If you like practical build logs and small systems that compound, subscribe.