Automating your processes with artificial intelligence

LLM agents and automation flows for back-office and recurring processes.

I design flows in n8n, or Claude and GPT agents, that take on the repetitive part: sorting incoming invoices, watching the official notifications inbox and warning you before a filing falls due, drafting a reply. They connect to what you already use, over API or webhooks.

Who it is for

• Businesses with repetitive manual processes
• Sales teams with prospecting workflows
• Operations handling customer enquiries at volume

Why it ends up being needed

The work that automates well is almost never the most complicated: it is the most repeated. Someone opens the mail, downloads a PDF, types six fields into another program, files the document and moves on to the next one. Forty times a day. Nobody calls it a process because it has always been done that way.

The real cost is not those hours, it is what comes with them: on a busy day the queue builds up, whoever does it mistypes a digit and the error surfaces three weeks later, and when that person is off sick nobody else knows how. What you automate is not just time: it is the dependency on one particular person being available.

Automating is not buying a tool with AI in it. It is deciding which part of the process a machine can decide, which part a person has to review, and which data may leave your systems for a model to read. That third question is the one most often skipped, and it is the one that ends in a letter from the data protection authority.

What I deliver

• Documented architecture — Flow diagram, the services involved and their dependencies.
• Agents and flows — Built on self-hosted n8n or on a managed service.
• Versioned prompts — A prompt library with automated tests.
• Observability — Logs, alerts and execution metrics.
• Technical handover — Documentation plus a two-hour session for your team.
• Hours saved, measured — A baseline before automating and a measurement after, process by process.

What is included

• A map of the processes worth automating
• Development and integration with your systems
• Training for your team
• Three months of support

What gets decided before a line is written

• What gets automated first — The first process is not chosen because it is the most annoying, but because it combines two things: it repeats often and it has clear rules. A frequent process full of exceptions is expensive and produces a result nobody trusts. The process map that gets delivered sorts exactly that.
• Language model or rules — Not everything needs a model. Pulling an amount out of an invoice with a fixed layout is a rule, costs cents and does not get it wrong. A model belongs where the text is free-form and has to be interpreted. Mixing both in the same flow is normal, and using a model for what a rule solves is paying for uncertainty.
• What data leaves and what does not — Before anything is connected, it is agreed in writing which fields go to a model and which are replaced or stay inside. A name and a tax number are almost never needed to classify a document. This is settled at the start because settling it later means rebuilding the whole flow.
• Where the flow lives — Self-hosted n8n keeps the data on your own infrastructure and keeps the cost fixed; the managed service is up in a day and saves you the maintenance. The choice depends on what data travels through the flow and on whether anyone can look after a server.
• What happens when it breaks — An automated flow that fails silently is worse than not having one: for two weeks nobody knows the invoices are not being filed. That is why observability — logs, alerts and metrics — is in scope and not a later improvement.

What is not included

• Training a model of your own: the work uses existing models.
• Licences or usage of third-party tools, which are contracted in your name.
• Automating processes on systems with no API and no way to export.
• The human review of what the flow produces, which stays yours.

What you need to have

• Access, or someone who has it, to the systems that will be connected.
• One person who knows the process as it is actually done today, exceptions included.
• A decision on what data may leave the system, agreed in writing before anything is connected.
• Somewhere to host the flows, or the decision to use a managed service.

Frequently asked questions

Do I own the code and the workflows?

Yes. They are handed over open and documented, with a month of support, so you can change them without depending on me.

Will it integrate with what I already use?

It connects to your current systems over API or webhooks. If one of them has no API, I tell you before starting rather than halfway through.

What happens to my clients' data?

The design starts by deciding which data may leave the system and which may not. Whatever is sent to a model is agreed in writing before anything is connected.

How long until the first flow is running?

The prototype is two weeks after the discovery week: one or two flows in production with real data, not a demo. The rest is rolled out afterwards.

What if the process changes in six months?

Flows are handed over open and documented, and prompts are versioned and tested, precisely so a change does not mean starting again. If there is no technical profile in-house, maintenance is contracted separately.

How do I know this actually saves anything?

It is measured before automating and after, process by process. That baseline is part of the deliverables, because without it the only proof that something improved is the feeling that it did.