By team
AI agents and automation for operations teams
Operations is where every system in a company stops being connected and a person takes over. Half the process runs in the software and half in a spreadsheet, an inbox and somebody’s memory of how it is really done. We build the layer that closes that gap — and we start by watching the work rather than reading the process document.
Two weeks to a written build plan · no obligation to build with us
- Mapped from the work, not the document
- The real processMapped from the work, not the document
- Nothing changes a record unseen
- Reviewed writesNothing changes a record unseen
- Held as code, versioned and testable
- Your rulesHeld as code, versioned and testable
- To a written build plan, via the audit
- 2 weeksTo a written build plan, via the audit
Where the time goes
If two of these are true, there is something here
Written the way the people doing the work describe it, not the way a process document does.
The process document and the real process disagree
The documented flow is four steps. The real one has eleven, including two workarounds nobody has written down and one that only one person knows.
A spreadsheet is load-bearing
There is a workbook without which the department stops. It has formulas nobody wants to touch and a single owner who cannot take a holiday.
Handovers happen by email
Work moves between teams as a message with an attachment. Status is whoever replied last, and nothing is queryable.
Nobody can say how long anything takes
Cycle time, backlog and rework are not measured, so improvement arguments are made with anecdotes and the loudest recent failure wins.
What we connect to
The systems you are already running
Operations teams rarely own a single system. They own the seams between several, which is exactly where we work.
- Systems of record
- ERP (SAP B1, Odoo, Dynamics)
- CRM
- WMS
- Accounting systems
- Custom databases
- Where the work really happens
- Excel and Google Sheets
- Shared mailboxes
- WhatsApp and Slack threads
- PDF attachments
- Paper forms
- Coordination
- Jira / Asana / Trello
- Microsoft 365
- Google Workspace
- Ticketing tools
- Power Automate
What we build here
Five things worth building for operations
Each one names the systems it touches, because an integration that is not named is an integration nobody has thought about yet.
- 01
Close the spreadsheet gap
The load-bearing workbook is turned into a service: the same rules, held as versioned code, with the data in a database and the spreadsheet kept as a view for as long as people want it. Nobody is asked to give up their view on day one.
- Touches
- The workbook · system of record · reporting
- What changes
- The process survives its owner taking leave.
- 02
Inbox-driven work made trackable
Requests arriving by email or chat are classified, given a case record, routed by your rules and answered from the systems that hold the answer — with the thread kept as evidence and the case as the truth.
- Touches
- Shared mailbox · ticketing · systems of record
- What changes
- Work has a queue, a status and an age instead of a thread.
- 03
Reconciliation between systems
Two systems that should agree are compared on a schedule, with differences presented as a worklist ranked by value and age rather than as an export nobody opens.
- Touches
- Any two systems of record · reporting
- What changes
- Drift is caught daily instead of at period end.
- 04
Exception handling with the context attached
When a case cannot be cleared automatically it arrives with everything needed to decide: the source documents, the rule that stopped it, what similar cases did, and a proposed action to accept or change.
- Touches
- Case store · systems of record · review queue
- What changes
- Exceptions take minutes instead of an investigation each.
- 05
Measurement that was never there
Cycle time, backlog, rework rate and first-pass yield measured from the events the system already produces, per step, so process arguments can be settled with numbers.
- Touches
- Case events · dashboards · exports
- What changes
- Improvement is targeted at the step that is actually slow.
How it is put together
How an undocumented process becomes a system
The first phase is not technical. Most failed operations automation projects automate the documented process, which is not the one anybody follows.
- 01
Observe
We sit with the people doing the work and map what actually happens, including the workarounds. The output is a map of every step, the system it touches and how long it takes.
- 02
Separate rules from habits
Some of what the team does is policy and some is how it has always been done. Writing the rules down forces that distinction, and the conversation it causes is frequently worth more than the software.
- 03
Automate the middle
The routine path is automated first and the two ends — intake and exception — are left with people. Most processes are eighty per cent routine, and that eighty per cent is where the time is.
- 04
Queue the rest
Anything the rules do not cleanly cover goes to a review queue with context and a proposed action. The queue is designed to be cleared in a morning, not to become the new backlog.
- 05
Instrument
Every case emits events, so cycle time and exception rate are visible from the first week. That is also how you decide what to automate next, rather than guessing.
Your data
What we will and will not do with it
Stated plainly, and without claiming a certification we do not hold. If a requirement here is harder than what is written, say so on the call and we will tell you whether it is buildable.
We will not automate a process that should be deleted
Some steps exist because a system could not do something in 2016. Automating them preserves the workaround forever. Where we find one, we will say so — even though the smaller project is worth less to us.
Writes stay reviewed until they have earned otherwise
Every write to a system of record runs through a review queue while we measure agreement against the people doing the job today. You see the agreement rate and you decide when a category graduates.
The team sees it before it replaces anything
Automation that lands on an operations team as a surprise gets worked around within a fortnight. The people doing the work are in the discovery and the parallel run, because they are the ones who know what the exceptions really are.
Proof
We have taken a load-bearing spreadsheet out of a business
Base Papers had the classic operations problem: a real system, and beside it a workbook holding the numbers people actually trusted. We replaced the parallel spreadsheet with a system the stock and the accounts live in. The pattern repeats in almost every operations engagement we take.
- For stock and accounts
- Single sourceFor stock and accounts
- Floor to ledger
- Real-time syncFloor to ledger
Technology
What this gets built with
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Agents
- LangGraph
- Structured output
- Retrieval with citations
- Review queues
- Integration
- REST / SOAP adapters
- Mailbox ingestion
- Spreadsheet import
- Webhooks
- FastAPI
- Rules and data
- Versioned rule code
- PostgreSQL
- Celery
- Event log
- Idempotency keys
- Visibility
- Cycle-time dashboards
- Exception reporting
- OpenTelemetry
- Per-run cost logging
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 1–2
Sit with the work
We watch the process as it is actually done, not as the process document says. The output is a map of every step, which system it touches and how long it takes.
DeliverableProcess map and a shortlist of what is worth automating - 02Week 2–3
Design the access layer
Which systems get read, which get written to, what scope each credential carries, and which decisions stop for a person. Agreed in writing before anything is built.
DeliverableArchitecture and permission model - 03Week 3–8
Build against your real data
Built in your sandbox against real records, not a demo dataset. The write path goes through a review queue from the first day, so nothing lands in a live system unseen.
DeliverableRunning system in staging, with the review queue - 04Week 8–10
Run it beside the humans
It runs in parallel with the people doing the job. We compare the two outputs, fix what differs, and only then start letting the routine path through unattended.
DeliverableAgreement rate report and a go-live threshold - 05Ongoing
Hand over and watch
Source code in your repository, deployment in your accounts, cost and failure dashboards you can read without us. Support if you want it, not because you are locked in.
DeliverableRepository, runbook and monitoring
Why Devs Core
Three reasons that are checkable
We run two of our own products
Cadenza and Budge are ours. What an agent costs per run, where it fails and which decisions need a person came from operating them, not from a vendor deck.
The write path is reviewed by default
Anything that changes a record in a system of record goes through a queue a person can see. You choose what graduates to unattended, and when.
You own the code
Source in your repository, infrastructure in your accounts, model keys in your name. There is no runtime of ours you have to keep paying for.
Questions
Operations — the questions we get asked
Where should an operations team start?
With the process that has the clearest right answer and the most repetitions — usually a reconciliation or a document intake. Start with the one that is judged rather than counted and you will spend the project arguing about whether it worked.
Our process is not documented. Is that a blocker?
No, and it is the normal starting point. Documenting it is the first phase of the work. The documented version would probably have been wrong anyway.
Will this mean redundancies?
That is your decision, not something we will pretend not to be part of. What we see most often is the same team clearing a backlog they could never reach and taking on work that was being declined. We would rather you go in with a clear intention than discover it afterwards.
What if the rules change every few months?
Then they are held as versioned code with tests, and changing them is a small deliberate change rather than a rebuild. Frequent rule change is an argument for explicit rules, not against automation.
Can we use a no-code tool instead?
For a simple two-system trigger, often yes, and we will tell you when that is the right answer. It stops working when you need exception handling, an audit trail, a review queue or logic that is hard to express in a flowchart — which is most operations work of any size.
How do we know it is working?
By the numbers instrumented from day one: cases cleared unattended, exception rate, cycle time and agreement with the humans during the parallel run. If those do not move, the project has not worked, and that should be visible to you without asking us.
Related
What operations buys most often
- Read more
Process Automation
Replace the manual steps between two systems — the re-keying, the copy-paste, the spreadsheet that reconciles what neither system knows.
From $4,500 - Read more
AI Agent Development
Agents that take real actions in your systems — reading live data, drafting work, and writing back only what a person has approved.
From $6,500 - Read more
AI Integration Services
The access layer between the software you already run and any AI model — so an agent can reach your ERP, CRM or helpdesk without being handed the keys.
From $8,000 - Read more
AI Readiness Audit
Two weeks that end in a written plan: which processes are worth automating, what each would cost, and what has to be fixed first.
From $2,400
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com