Case study 03
AI Content Operations Pipeline
I built and operate an AI-assisted content system for X accounts with different audiences and editorial voices. Adding an account is a configuration change, not a new pipeline.
The accounts are not fed by one generic content generator. Each has its own positioning, source rules, tone, publishing limits and approval flow. The shared layer handles repetitive operations: collecting source material, generating structured drafts, preparing optional visuals, scheduling approved content and checking whether publication actually happened.
The system is semi-automated by design. AI prepares and routes work; a human remains responsible for editorial judgment and final approval.
The problem
Managing several accounts manually created a fragmented workflow:
- research lived in different feeds and notes;
- the same topic could be rewritten in the wrong voice;
- drafts were lost between Telegram, spreadsheets and scheduling tools;
- image generation added another separate process;
- approved posts could fail at the scheduling or publishing stage without a visible error;
- reply workflows required a browser session and could consume server resources when left running;
- checking each account every day became its own monitoring task.
The objective was to reduce operational overhead without turning the accounts into automated content farms.
What I built
Each account is defined by a profile rather than by its own codebase: positioning, topic boundaries, tone, factual constraints, source rules and publishing limits. Onboarding another account means writing another profile, so the workflow scales without duplicating the pipeline.
Every account then runs through the same high-level pipeline:
- 1
Source collection
Ingest relevant digests, lists, project updates or a user-provided draft.
- 2
Account routing
Apply the correct topic boundaries, voice and factual constraints.
- 3
Draft generation
Produce several candidate versions or a prebuilt thread.
- 4
Telegram review
Show the draft, length, image status and clear actions.
- 5
Human approval
Approve, edit, regenerate, skip or choose an image.
- 6
Scheduling and publishing
Route single posts and threads through the appropriate publishing service.
- 7
Record synchronization
Save approvals, scheduled status and final X URLs in the account database and Google Sheets.
- 8
Daily operational audit
Check posts, replies and service state across every connected account and report only the actions that need attention.
Guardrails
Human control
The human approval step is the editorial boundary.
The model can suggest a post, rewrite a draft or generate an image concept, but it cannot treat generated text as automatically publishable. The operator sees the final copy before it is scheduled and can edit, regenerate or skip it.
Reply automation follows the same principle. The browser can collect targets and prepare drafts, but automatic sending is disabled for approval-based workflows. This keeps tone, factual risk and account reputation under human control.
Risk controls
The pipeline includes controls for both content quality and operational reliability:
- separate prompts and databases for each account;
- no invented statistics or unsupported project claims;
- source-bound generation for news and research posts;
- visible character-limit checks before scheduling;
- duplicate-publication prevention;
- explicit warnings when a post is approved but not scheduled;
- retry paths after editing failed drafts;
- publication URL reconciliation after the scheduler sends the post;
- account-specific browser profiles for reply workflows;
- on-demand browser runners and resource limits;
- daily checks that distinguish “nothing to publish” from a stopped or disconnected service.
A key rule is that approval and publication are different states. A green approval message is not enough; the system must receive evidence that the scheduler accepted the post and later resolve the final X URL.
Result
The workflow is deployed across multiple accounts while preserving distinct editorial identities.
Routine operations — source intake, draft preparation, scheduling metadata, link synchronization and health checks — are automated. Editorial decisions remain manual.
The system also exposed several quiet failure modes that a simple content generator would miss: drafts truncated before review, approved posts rejected by platform limits, image generation failures, browser sessions running without a usable X tab and scheduled threads that entered an error state without publishing.
These failures were converted into visible statuses, retries and monitoring rules. The practical result is not “more AI content.” It is a controlled publishing process where the operator can see what is drafted, what is approved, what is scheduled and what actually reached X.
My role
I designed the account positioning, editorial boundaries, Telegram UX and approval logic. I connected the generation, scheduling, image, browser and reporting components, then tested the system against real publishing failures.
I also created a daily audit layer so that managing several accounts does not require manually opening every service, spreadsheet and X profile.
Stack
- Python
- AI models and agents
- Telegram Bot API
- Buffer
- Typefully
- Google Sheets
- SQLite
- Browser automation
- Scheduled jobs
- systemd
Proof
Private repository — it holds the publishing credentials and the per-account editorial rules. The accounts themselves are live and posting.
Key lesson
The difficult part of AI content automation is not generating text. It is preserving context, accountability and a reliable path from source to published result.