I am less interested in building another chat window than in giving a model a useful place inside an existing process. My projects connect AI to publishing, marketing and software development, where the model can see the right context, use actual tools and stop before an expensive decision needs a human.
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.