How I Built an AI Assistant for My Ghost Blog

I recently built a small workflow that makes writing for my blog much easier: I added an AI assistant as a contributor inside Ghost, the publishing platform that powers this blog, and connected it to Telegram so I can turn rough ideas into draft posts from a simple chat.

I was not trying to build the perfect integration. I mostly wanted to see whether a bot could behave like a real contributor and still produce something I would actually publish.

This post is actually a good example of how the workflow works in practice.

It started with a message I sent through Telegram. I asked the assistant to write an article for my blog explaining how I built an assistant for my publishing workflow, what that assistant actually does, and how it connects to the platform.

A bit later, the assistant let me know the draft was ready. I opened Ghost Admin, reviewed everything myself, adjusted a few parts, and then published it.

That part matters to me. The assistant helps me get from idea to draft much faster, but the final review and publishing decision still stay on my side.

How the setup works

At a high level, the workflow is simple:

• I created a dedicated account for the assistant
• I invited that account into my Ghost publication as a contributor
• I connected the assistant to Telegram through the Telegram Bot API
• I use Telegram to send rough prompts in plain language
• The assistant turns those prompts into structured draft content

In practice, this means I can send a quick message with an idea, an angle, or even a messy paragraph, and the assistant can help shape it into something closer to a blog post draft.

In practice, Ghost is where the drafts end up, but Telegram is where the workflow actually feels alive. That is where I throw quick ideas, half-baked titles, or even messy notes, and let the assistant help me shape them before I look at them properly in Ghost.

The interesting part, at least for me, is that it is not just generating text. It is also interacting with the platform in a way that feels much closer to how a person would actually use it.

Why the assistant has its own Ghost account

One important detail is that the assistant does not share my main admin identity.

It has its own account, permissions, and place in the workflow. That separation makes the system cleaner and easier to control. It also helps define boundaries: the assistant is a tool in the publishing process, not a replacement for the person behind the blog.

This is a small detail, but it matters. Good workflows are usually clearer when roles and permissions are explicit.

Why I wanted the assistant to behave like a real contributor

A technical question naturally comes up here: why not just use the Ghost Admin API directly?

That would have been a valid option. Ghost already provides an admin API and an integration model for creating and managing content programmatically. But for this experiment, I wanted to explore something slightly different.

I wanted the assistant to behave more like a real contributor working at a computer than like a backend integration with direct publishing access.

In practice, that means it tries to go through the same kinds of steps a person would: opening the platform, logging in, dealing with authentication flows, handling email verification codes, clicking redirect links, and working through the same interface a human would use.

One of the reasons I built it this way was to understand how far this kind of assistant could actually go. This was one of my first real automations with it, and I wanted to measure what the bot was really capable of doing in a realistic environment.

And honestly, the result was surprising. At least in this case, the process worked well enough to get me from a rough prompt to a publishable draft.

That said, I will probably end up using the Ghost API for this kind of task in the future. It is likely to be cleaner and more efficient. But building it this way first helped me understand the real capabilities of the assistant, and that was already extremely valuable.

What the assistant can and cannot do

The assistant is useful because it can help with more than just text generation.

It can keep context between tasks, help organize ideas, support drafting, and assist with research. In my case, it works more like a persistent writing agent than a simple chatbot in a browser tab.

Still, there are clear limits.

It does not replace editorial judgment. It does not decide what deserves to be published. It does not make the blog personal on its own. The final voice, direction, and standards still need to come from the human side.

That is exactly how I want it.

Why Telegram fits this workflow

Telegram is not the only interface I could have used, but it is one of the most practical.

It is fast, familiar, and available everywhere. I do not need to open a complex writing environment just to capture an idea. I can send a message naturally, almost like leaving a note for myself, and let the assistant help turn it into something more structured.

That makes the process feel lighter and more natural, especially for early-stage ideas.

Why this is useful for blogging

What I like most about this setup is that it lowers friction without making the process feel artificial.

The blog still stays personal. The writing still needs intent. The editing still matters. But the path from idea to draft becomes much more practical.

Instead of forcing every thought into a full writing session, I can start with a simple conversation and build from there.

For small independent blogs, that kind of workflow matters a lot. The hardest part is often not publishing. It is starting.

Limits and risks

This is still an early experiment, and it comes with trade-offs.

Any workflow that involves automation, tools, permissions, and content creation needs boundaries. If you build something like this, it is worth thinking carefully about access, review steps, and what the assistant should be allowed to do.

For me, the important principle is simple: the assistant should reduce friction, not remove responsibility.

What I started noticing very early

Since this was one of the first real automations I built with the assistant, I quickly started noticing a few problems.

The first one was token consumption. In my case, the bot connects to language models through the OpenAI API, and the initial setup was simply too expensive for this type of workflow. I started with a more capable model, but I soon had to do some tuning to control costs and switch some tasks to cheaper models that are still good enough for a large part of the work.

The second issue is session context. Because my bot runs on a personal machine with OpenClaw, the session context can grow very quickly, and that means a lot of extra input tokens being carried around all the time.

The third issue is efficiency. It works, but I do not think it is the most efficient way to solve this in the long run. For this specific type of task, using the Ghost API will likely make more sense later. Ghost already supports programmatic content management, so the challenge here is less about possibility and more about choosing the right trade-off between experimentation and efficiency.

In the end, a lot of this comes down to minimizing token usage as much as possible. That is one of the main optimization problems I am already thinking about, and I will probably write a separate article about the changes I made to reduce model costs.

Final thoughts

This setup is not about replacing writing with AI.

It is about making the writing workflow more practical.

Ghost gives me a clean publishing platform. Telegram gives me a lightweight interface. The assistant connects the two and helps me move from rough ideas to real drafts with less effort and less context switching.

That is the part I find most interesting.

The blog remains personal, but the workflow becomes much more usable.

What makes this interesting to me is that this was not just a writing shortcut. It was also a way to test what this kind of assistant can actually do in practice.

It also gave me a better sense of how human-like the assistant can be when it is placed inside a real workflow. That part surprised me more than I expected, and it also made me realize how many opportunities tools like OpenClaw can open up. I have only scratched the surface here, so that will probably be a topic for another post.

Even if I later move part of this workflow to the Ghost API for efficiency reasons, this first version already proved something important: the process worked, and it worked well enough to produce a real post that I could review and publish.

If this kind of experiment interests you, subscribe for free and follow along as I keep building and refining these workflows.