We connect models to your data, tools and operating rules. AI helps where it has a defined job, while people keep control of decisions that carry cost or risk.
I originally built PolyTrans to solve a concrete publishing problem: translating a large, multilingual WordPress publication without paying a SaaS fee for every word and without giving up ownership of the translated content. It started as a plugin that could send a post to an AI provider. Production use pushed it much further—towards scheduling, editorial review, post-processing chains and communication between separate WordPress sites.
PolyTrans sits beside the marketing MCP work. Its purpose is multilingual publishing: moving editorial content through translation and post-processing flows while keeping it in the WordPress environments where the teams already work.
The work around trans.info, trans.eu, TFC and TFF did not start from one identical template. PolyTrans has been adapted where a property needed a translation, hand-off or content-processing capability.
Models can translate or process content, but scheduling, review, status and publication stay visible in the editorial workflow. The output and translation relationships remain in WordPress rather than an external translation SaaS.
A source post is selected. PolyTrans reads the content, metadata, language relationships and the translation route configured for that publication.
The model performs a defined job. Translation can go to OpenAI, Claude or Gemini. A later step can use another model or prompt for tone, terminology, SEO fields or structural cleanup.
The result returns to the editorial system. The translated post, taxonomies and metadata are created where editors already work, with status and review information attached.
The integration is chosen for the property. PolyTrans can work in a single WordPress installation or distribute sender, translator and receiver roles between installations when that is what a publishing setup needs.
Once I began using coding agents for daily work, the limitation was obvious: a capable model still cannot help much if every important fact is trapped in another tab and every action requires a different UI. I use MCP servers to expose live systems and local knowledge, then hooks to add rules around the agent lifecycle.
I split a full marketing review loop into local servers for account diagnosis, durable client memory, safe campaign changes, analytics and reporting. Each remains useful alone; together they let one agent follow the work from finding to deliverable.
Explore the stackI built a universal lifecycle-hook framework after repeatedly needing to inject the same reminders, safety checks and context at specific moments in an agent session. It now includes reusable recipes and works across Claude Code and Codex.
GitHubI maintain a self-hosted fork of a visual coding system that turns screenshots into editable interfaces with multimodal models. It was also my practical entry point into running model-heavy applications on my own infrastructure.
Case studyI made Kompakt because Claude Code compaction kept flattening long Polish conversations into generic English summaries. The plugin lets me control the summarization prompt, preserve user messages and choose how much technical detail survives.
Project detailsI keep a human at the expensive boundary. My campaign tools prepare and preview changes first. They execute only after a separate, explicit confirmation.
I keep knowledge outside the conversation. Client facts, past decisions and working procedures belong in inspectable files that survive a single chat session.
I prefer portable interfaces. Local files and standard protocols let me use the same building blocks from Claude Code, Codex and Cursor.
