InkyPyrus: an AI studio on the platform

A platform is only as credible as the work it ships. The self-hosted AI estate I run is not a
lab exhibit — it produces real business output, on a schedule, for a real client. The proof is InkyPyrus,
an autonomous publishing studio that runs entirely on the platform. InkyPyrus is the studio; I’m the
engineer who built the backend that makes it possible. This article is about that backend.

The interesting claim isn’t “I used some AI to make content.” Anyone can do that with a browser tab.
The claim is that an org-chart of cooperating agents — a directing agent in the cloud, executing agents
on my own GPUs — takes a one-line campaign brief and produces finished, branded deliverables end to end,
with cost that trends to a power bill rather than a per-token meter. That is a different thing, and the
difficulty is in the seams, not the models.

An org chart of agents

The architecture borrows from how a small studio actually works: someone sets direction, someone
executes, and there’s a coordination layer keeping them in sync.

  CEO agent (cloud Grok)        ── sets strategy, campaign intent
        │
        ▼  agent control plane  ── tasks, retries, state, idempotency
        │
  CTO-style agents (local 27B)  ── plan + execute the build
        │
        ▼
  "The Press" content engine    ── reels · carousels · PDFs · voiceover
        │
        ▼
  client pipeline + CRM         ── brief → generate → approve → schedule → publish

The CEO agent runs on cloud Grok and handles strategy — interpreting a brief,
deciding what a campaign should contain, sequencing the work. The CTO-style agents are
the self-hosted Qwen-class 27B model on my own GPU; they take the CEO’s intent and turn it into concrete
build steps, then execute them. An agent control plane sits between them, owning the
unglamorous but decisive parts: task state, retries, structured handoffs, and idempotency so a retried
step doesn’t double-publish.

“The Press” — the content engine

The Press is where a brief becomes artifacts. From a single campaign brief it generates programmatic
video reels rendered with Remotion on the GPU, social carousels, branded PDFs, and TTS voiceovers — the
full set of deliverables a content campaign actually needs, assembled without a human touching a design
tool for each one. “Programmatic” is the operative word: a reel is code that renders deterministically,
so the same brief produces the same branded output every time, and changing the brand means changing a
template, not re-cutting fifty videos by hand.

Where agents shine, and where a human gate is mandatory

The honest version of “autonomous studio” includes the word mostly. Autonomous agents are
genuinely excellent at the high-volume, structured, tedious middle of the pipeline: expanding a brief
into a shot list, drafting variations, rendering, formatting, scheduling. That’s where local inference
earns its keep — you can run those loops as long as you like because the marginal cost is electricity.

But there is a hard line at approval and brand voice. A regenerative
agriculture knowledge business — the pilot client — has a voice and a set of claims it can and cannot
make, and getting that wrong isn’t a typo, it’s a credibility hit for someone else’s brand. So the
pipeline has a mandatory human gate: nothing publishes without an explicit approval step. The agents
propose; a person disposes.

The senior decision in an autonomous system is not how much you can automate — it’s where you refuse
to. An approval gate isn’t a failure of automation; it’s the feature that makes the automation safe to
point at a real client’s audience.

Reliability is the actual work

Demos of agent pipelines are easy. Production pipelines fail constantly in small ways — a model
returns malformed JSON, a render times out, a network blip drops a task — and the difference between a
toy and a studio is how those failures are handled. Three disciplines carry most of the weight:

• Structured output: agents emit validated JSON against a schema, not free text that
  the next stage has to guess at. A malformed response is rejected and retried, not half-parsed into a
  broken downstream step.
• Idempotency: every pipeline step is safe to run twice. A retried “publish” checks
  whether the artifact already shipped before shipping again, keyed on a stable campaign+asset ID.
• Bounded retries: transient failures retry with backoff; persistent ones fail loudly
  to the control plane rather than silently dropping the deliverable.

# control plane: a pipeline step is idempotent and schema-validated
async def run_step(step: Step, ctx: CampaignContext):
    if await ctx.already_done(step.id):        # idempotent: retry is a no-op
        return ctx.result_for(step.id)

    raw = await agent.generate(step.prompt)
    payload = Asset.model_validate_json(raw)   # reject malformed model output
    result = await execute(payload, ctx)

    await ctx.mark_done(step.id, result)        # commit before returning
    return result

Keeping inference local is also a cost-control decision, not just a privacy one. A content studio that
ran on a hosted frontier model per asset would have a marginal cost that scales with output — exactly the
wrong shape for a business whose product is volume. Running the heavy generation on owned GPUs
flips that: the expensive part is fixed, the variable part is electricity, and the CEO agent — the one
hosted call in the loop — only ever handles cheap, low-token strategic direction.

Live / proof

This isn’t a prototype. The studio runs a real client pipeline and serves a real pilot client today:

• www.inkypyrus.com — the live studio this platform produces work for

The studio is the front door. The backend — the agents, the control plane, the render farm, the
estate it all runs on — is the engineering I build at RealAndWorks.