Six months ago we started building Kino — a tool that manages social media for solo creators. The pitch was simple: give us your niche, your brand voice, and your existing content, and we'll run your social media presence autonomously.

What followed was three months of architectural pivots, two complete rewrites of the generation pipeline, and one very important lesson about why "autonomous" and "fully automated" aren't the same thing. This is the technical story of what we built, what broke, and why Model Context Protocol (MCP) changed our thinking.

The Problem Worth Solving

The average solo creator spends 15–20 hours per week on social media administration: writing captions, reformatting content per platform, scheduling posts, tracking what performed, and trying to stay consistent across 3–5 channels simultaneously. That's half a work week on distribution overhead, not on the content itself.

Existing tools solve pieces of this — Buffer and Later handle scheduling, Predis.ai handles generation — but nothing handles the full loop. You still need to manually connect the pieces. Kino's goal was to close that loop.

V1: The Naïve Approach

Our first version was embarrassingly simple. When a creator onboarded:

  1. We stored their niche, brand description, and social handles
  2. A cron job ran weekly and called OpenAI with a prompt like: "Generate 12 social media posts for a [niche] creator with [brand description]. Include posts for Twitter, Instagram, TikTok, and LinkedIn."
  3. We stored the result as a blob and displayed it in a table

This produced passable content. It also revealed three immediate problems:

Problem 1: Generic at scale. The prompts had no memory. Each generation was stateless — it didn't know what we'd posted before, which topics had performed, or what the creator's current angle was. Week 3 posts looked identical to Week 1 posts.

Problem 2: Delivery was out of scope. We could generate content, but actually posting to Twitter, Instagram, or TikTok required OAuth tokens, rate-limited APIs, and platform-specific formatting rules. V1 punted — creators copied and pasted manually. This defeated half the value proposition.

Problem 3: Platform formatting was an afterthought. Twitter enforces 280 characters strictly. Instagram captions live or die on their hook (the first two lines before "more"). TikTok rewards trend-aware language. LinkedIn's algorithm penalizes external links in the post body. Treating these as "all social posts" produced mediocre output everywhere.

V1 shipped. Users used it once and churned.

V2: Platform-Native Content Generation

The second architecture treated each platform as a distinct target with its own constraints and idioms.

The Content Calendar Data Model

Instead of generating a blob of posts, V2 generates structured records per platform per week:

CREATE TABLE content_calendar (
  id SERIAL PRIMARY KEY,
  page_id INTEGER REFERENCES pages(id) ON DELETE CASCADE,
  platform VARCHAR(20) NOT NULL,     -- 'twitter' | 'instagram' | 'tiktok' | 'linkedin'
  week_start DATE NOT NULL,
  content TEXT NOT NULL,
  content_type VARCHAR(50),          -- 'post' | 'story' | 'reel_script' | 'thread'
  hashtags TEXT[],
  status VARCHAR(20) DEFAULT 'draft', -- 'draft' | 'approved' | 'posted'
  posted_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

Three records per platform per week = 12 posts/week total. Each has its own generation prompt tuned to that platform's conventions.

Platform-Specific Prompt Engineering

The Twitter prompt enforces hard constraints:

Generate 3 tweets for a creator in the [niche] space.
Rules:
- Maximum 240 characters each (leave buffer for links)
- No hashtags in the tweet body (they tank engagement)
- Strong hook in the first 8 words
- One tweet must be a question (drives replies)
- One must share a specific insight or data point
Return JSON array: [{text: string, content_type: "post"}]

The Instagram prompt is completely different:

Generate 3 Instagram captions for a [niche] creator.
Rules:
- First line must be a hook (30 chars max, no period, creates "read more" cliff)
- Caption body 150-300 words (Instagram algorithm rewards engagement time)
- End with a soft CTA question (drives comments)
- Hashtag block SEPARATE from caption: 20-25 hashtags, mix of niche (#[niche]photography) and broad (#ContentCreator)
- Line breaks between paragraphs (Instagram doesn't render markdown)
Return JSON array: [{text: string, hashtags: string[], content_type: "post"}]

The difference in output quality was substantial. Platform-native prompts produced content that actually fit the medium instead of generic social copy dropped into each platform's character limit.

The A/B Testing Layer

Content generation is only valuable if you can measure what works. V2 added A/B testing for creator landing pages — the profile-and-links pages that Kino creates for each creator.

The key design decision: test at the element level, not the page level.

CREATE TABLE ab_tests (
  id SERIAL PRIMARY KEY,
  page_id INTEGER REFERENCES pages(id) ON DELETE CASCADE,
  element VARCHAR(100) NOT NULL,   -- 'headline' | 'tagline' | 'cta_text'
  variant_a TEXT NOT NULL,
  variant_b TEXT NOT NULL,
  status VARCHAR(20) DEFAULT 'running',
  views_threshold INTEGER DEFAULT 100,  -- declare winner after N views per variant
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE ab_test_events (
  id SERIAL PRIMARY KEY,
  test_id INTEGER REFERENCES ab_tests(id) ON DELETE CASCADE,
  variant CHAR(1) NOT NULL,        -- 'A' | 'B'
  event_type VARCHAR(50) NOT NULL, -- 'view' | 'click'
  visitor_id VARCHAR(64),          -- hashed, not stored as PII
  created_at TIMESTAMPTZ DEFAULT NOW()
);

We record every view and click event individually rather than incrementing counters. This lets us calculate statistical significance, replay results for debugging, and detect anomalies (e.g., a visitor who triggers 50 views in 10 seconds is a bot — filter on replay, not on write).

At 100 views per variant, the system auto-declares a winner based on click-through rate and promotes the winning variant. The creator gets notified and can override — but in practice, they almost never do, because the data is unambiguous.

Why MCP Changes Agent Architecture

The hardest part of building an autonomous agent isn't the AI — it's the tooling.

In V1, every external capability required bespoke integration: write the OAuth flow for Twitter, write the API wrapper for Instagram, write the custom logic to pass context from one tool to the next. Each integration was hand-wired, fragile, and untestable in isolation.

Model Context Protocol (MCP) introduces a standardized interface: tools expose themselves as MCP servers, and any MCP-compatible agent can call them using a consistent protocol. The agent doesn't need to know whether it's calling a Gmail tool, a Twitter API wrapper, or a custom database function — the protocol is the same.

For Kino, this changes two things:

Tool composition becomes reliable. When the content generation agent needs to read a creator's recent post history, it calls the post-history MCP tool. When it needs to post a draft, it calls the publish MCP tool. The agent doesn't need to understand the OAuth implementation or the rate-limiting logic — that's encapsulated in the tool. We can test tools in isolation, swap implementations without touching the agent, and add new capabilities (email, analytics, competitor research) as new MCP tools without modifying the agent loop.

Context passing becomes explicit. In bespoke integrations, context leaks or gets lost between steps. MCP forces you to declare what context flows between tools — which also makes the agent's behavior auditable. You can inspect the tool call trace and understand exactly why the agent made each decision.

We're not fully MCP-native yet — Kino's current architecture uses direct API calls in several places — but new integrations are all being built as MCP servers. The migration pays back quickly in debuggability alone.

The Human Approval Loop: Why Autonomous Isn't Fully Automatic

Here's the thing nobody tells you about autonomous agents: full automation of creative work fails in production.

Our first fully-automated posting pipeline (V1.5, between the two major versions) posted directly without human review. The results were educational:

The agent has no awareness of the external world unless you give it one. Even with real-time web search, the agent doesn't understand brand risk, community sentiment, or the creator's personal context ("I'm on vacation this week, don't post tech content").

The current Kino architecture positions the human approval loop as a feature, not a limitation:

  1. Agent generates 12 posts/week, formatted per platform
  2. Creator reviews in the content calendar (edit, approve, or delete)
  3. Approved posts queue for delivery at optimal times
  4. Agent learns from what the creator edits vs. approves (future versions)

Creators who see the queue have a completely different relationship with social media. Instead of the anxiety of needing to post something today, they spend 15 minutes on Monday reviewing what the agent drafted and approving the posts they like. The agent absorbs the daily pressure; the human retains creative control.

This is the right model for AI-assisted creative work: reduce friction, don't remove judgment.

Data Modeling Lessons: Events Over Snapshots

One architectural pattern we got right early: model lifecycle events as event records, not overwritable columns.

The naive approach for tracking when a creator last posted:

-- Bad: single column, overwrites on every post
ALTER TABLE pages ADD COLUMN last_posted_at TIMESTAMPTZ;

When did they post before that? Gone. How many times have they posted this month? Unknown. What's their posting cadence? Can't calculate.

Instead:

-- Good: immutable event records
CREATE TABLE content_events (
  id SERIAL PRIMARY KEY,
  page_id INTEGER REFERENCES pages(id),
  event_type VARCHAR(50) NOT NULL,   -- 'post_approved' | 'post_delivered' | 'post_failed'
  platform VARCHAR(20),
  metadata JSONB,
  occurred_at TIMESTAMPTZ DEFAULT NOW()
);

Now we can answer any historical question: posting frequency by week, delivery success rate by platform, correlation between approval rate and subscriber growth. The data is there — we just haven't built all the queries yet, but we don't need to decide upfront what to measure. Everything is recorded; we query what we need when we need it.

Storage is cheap. Lost history is permanent.

The Creator Page as Distribution Infrastructure

Every Kino creator gets a profile page at kino-7apg.polsia.app/username. This isn't just a nice-to-have — it's distribution infrastructure.

When the agent posts on social media, every post links back to the creator's Kino page. The page is the conversion surface: bio, links, tip jar, paid content. It has OG meta tags for social sharing, JSON-LD structured data for SEO, and canonical URLs so search engines don't split authority across platforms.

The insight: social platforms are rented land. An Instagram bio link or a Twitter profile link leads somewhere you don't own. The Kino page is owned. Traffic from the agent's posts builds search equity on a domain the creator controls, not Meta's.

What's Next

Three things on the roadmap:

Delivery integrations. Right now, Kino creates content and displays it for copy-paste. The agent posts the draft; the human delivers it. Next step: OAuth connections to each platform so approved posts publish automatically on schedule. MCP tools per platform, clean separation between generation and delivery.

Performance feedback loop. The agent generates based on the creator's brand description and niche. It doesn't yet learn from what performs. Once delivery is live, we can close the loop: which posts drove clicks to the creator's page, which drove conversions, which topics got engagement on each platform. The generation prompts improve automatically.

Cross-platform content strategy. Right now we generate platform-specific content independently. The next step is coherent strategy: a theme per week, different angles per platform, repurposing long-form content into micro-content. This requires the agent to plan before it generates — a more complex reasoning loop, but much higher value output.

Closing Thoughts

Building an autonomous social media agent taught us that the technical challenge is less interesting than the design challenge. The AI part is mostly solved — GPT-4 generates credible content. The hard part is the interface between the agent and the real world: what the agent knows, what it doesn't know, when it should act autonomously, and when it should stop and ask.

The MCP ecosystem is making the "what the agent knows" problem tractable. Standardized tool interfaces mean you can give agents real-world capabilities without hand-wiring fragile integrations. The field is moving fast.

If you're building something in this space and want to compare notes — or if you're a solo creator drowning in social media admin — start here. Kino is free to try.