Engineering teamtaking briefs
Describe the work nobody wants to do. We build the thing that does it.
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. Our engineers build the agent that does that work, inside the systems you already run.
The configuration appears here as it works.
What the first month looks like
Not a discovery phase that bills for six weeks and produces a slide deck. You see something running on your own data in the first fortnight.
Day 1
We watch you do it
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 on a normal Tuesday.
Day 3
A scope with a number on it
What we will build, what we will not, which systems we touch, what it costs and what it should give back. You can stop here and owe us nothing further.
Week 2
Running on your real data
Not a prototype on sample files. It works your live queue in shadow mode, and you compare what it decided against what your team decided.
Week 3
Turned on, with a human in the loop
It handles the confident cases and routes the rest to a review queue. You choose the confidence threshold, and you can move it any time.
Week 4
The threshold comes down
Once the review queue agrees with it often enough, more goes straight through. Every override we see becomes a change.
Ongoing
It stays ours to keep working
Your supplier changes their invoice layout, a system gets replaced, volume triples. We handle that. You do not inherit a codebase and a problem.
You describe it. We do the unglamorous part.
The demo above is a demo, and we would rather say so. What is real is the shape of it: you explain the work in your own words, and what comes back is a specific automation with a trigger, steps, the fields it reads and the systems it writes to.
The difference between that and a finished build is the unglamorous part, which is most of the job. The eleven carrier layouts. The supplier who sends a photo of a scanned invoice. The approval rule nobody wrote down. That is the work you are hiring engineers for.
We start from the exceptions
The happy path is a day of work. The month is everything your team quietly handles without noticing that they do.
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.
You can see what it did
Every decision it makes is logged with the input it saw and the reason it gave, so a disagreement is an investigation and not an argument.
The trigger
The event that starts it: an email, a webhook, a row appearing, a call ending.
day 1
The steps, in order
What it reads, what it decides, what it writes, and where it stops to ask.
day 2
The systems it touches
Named, with the access it needs and the access it does not get.
day 2
The number
Build cost, running cost, and the hours it should give back.
day 3
If the scope says this is not worth building, we say that. It is a cheaper sentence for both of us than a project.
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.
Move the sliders to your own situation. This is the arithmetic we use when we scope a build, with the assumptions printed underneath so you can argue with them.
Years of shipping this, not learning on your project.
Our engineers built and ran production software long before agents were a category, and have been shipping agentic systems since they became one. The LumisReach platform you can see on the rest of this site is our own work: telephony across two carrier stacks, a voice agent on live calls, document pipelines, video generation, social publishing, a CRM underneath all of it.
That matters because a custom build is mostly judgement. Knowing which parts a model should decide and which parts must stay deterministic. Knowing when a retry is safe. Knowing that the demo works and the Tuesday after Thanksgiving is what breaks it.
We build on what we already run
Your workflow inherits the queueing, retries, logging and observability the platform already uses in production, rather than starting from an empty repository.
Deterministic where it has to be
Money, compliance and anything irreversible runs on rules. The model is used where judgement genuinely helps, and nowhere else.
Built to be handed over
Documented, and yours. If you ever want to take it in-house, you can, and we will help you do it.
If it is repetitive, rule-heavy, and currently done by a person reading a screen, it is probably in scope. If it needs a licence or a judgement call with real liability, it probably is not, and we will tell you which one you have.
Your systems, however old or strange.
Nobody replaces their ERP because they wanted an automation. So we work with what is there: a modern API if you have one, and if you do not, a database, a nightly file drop, a scraped portal, an emailed report, or a login somebody uses by hand.
We have connected to things with no documentation and no support contract. It is rarely elegant, but it is usually possible, and it beats a migration nobody asked for.
A documented API
The easy case, and the fastest to ship.
best
Webhooks or an event stream
Real-time, and no polling to pay for.
good
Direct database or warehouse
Read replica where your DBA prefers it.
good
Files on a schedule
SFTP, a shared drive, or a nightly export.
fine
Email in and out
More systems speak this than speak REST.
fine
A browser, driven
For the portal with no API and no plans for one.
last resort
Sometimes the honest answer is not a build.
We also get brought in to work out whether something should be built at all, which is a different engagement and a cheaper one.
Where a process is actually breaking. Whether an agent belongs anywhere near it. Whether the tool you already pay for does this if somebody configured it properly. Which of six ideas is worth the first quarter. You get a written answer you can take to your board, and no obligation to hire us for the build.
Where the time actually goes, measured rather than estimated, across the people doing the work.
Which processes are worth automating, ranked by hours returned against build effort.
Which ones should not be touched, and the specific reason for each.
What your existing tools already do that nobody has switched on.
A build order with costs, so the first project is the one that pays for the second.
Half the value of this is the list of things not to build. That list is free to act on and costs you nothing further.
The three ways this normally gets done.
Every business with this problem has already considered the other two. Here is the honest comparison.
Time to something running
An agency or a new hireA quarter, if the discovery phase goes well.
With our teamWorking on your real data inside two weeks.
Who learns your business
An agency or a new hireA contractor who leaves with it when the statement of work ends.
With our teamA team that stays on it, because we run it for you afterwards.
What you get at the end
An agency or a new hireA repository, and now it is your problem to run.
With our teamA working system we keep running, and the code if you ever want it.
When a supplier changes a format
An agency or a new hireA change request, a quote, and a fortnight.
With our teamWe already saw it in the logs and fixed it.
If it turns out to be a bad idea
An agency or a new hireYou find out in month three, having paid for two.
With our teamYou find out in the scope, for the price of three days.
The foundations
An agency or a new hireBuilt from scratch: queueing, retries, logging, alerting, all of it.
With our teamInherited from a platform already doing this in production.
What to expect
Drawn from the builds we actually run. Your project will have its own shape, and the scope will say so plainly before you commit.
3 days
From first call to a scope
With a cost, a timeline and an honest opinion attached.
2 weeks
To something on your real data
Shadow mode first, so you can compare it against your team.
90%+
Typical straight-through rate
The rest goes to a review queue you control.
0
Systems you have to replace
We connect to what is there, including the awkward parts.
A brief, and what came back
Lightly edited from a first call with an auto insurance agency. The build in the demo above is this one.
Them
Four people spend most of their morning opening claim emails, reading the attachments and typing the numbers into our claims system. It is the worst job in the building.
Us
How many different documents, and how many carriers send them?
Them
Four types, maybe eleven layouts. Some are PDFs, some are photos somebody took of a printout.
Us
Then the build is classify, extract, validate against the policy, post the claim. The photos are the hard part, and that is the part we will spend the time on.
Us
We will not let it post anything it is not sure about. Under your confidence threshold it goes to a review queue, and your team only sees the ones worth their attention.
Them
What happens when a carrier changes their form?
Us
Confidence drops on that layout, those documents route to review, and we get an alert before anybody on your side notices. That is our job, not yours.
Tell us about the worst job in your building.
One call, no prepared brief needed. If it is worth building we will scope it in three days, and if it is not we will say so on the call.