AI agents
Custom AI agents for your business.
Built around your needs, not around a platform: agents and automations that fit your process, run on your infrastructure and belong to you.
We advise mid-sized companies and online retailers on AI agents, then build and run them. People stay in charge, the model is an interchangeable tool, and you keep the system.
Why bespoke
We start with the job, not the tool.
Before n8n, we built agents on SmythOS for a client project; we've since dropped it. We know n8n well and still use it where it fits: the chatbot in a business application we built for a pharmaceutical logistics company runs on it to this day.
Today we pick whatever the job needs:
- The model providers' own SDKs and agent tooling: subagents that each run in their own context, hand-offs between agents, and guardrails that validate inputs and outputs.
- The Model Context Protocol (MCP), an open-source standard for connecting AI applications to external systems. Since December 2025 it has been hosted by the Agentic AI Foundation, part of the Linux Foundation.
- n8n, where a workflow tool is the right answer. You can host it yourself, combine several models in one flow and require human approval before an agent runs a tool.
We've found that our pipelines work better without n8n: we couldn't set up separate agents with their own skills and a targeted choice of model for each task the way we needed to. That reflects our own projects; it's not a verdict on the wider market. In August 2026 we moved document classification and summarisation in that pharmaceutical logistics application off n8n webhooks and onto direct calls through a model provider's PHP SDK.
You can also host models locally or use cloud agents. Which route is right depends on the task.
How we build agents
Separate roles, the right model, a person with the final say.
One large model provider defines an agent as a system that plans its own steps and calls tools to complete a task, and warns that this autonomy brings higher costs and the risk of compounding errors. So we build checks in from the start rather than bolting them on later.
Separate roles, independent checks
In one research pipeline, for example, the agent that writes never checks its own work. The checker has neither written the text nor gathered the sources, and it runs on a different model with a fresh context. Engineering guidance from one of the large model providers points the same way: a separate model instance tends to make a better guardrail.
The right model for each task
We match the model to the task. In one project, for example, a small model handles simple tasks, a mid-sized one long prompts and the largest the demanding reasoning. The choice is set per endpoint and can be switched at runtime. When a better model arrives, it takes over.
Clear interfaces, human approval
Agents work with an application through defined interfaces, such as a REST API or MCP tools. The MCP specification says hosts must obtain explicit consent before invoking a tool, but admits the protocol cannot enforce it. So approval belongs in the application, and the final decision rests with a person.
What we build
Agents that do one job properly and leave a trail.
Six kinds of work we build agents and automations for. You'll find worked examples in our case studies.
-
01
Research and checking pipelines
One pipeline we built shows the pattern: research, writing and checking run as separate agents. A statement only counts as a fact once a script, not a model, has found the supporting quote in the retrieved source text. A model's claim to have found it is just one more opinion.
-
02
Email agents that guard confidentiality
In one client's business application, an email agent turns incoming mail into tasks and knowledge-base entries, which inherit the email's confidentiality level. It raises that level itself when it finds access credentials, contracts or personal data, but never lowers it. It can't delete anything, and everything it writes is logged.
-
03
Agents in your business applications
We give your application an interface built for agents. In one project, for example, that is a stateless REST API behind bearer tokens, with compact output formats designed for an agent's context and an endpoint that issues the next free reference number, so agents never guess a number or use one twice. An MCP server on top lets agents work through that API.
-
04
Reports with figures straight from your data
In one reporting project, the model writes the summary, assessment and recommendations as structured output against a JSON schema. The figures come from the data and a template renders them, never the model.
-
05
Content from product data
Copy built from your product data rather than from a blank prompt. Our SEO and content page explains how this ties in with search visibility.
-
06
ERP, shop and other systems in sync
Data kept consistent between your ERP, online shop and the systems around them. We build this for a pharmaceutical logistics company and for one of our own shops. The shop side of that work is covered on our online shops page.
We've been working with total10 for many years, and it's always been fast and effective. t10 looks after and builds everything our various shops need. Lately, AI has been coming up more and more. What total10 makes possible there goes far beyond anything we'd imagined ourselves. Anyone on board now is years ahead of the competition. Anyone who isn't will be left behind.
From idea to running agent
-
Step 1
Use case and business case
- the process
- the data
- the payback
-
Step 2
Design
- roles
- model per task
- interfaces
-
Step 3
Build
- API and MCP tools
- structured output
- logging
-
Step 4
Testing and approval
- test runs
- independent checks
- approval
-
Step 5
Operation
- tool trace
- model updates
- ongoing development
Beyond the workflow tool
Some agents need an application of their own.
When an agent writes to your data, its tools belong inside the application, not in a workflow tool sitting next to it. We build these tools into the application itself, as part of our Symfony development work.
The agent inside the application
Take the email agent in an application we built for a pharmaceutical logistics company: now that we've moved it off n8n, it runs in the same PHP process as the application, with its tools working directly on the data layer instead of going through a bot API. Tool errors now reach the model rather than being swallowed.
A record of what really happened
In the same application, every reply from the agent comes with a list, logged by the system, of the actions it actually took, so if the model claims something worked when it didn't, you see it straight away. For each email, the complete tool trace, iterations and token usage are logged.
Our work
AI and automation in practice.
-
Case study · E-commerce
The self-driving content machine
An established mid-market online shop with several thousand specialist products that need real explanation, multiple country shops and a large trade magazine faced a scaling problem: high-quality, search-strong content, complete with imagery, internal linking and multiple languages, can't be produced by hand at the volume required. We built a fully automated content machine for it that generates, illustrates, translates and even voices articles, running autonomously round the clock.
Read the case study
When we advise against AI
Sometimes the honest answer is no agent at all.
If a rule gives the same answer every time, it doesn't need a model.
- Tasks with fixed logic and a predictable output
- High-stakes financial, strategic or legal decisions left to an agent alone
- Automations that would not pay for themselves
This caution is not peculiar to us. The workflow platform Make, which offers agents of its own, advises giving agents only tasks you would trust an intern with, and keeping them away from sensitive data, high-stakes financial or strategic decisions, and anything subject to strict legal requirements. For logic that always produces the same output, it recommends a standard Make scenario without an agent.
A major model provider's engineering guidance says much the same: find the simplest solution and add complexity only when it is needed, which may mean building no agentic system at all. We work to that rule, and we'll tell you when a plain automation, a script or no change at all would serve you better.
Frequently asked questions
What people ask before starting an agent project.
- Where does our data live?
- On your infrastructure, together with the system and workflows, all of which belong to you. The models we use are hosted externally, so for every workflow we tell you exactly what each model gets to see. We have no models of our own and haven't trained any.
- Do you work with n8n or build bespoke systems?
- Both; it depends on what you need. n8n can be self-hosted and suits simpler flows; a business application we built still runs a chatbot on it. Where you need separate agents, each with its own skills, and a deliberate choice of model per task, we build a bespoke system, because in our experience n8n couldn't give us that.
- Which models do you use?
- Whichever suits the task. One project splits it like this: simple jobs go to a small model, long prompts to a mid-sized one and demanding reasoning to the largest. The model is a tool, not a fixture: we replace it as soon as a better one is available.
- How do we avoid lock-in?
- The code and workflows are yours, and they run on your infrastructure alongside your data. Agents connect through defined interfaces such as REST APIs and MCP, an open-source standard now under the Linux Foundation's Agentic AI Foundation. The model behind the agents can be swapped.
- What does an agent cost?
- That depends on the process, so there's no fixed price. We start with a use-case analysis, and you then get a cost estimate that sets out its assumptions. If the numbers don't add up, we'll say so.
- What if an agent gets it wrong?
- We assume it will, sooner or later, and build for that. Depending on the project, a person starts the run or approves the output, and where the output is text that goes out, a second agent on a different model checks it. In one client's application, for example, everything the agent writes is logged and the system records what it actually did, so a claimed success that never happened shows up. When a tool fails there, the model is told rather than left in the dark.
- Can this run locally?
- Yes. Open-source software will run language models on your own machines, and cloud agents are an option too. Which of the two suits you depends on the use case.
A process worth automating?
Tell us which process you have in mind and we'll give you an honest view of whether an agent makes sense and, if so, what it would take. We'll get back to you promptly.