AI Agents and Automation
One workflow, from input to reviewed output
Not a chatbot bolted to your website. A specific process – the one that eats hours every week – taken end to end, with the integrations, approval points and controls it needs before anyone will trust its output.
- One workflow at a time
- A person approves what leaves the system
- Scope agreed before any invoice
- Who it is for
- Teams with a repetitive, rules-heavy process that a person currently does by hand
- Unit of work
- One workflow at a time, scoped from its input to its reviewed output
- Always included
- A review step. A person approves anything that leaves the system
- Before we build
- Agreed data, formats and acceptance criteria, in writing
What this is for
The work that is too rules-heavy for people and too messy for a script
Automation is worth it where the process is frequent, the rules are real but fuzzy, and a person is currently doing it by hand. Some examples of that shape.
Requests that become quotes
An enquiry arrives as an email, a PDF or a form. Someone reads it, finds the matching items, checks availability and drafts a quote. The rules exist; they are just not written anywhere.
Documents that become records
Invoices, contracts, forms or reports arrive in a dozen layouts. The fields matter, the validation matters, and the routing depends on what is inside.
Enquiries that need triage
A queue where most items need a standard response, some need a specialist, and the cost of misrouting is a lost week or a lost deal.
Reports assembled by hand
The same pull from the same systems, reconciled the same way, every week – by someone whose time is worth considerably more.
Research before a conversation
Gathering context on an account or a supplier from several sources so a person starts the conversation informed rather than cold.
Quality checks nobody has time for
Consistency checks on output that currently happen only when something has already gone wrong.
What you get
A working workflow, and the means to keep it working
The workflow is the obvious deliverable. The rest is what decides whether it is still running in six months without us.
- 01
The workflow itself
Running against your systems, with the integrations it needs.
- 02
Written acceptance criteria
What correct means, agreed before the build and tested against after.
- 03
Review and approval points
Where a person sees the output before it goes anywhere.
- 04
Refusal behaviour
What the system does when it should not answer, instead of guessing.
- 05
Tests and documentation
How it works, how to change it, and how to tell when it has drifted.
- 06
A named owner and handover
Someone on your side who can run and change it without us.
Scope
What one workflow engagement covers
A workflow is the unit. Adding a second is a separate piece of work, priced on what the first one taught us both.
Included
- One workflow from its trigger to its reviewed output
- Integrations with the systems that workflow touches
- Approval points and the handling for cases it should refuse
- Acceptance criteria agreed in writing before the build
- A parallel run against real work before anything is switched on
- Tests, documentation and handover to a named owner
Scoped separately
- Additional workflows beyond the one agreed
- Rebuilding or migrating the systems it connects to
- Ongoing monitoring, incident cover and maintenance
- Data cleanup programmes where the source data will not support the work
- Regulatory, legal or security certification opinions
- Open-ended model experimentation without an agreed acceptance test
Anything on this side is scoped and priced on its own, once the shape of it is clear. Discuss one workflow →
How it runs
Agreed before it is built, demonstrated before it is trusted
The order matters. Most AI work that fails was built before anyone agreed what "correct" meant.
- 01
Pick the workflow
One process, named precisely: what triggers it, what goes in, what comes out, how often it runs, and who is doing it today. If more than one qualifies, we start with whichever is easiest to judge.
- 02
Agree what correct looks like
Acceptance criteria written down before anything is built, against real examples. This is the step that decides whether the project can succeed, and it is the one most often skipped.
- 03
Map the data and the access
Which systems hold the inputs, what access is needed, what can be done with redacted samples, and what has to wait for a decision on your side.
- 04
Build the workflow
The path from input to output, with the integrations it needs, the approval points where a person sees it, and the handling for cases it should refuse rather than guess at.
- 05
Run it beside the current process
In parallel, on real work, with the output compared against what your team would have produced. This is where the acceptance criteria earn their place.
- 06
Hand it over
Documentation, tests, a named owner on your side, and what to do when the system is wrong – because sometimes it will be.
Against the alternatives
Not a chatbot bolted to your website. One process, taken end to end.
The one that eats hours every week, from its input to its reviewed output, with the integrations, approval points and controls it needs before anyone will trust what comes out of it.
| A chatbot product | A generic automation tool | This engagement | |
|---|---|---|---|
| What it covers | Questions typed into a box | The rules you configure | One workflow, from its input to its reviewed output |
| Who checks the output | Nobody, unless you add someone | You, if you build the check | A person approves anything that leaves the system |
| When it should not answer | It answers anyway | The rule does not fire | Agreed refusal behaviour, instead of guessing |
| What you keep | A subscription | A configuration | Tests, documentation and a named owner on your side |
Evidence
A demonstration on your work, not a case study about someone else's
There are no client case studies published here, because there are none we can substantiate and attribute properly yet – and past employers' clients are not ours to claim. What is available instead is more useful at this stage: bring three or four redacted examples of the work you want automated, and we will walk through what the system would do with each of them, including the ones it should refuse. That tells you more about fit than any logo wall.
Daniel Rondeau
The person on the call, and the person making the decisions.
Daniel on LinkedIn →Ask on the fit call how a decision like yours has been approached before.
What it costs
No price list. A written scope for one workflow, with a figure attached.
How many systems the workflow touches and how cooperative their interfaces are, how variable the inputs are, how much of the output needs human review, and whether the data behind it is in a state that can support the work at all. A first conversation about one workflow produces a written scope with a figure attached. We would rather quote something we can stand behind than publish a range that gets renegotiated.
Before you book
The questions that usually come first
How long does one workflow take?
It depends on how many systems it touches and how variable the inputs are – which is why a timeline is part of what a first conversation produces rather than something to quote in advance. A tightly bounded workflow against cooperative systems is a different proposition from one that spans four tools and a mailbox.
What if our data is a mess?
Then that is the finding, and it is better to hear it before a build than during one. Sometimes the answer is conventional automation first, or a smaller workflow where the data is sound. A recommendation to fix something else first is a legitimate outcome.
Do you need access to our production systems?
Not to start. Early scoping works from redacted examples. Where an implementation does need access, what it touches and who holds it is written into the scope before anything is granted.
What happens when the system gets something wrong?
It is designed on the assumption that it will. That is what the approval points, the refusal behaviour and the parallel run are for – so errors surface in front of a person rather than downstream in a customer's inbox.
Will this replace people on our team?
The honest framing is that it releases capacity, and capacity released is not the same as cash saved. We report those separately, because payroll that does not change is not an immediate saving – and pretending otherwise makes the business case fall apart later.
Can you work with the tools we already use?
Usually, and the ones you already run are the first option considered. Where an existing tool does the job, that is the recommendation – it is cheaper for you and it is the right answer.
Not the right engagement? The others
Start with a conversation
Bring one workflow and we will tell you whether AI is the answer
What goes in, what comes out, and roughly how often it happens. If conventional automation or an existing tool is the better answer, you will hear that.
Pick a time that suits you. Or write to daniel@gotai.com