Short answer: automate the back-office work with a custom AI agent when the task is repetitive, spread across people, and no product on the market covers it; buy a product when one does; and hire engineers who have run agents in production rather than ones learning on your project. The build that works has a trigger, deterministic rules for money and compliance, a model only where judgment helps, a human review queue with a confidence dial, and a team that stays on it after launch. That is the shape of LumisReach's Custom Agentic Workflows engagement.
Every business runs on a few processes that no product was ever going to cover: the inbox somebody empties by hand, the spreadsheet three systems disagree with, the approval that waits on one person, the supplier who sends a photo of a scanned invoice. This guide is about those processes.
What is a custom agentic workflow?
A custom agentic workflow is a piece of software, built for one business, in which an AI model makes some of the decisions and deterministic code makes the rest. It has four parts:
- A trigger. The event that starts it: an email arriving, a webhook firing, a row appearing in a table, a call ending.
- Steps. What it reads, what it decides, what it writes, and where it stops to ask a person.
- Systems. The named applications it touches, with the access it needs and the access it does not get.
- Economics. Build cost, running cost, and the hours it should give back.
"Agentic" means the model can choose among steps rather than follow one fixed path. It does not mean the model is trusted with everything. Money, compliance and anything irreversible run on rules.
Should you build, buy, or hire?
| Situation | Best answer |
|---|---|
| A product already does the job well | Buy it. A custom build of a solved problem is the most expensive way to get a worse version. |
| The task is unique to your business and spread across several people | Build, with engineers who have shipped agents in production. |
| You have engineers in house who can own it after launch | Build it yourself, on a platform that gives you queues, retries and logging. |
| The task is rare, or a form and a checklist would fix it | Do not build. Sometimes the honest answer is not a build. |
The last row matters. A good engagement starts with a scope you can walk away from, and some scopes should end with "this is not worth automating".
What should you automate first?
Count the hours before you count the savings. Most back-office work is invisible because it is spread thin: an hour here, three hours there, nobody's whole job. Add it up across the people doing it and the number is usually larger than anyone in the building expects. The best first candidates share three properties:
- High volume, low variance. Hundreds of near-identical items a month, with a handful of known exceptions.
- A clear definition of done. You can say what a good outcome looks like on a normal Tuesday.
- Systems you can reach. An API, a database, a file drop, a mailbox, or at worst a portal somebody logs into by hand.
Document intake and extraction (invoices, purchase orders, carrier paperwork, intake forms) is the most common first build, because it scores on all three.
How do you connect to systems that have no API?
Nobody replaces their ERP because they wanted an automation, so a custom build has to work with what is there. In rough order of preference:
- A modern REST API, the easy case and the fastest to ship.
- Webhooks, real time and no polling to pay for.
- A database connection, on a read replica where your DBA prefers it.
- A file drop: SFTP, a shared drive, or a nightly export.
- An emailed report, which more systems speak than speak REST.
- A scraped portal, for the system with no API and no plans for one.
LumisReach engineers have connected to systems with no documentation and no support contract. It is rarely elegant, but it is usually possible, and it beats a migration nobody asked for.
Where should the model decide, and where must code decide?
This is the judgment that separates a demo from a production system. The model is used where judgment genuinely helps: reading a messy document, classifying an email, choosing which of three templates fits. Deterministic code handles everything else: totals, approval thresholds, compliance checks, anything that moves money, anything that cannot be undone.
Two rules follow. First, confidence is a dial, not a claim: anything the agent is unsure about goes to a person, you set where that line sits, and you watch it before you move it. Second, every decision is logged with the input it saw and the reason it gave, so a disagreement is an investigation rather than an argument.
What does the first month look like?
Not a discovery phase that bills for six weeks and produces a slide deck. The LumisReach engagement runs like this:
- A working session with the person who actually does the task. Where it starts, every exception, what makes it go wrong, and what a good outcome looks like.
- A written scope. What will be built, what will not, which systems it touches, what it costs and what it should give back. You can stop here and owe nothing further.
- Shadow mode on your live queue, inside the first fortnight. Not a prototype on sample files. It works real items and you compare what it decided against what your team decided.
- Turned on, with a human in the loop. It handles the confident cases and routes the rest to a review queue. You choose the threshold.
- Expansion. Once the review queue agrees with it often enough, more goes straight through. Every override becomes a change.
- Maintenance. Your supplier changes their invoice layout, a system gets replaced, volume triples. The team handles that. You do not inherit a codebase and a problem.
The happy path is a day of work. The month is everything your team quietly handles without noticing that they do: the eleven carrier layouts, the supplier who photographs invoices, the approval rule nobody wrote down.
Why hire engineers who already run agents in production?
A custom build is mostly judgment. Knowing which parts a model should decide and which must stay deterministic. Knowing when a retry is safe. Knowing that the demo works and the Tuesday after Thanksgiving is what breaks it.
The LumisReach platform is the team's own work: telephony across two carrier stacks, a voice agent on live calls, document pipelines, video generation, social publishing, and a CRM underneath all of it. A custom workflow built on it inherits the queueing, retries, logging and observability the platform already uses in production, rather than starting from an empty repository. And it is documented and yours: if you ever want to take it in house, you can, and the team will help you do it.
What does a custom agentic workflow cost?
Every scope is priced individually, with build cost, running cost and the hours it should give back written down before you commit. The arithmetic is the same one the ROI calculator on the Custom Agentic Workflows page uses, with the assumptions printed so you can argue with them. The scoping step costs nothing, and you can stop after it.
Frequently asked questions
What is a custom agentic workflow?
A custom agentic workflow is software built for one business in which an AI model makes some decisions (reading documents, classifying requests, choosing a next step) and deterministic code makes the rest (totals, approvals, compliance, anything involving money). It has a trigger, steps, named systems it touches, and a human review queue for low-confidence cases.
Should I build a custom AI agent or buy a product?
Buy a product when one already does the job well. Build when the task is unique to your business, high volume, spread across several people, and reachable through an API, database, file drop, mailbox or portal. Hire engineers who have run agents in production to do the build, and insist on a written scope you can walk away from.
Can a custom AI agent connect to a system with no API?
Yes. Options include a database read replica, an SFTP or shared-drive file drop, a nightly export, an emailed report, or a scraped portal login. LumisReach engineers have connected to systems with no documentation and no support contract.
How do you keep a custom AI agent from making costly mistakes?
Keep money, compliance and irreversible actions on deterministic rules; route anything the model is unsure about to a human review queue with a confidence threshold you control; log every decision with the input it saw and the reason it gave; and run in shadow mode on the live queue before turning it on.
How long does it take to build a custom agentic workflow?
With LumisReach, something is running on your own data in shadow mode within the first fortnight, after a working session and a written scope. Full rollout depends on how many exceptions the live queue surfaces.