You bring a task you understand well. I turn it into a working system you can test. That might mean connecting the tools you already use, automating the repeat steps, or adding an AI agent where reading messy, unstructured information is the hard part. We agree where the system starts and stops before I write any code.
The right problem to bring
One recurring workflow, with clear inputs, someone who owns it, and a result a person can check. Preparing documents, finding information and producing the same report again are good places to look. Whether an agent is the right fit is something we decide together, task by task.
If you’re still choosing where to start, begin with an opportunity assessment.
What the implementation includes
- An agreed boundary for the workflow, success criteria and a set of real test examples.
- Connections only to the systems and accounts you approve.
- A focused build, with a person approving any step where a mistake would be costly.
- Tests for normal inputs, uncertain answers, odd cases and recovering from failures.
- Documentation covering how it runs, who has access, what it depends on, what it costs to keep running and who owns it.
- A handover, so the person responsible knows what runs and how to switch it off.
We agree the deliverables for your project up front, and anything bigger becomes a separate stage.
From prototype to operation
First we get the smallest working version running against real examples. Then we go looking for trouble: missing information, a changed file format, a service that’s down, an answer that needs a second look. An agent gets authority only after it has earned it on your examples.
Uncertainty should be visible. When an integration fails or the system isn’t confident, the work goes back to a person by a route we’ve agreed. We settle how long data is kept, how it’s monitored and who can access it before the system touches your business data.
Remote collaboration and ownership
We work through scheduled reviews, a shared project record and a code repository we both can see. We write down who owns the code and the accounts, who can approve changes, and who looks after it once I’ve handed it over. Provider fees and maintenance get discussed openly, so there are no surprises after the demo.
Where this comes from
In my day job I’ve put AI coding agents into a regulated software pipeline. They started read-only, then were allowed to comment, and they still can’t change code on their own. I’ve also built a Terraform template that lets a team set up its monitoring in an afternoon, and a release process that checks a service is healthy before every deploy. Your workflow gets the same treatment: small permissions, visible checks, and a way back to a person. You can also browse public projects like Shiny-filteRs and Hinuhinu.
Scope and pricing factors
Scope depends on how many systems we connect, how ready your data is, the permissions involved, how much human review you need and what maintenance you expect. We agree a written proposal before the build starts. If a bigger replacement is on the cards, we split it into stages.
Common questions
Can this work with our existing tools?
We check what your tools actually allow first: their interfaces, account permissions and limits. That tells us whether it fits, rather than guessing from a product name.
Can we keep a person in control?
Yes. Review and approval can be steps in the workflow itself. The design says plainly which actions run on their own and which wait for a person.
After the build, training and adoption helps your team use it and look after it.