AI automation & operations. I take a business task, build the automation around it, and stay responsible for the result.
Ten years in digital business — performance marketing, affiliate, B2B partnerships, budgets, a team of three developers. The last two years: building and running LLM-based automation on my own machine.
I am not a model researcher, and I do not claim to be one. What I bring is the operator's side of AI: pick the tool that fits, wire it into the business process, ship it, and count what it costs and what it saves.
A personal AI operations system. One laptop, no cloud beyond model calls: planning separated from execution as a design, speech in and out, memory in Markdown, and a runner that sends the same task to several models and records quality, latency and cost per run. The separation is the design, not the current state — today one fast model fills both roles, and saying so is cheaper than being asked about it.
I would rather show its real state than a polished claim, because the state is the interesting part. Working today: the executor, speech synthesis, live voice conversation, Telegram as a channel, and the model-comparison runner — that one produced a written report on its first run. Not working yet: the orchestrator is several contours that have never been joined into one path, notes still get lost between chats, and the dashboard has been down for a while.
Building it taught me the thing I now apply everywhere: cheap models for drafts, paid models for decisions.
The code is private while I clean it up — I am preparing a sanitised version of the architecture for publication, and I am happy to walk through it live.
Four that run, and a note about the rest.
| Repository | What it is | Stack |
|---|---|---|
| talentflow-agent | Recruiting automation: parses Djinni vacancies, de-duplicates them, scores the fit, drafts a reply and sends a Telegram digest. The test suite is in the repository | Python, FastAPI, SQLAlchemy, PostgreSQL |
| bookas | Product image synchronisation for a WooCommerce bookstore, written for a shop that uses it — matches and pushes images by ISBN | Python, WooCommerce API |
| ai-lab | Self-hosted stacks for agents, RAG and automation — Flowise, n8n, Open WebUI, Qdrant and a combined stack, each in Docker | Docker Compose |
| devops-optimizer | One script that measures a Git working tree and reports what could be reclaimed | Python, MIT |
What I left out, and why. The profile has other repositories that are
scaffolding rather than software: binance-delisting-monitor is an entry point
that logs "ready for implementation" and loops, market-research-map is a
generated component library around one unfinished screen. Listing them here
would make this table longer and less true. They are where they are; they are
not what I would show you first.
A note on the first row, because it is the honest version. I built the
documentation for talentflow-agent before the code existed, which is a mistake
I would rather write down than hide: the repository spent months describing a
product that did not run. It runs now, with the test suite in the repository.
Python (read and fixed with AI coding agents — not written from scratch by hand) ·
Docker (running stacks, not orchestrating clusters) · SQLite · REST APIs and webhooks · MCP servers · Telegram bots · Flowise / Dify / n8n · Git ·
SQL · Google Ads / Meta / Yandex · GA4, cohort and funnel analytics
- Evidence over adjectives. A claim without a file, a log or a number behind it does not belong in a README.
- A demo that runs beats a feature list that does not.
- Write down what broke. The failure is usually the useful part.
- Written task intake. English in writing is stronger for me than English on a call, and it leaves a trail both sides can check.
Available for automation work and consulting — AI integration, workflow automation, or rescuing something that stopped working. Reach me on LinkedIn.