AI automation engineer. I assemble working loops rather than isolated scripts: agents, scenarios, integrations and investigation tools that run every day without me. Below is what I can do; every item points to an entry where it is visible in detail rather than merely claimed.
Agents that work with a project’s real context rather than merely conversing nicely. A platform map, per-project memory, a runbook for common problems. The model’s answer is the last point of a long chain, and it is the whole chain that has to hold.
where this is visible: I put support into a folder · How I accidentally became an AI automation engineer
Not "two buttons and thank you", but a graph: nodes, conditions, variables, state between messages, external requests, fallbacks. Python, FastAPI, aiogram, Redis, webhooks. A standalone service behind a reverse proxy, not a script thrown together.
where this is visible: Built the bot in October. Delivered it in July · I built a bot for Phuket. Then people came in
Projects in healthcare, logistics, fitness, retail, telecom and education: text and voice bots already running on real traffic. Triaging requests, editing scenarios, shipping changes without stopping conversations. What needs fixing is what cannot be switched off.
where this is visible: I put support into a folder · Five production projects
Bots that report a failure before the client notices it: checks on delivery, queues and handovers to a human operator. A separate piece of work is trust in the alert itself: one that lies about a problem that is not there is worse than silence.
where this is visible: I put support into a folder
A recurring report from 40–60 minutes down to 2–3 with no human involved, roughly 38 analyst hours a month given back. One approach spread across five production projects with no extra headcount and a single shared method of calculation.
where this is visible: Five production projects
Tracing data from the user to the final action and finding the point where two parts of a system stopped agreeing. Config and analytics first; logs once it is clear the scenario worked correctly. The nastiest bugs live between systems, not inside them.
where this is visible: I put support into a folder · Built the bot in October. Delivered it in July
Partners keep their data where it suits them, while a separate process picks up the changes and puts them into PostgreSQL, which then serves search and filtering. A database appears when real usage has broken the previous solution, not for the look of it.
where this is visible: I built a bot for Phuket. Then people came in
Masking as part of the process rather than a reminder to "not forget": before a file is read, a hook fires and swaps it for a masked copy. Investigation is separated from external actions — replying to a client or changing state requires human confirmation.
where this is visible: I put support into a folder · Five production projects
Combined traffic of the projects I am responsible for. A dialogue starts over after it ends or times out — which is why there are more of them than users.
Then a problem. Then the next layer. Not the other way round. A spreadsheet instead of a database is a perfectly good first solution, until real usage makes it inconvenient.
Do not give the model more intelligence; give it a decent environment: project context, memory of past investigations, a clear route from ticket to cause.
An agent can gather data, find the cause and prepare a change on its own. Publishing to production and replying to a client happen only with explicit confirmation.