AI & automation
AI is one capability, and it earns its place on a narrow class of work: repetitive tasks involving documents, language or judgement too irregular for a fixed rule. We build those workflows with validation, human review and a known cost per run.
- LLM APIs
- Document extraction
- Human review
- Workflow automation
BUILD
Product engineering & technology
The applications, interfaces, services and infrastructure your business actually runs on — mobile, web, backend, cloud and the automation around them, built by the same people who will later measure and advertise them.
AI is one capability among several, and it is worth using on a narrow class of work: tasks that repeat, involve language or documents, and are too irregular for a fixed rule. Reading an invoice. Deciding which team an enquiry belongs to. Summarising a long thread. Turning a photographed form into a row in a database. Where a plain script already does the job, we write the script instead.
Most of what we build is not a model. It is the workflow around one: the connector that fetches the file, the schema the output has to fit, the validation that rejects a bad extraction, the queue where a person checks the uncertain cases, and the log that lets you reconstruct any single decision months later. That engineering is what makes an automation survive contact with real, messy data.
We do not train foundation models and we do not own one. We integrate third-party model APIs, choose the cheapest model that passes the evaluation rather than the largest one available, and state what a run costs before it goes live. If a workflow cannot be measured, or the volume does not justify the build, we will say so and recommend leaving that step manual.
What usually prompts the conversation
Nobody asks for automation in the abstract. They ask because a specific piece of work has become a bottleneck, or because a previous attempt looked convincing in a demo and then quietly stopped being used.
- Someone retypes the same documents daily
- Invoices, purchase orders, delivery challans or forms arrive as PDFs, scans and phone photographs, and a person copies fields from them into a spreadsheet or an accounting system. The work is slow, it gets error prone late in the day, and it grows in direct proportion to volume. Nobody has time to fix it because everyone is busy doing it.
- Weekly reporting is assembled by hand
- Someone exports from several systems on Monday morning, pastes the results into a template, checks the totals and sends it out. The numbers are usually right, but the work occupies a person who has better things to do, and it stops entirely when that person is on leave. Questions that arrive mid-week wait for the next cycle, because the report cannot be produced on demand.
- An AI pilot never reached production
- The demo worked on a handful of hand-picked examples. Then it met the real inbox: poor scans, mixed languages, two documents in one file, fields that are sometimes simply absent. No one had defined what accuracy was acceptable, there was no review path for uncertain cases, and nobody owned the failures. The pilot was abandoned without anyone deciding to abandon it.
- Enquiries are sorted and routed manually
- Everything lands in one shared inbox or one form, and a person reads each item to decide who should handle it, how urgent it is and whether it duplicates something already open. Response time depends on when that person next opens the queue. Items that need more than one team get forwarded back and forth, and the record of who did what disappears into email.
What we build
Each of these is a workflow with a defined input, a validated output and a person who owns the exceptions. None of them is a model on its own.
Document and data extraction
Structured fields pulled out of invoices, statements, forms and contracts, whether they arrive as clean PDFs, scans or phone photographs. Output is validated against a schema before it is written anywhere, so a malformed extraction fails loudly instead of entering your accounting system quietly.
- Layout and OCR handling for scans, photographs and multi-page files
- Schema-constrained output, so every result has the same shape
- Field-level validation on dates, totals, tax fields and identifiers
- Arithmetic cross-checks that catch a total which does not add up
- Confidence recorded per field, not only per document
- Human corrections captured and folded back into the test set
Classification, triage and routing
Incoming items sorted into the categories your operation already uses, with urgency and an owner attached, then written into the system where the work actually happens. The taxonomy will change, so it stays readable and editable rather than buried in a prompt.
- A taxonomy agreed with the people who work the queue
- Duplicate and near-duplicate detection before anything is routed
- Priority and owner written into the destination system, not an email
- Threshold-based escalation to a human when the model is unsure
- Category changes possible without a code deployment where that is safe
LLM-assisted internal tools
Small internal applications where the model does the tedious part and a person keeps the decision: drafting replies, searching your own documents, summarising long threads, proposing an entry that staff approve or correct. Built as ordinary web applications with authentication, permissions and an audit log.
- Search and question answering over your own document set
- Draft-and-approve interfaces rather than send-automatically
- Role-based access, so not every user sees every document
- Generated output stored alongside the sources it was drawn from
- One-click correction that improves the evaluation set over time
Report and document generation
Recurring reports, summaries and standard documents produced on a schedule or on request, from your own data rather than from a model's recollection. Figures come from queries. The model writes the prose around them, and where a query returns nothing the report says so rather than filling the gap.
- Scheduled delivery to email, a spreadsheet or a dashboard
- Every figure sourced from a query, with the underlying rows attached
- Templates your team can edit without asking us
- Period-over-period commentary written against real movements
- Hard failure when a data source is missing, stale or partial
Workflow automation between systems
The unglamorous half of the work: moving records between a CRM, a billing system, a spreadsheet and a messaging tool so that people stop doing it by hand. Operations are made idempotent, retried with backoff, and parked where someone will see them when they keep failing.
- Webhook and scheduled triggers, with replay for missed events
- Idempotency keys, so a retry cannot double-write a record
- Retry with backoff, then a dead-letter queue that someone reads
- Field mapping documented in the repository, not inside a visual builder
- Dry runs against copied data before anything touches live systems
Evaluation, monitoring and failure handling
The part that decides whether an automation is still trustworthy long after the people who built it have moved on. A labelled test set, a score checked on every change, alerting when output drifts or spend rises, and a documented route back to the manual process.
- A golden set built from real and deliberately awkward examples
- Automated evaluation on every prompt, schema or model change
- Cost and latency tracked per run and per day
- Alerts on error rate, review-queue depth and spend
- A rollback and kill switch, tested before launch rather than after
How we run an automation project
The sequence is deliberately slow at the start. Automations fail when they are built before anyone has agreed what a correct result looks like.
- 01
Watch the work before automating it
We sit with the process as it runs today: where the inputs come from, how many arrive, how long each one takes, and what the person does when something is unusual. That gives an honest baseline and, often, the discovery that part of the process should be deleted rather than automated.
- 02
Define correct, using real examples
We collect a set of real inputs, including the ugly ones, and have someone who knows the work label the expected output. That set becomes the definition of correct for the life of the workflow. Without it there is no way to compare two prompts, two models or two versions, and no way to tell whether a change helped.
- 03
Build the narrowest useful version
One input type, one output, one destination. We test candidate models against the labelled set and pick the cheapest that clears the bar, because the difference in cost between model tiers compounds fast at volume. Anything the narrow version cannot handle is routed to a person from day one.
- 04
Put a person where the risk is
Confidence thresholds decide what passes automatically and what enters a review queue. The queue has a named owner, a target for how quickly it is cleared, and a screen designed for fast correction. Every correction is stored, both as an audit record and as new material for the evaluation set.
- 05
Ship with a budget, a log and a way out
Before launch we set a cost ceiling per run and per day enforced in code, turn on logging of input, output and model version, and agree the kill switch that returns the process to manual. Then we run the evaluation again on a schedule, because model providers change their models without asking you.
Where this pays for itself
Automation is worth building where volume is steady, the input is broadly consistent and the cost of a mistake is visible. These are the patterns that usually qualify.
Document & data work
- Invoices, purchase orders and challans read into structured fields
- Scanned and photographed documents turned into database rows
- Bank and payment statements normalised into one ledger format
- Long agreements reduced to the clauses someone actually checks
- Free-text form responses categorised and deduplicated
Operations
- Incoming enquiries classified and routed to the right owner
- Support tickets tagged, summarised and prioritised before anyone opens them
- Daily and weekly reports assembled and delivered without a person building them
- Records kept in step across a CRM, a spreadsheet and a billing system
- Exceptions pushed into a review queue instead of sitting in an inbox
Internal tools
- A search box over the documents your team keeps re-reading
- Draft replies proposed for a person to edit and send
- Structured summaries of calls, meetings or field reports
- An admin screen where staff correct a model's output in one click
- Templates and categories staff can change without a deployment
How we keep an automated workflow trustworthy
A workflow that runs unattended has to be defensible when it gets something wrong, and it will get something wrong. These controls are part of the build, not an optional hardening phase afterwards.
- A golden test set of real examples, labelled by someone who knows the work
- Evaluation against that set before rollout, and again after every prompt or model change
- Confidence thresholds that decide what passes automatically and what does not
- A human review queue for everything below the threshold, with a named owner
- A defined fallback path for when the model API is slow, rate limited or unavailable
- An audit trail per run: input, output, model version, timestamp and approver
- A cost ceiling per run and per day, enforced in code rather than watched in a dashboard
- Prompts, schemas and model versions in version control, reviewed like any other code
- Data retention rules agreed up front: what is sent, what is stored and for how long
- A kill switch that returns the workflow to the manual process without a deployment
What we do not claim
We do not train or own foundation models. The model in these workflows is a third-party API, and we tell you which provider it is, what is sent to it and what that provider's published terms say about retention and training. We do not guarantee accuracy. We measure it against a test set you can inspect, report what it scored, and build the validation, review and fallback paths that assume it will sometimes be wrong.
What we work with
These names are descriptive references to tools and services we use. They imply no partnership, endorsement, certification or affiliation with their owners, and each remains the property of its respective owner.
- Models and model APIs
- OpenAI API
- Anthropic API
- Google Gemini API
- Azure OpenAI Service
- Amazon Bedrock
- Ollama
- Hugging Face Transformers
- Documents and data
- Google Document AI
- Tesseract OCR
- PyMuPDF
- pandas
- PostgreSQL
- pgvector
- BigQuery
- Runtime and orchestration
- Python
- FastAPI
- Node.js
- TypeScript
- Celery
- Redis
- Google Cloud Run
- GitHub Actions
- Interfaces and integrations
- Next.js
- React
- Google Sheets API
- Google Workspace APIs
- Slack API
- n8n
- Webhooks
What you end up with
- A repetitive task handled by software, with a person reviewing the uncertain cases
- Extraction and routing measured against a test set you can inspect yourself
- A known cost per run, capped in code before it can surprise you
- Prompts, schemas and model versions in your repository, under review
- A documented route back to the manual process if the workflow is stopped
What people ask before starting
01Do you build your own AI models?
No. We do not train or own foundation models. We integrate third-party model APIs and existing open-weight models, and the engineering we do sits around them: schemas, validation, review queues, evaluation and cost control. Anyone claiming a proprietary model at this scale is usually describing a prompt. We will tell you which model a workflow uses and why that one was chosen.
02What actually drives the cost of this?
Two separate things. Build effort is driven by how messy the inputs are and how many systems have to be touched, not by the model. Cost per run is tokens or pages processed multiplied by volume, and we estimate it before building rather than after the first invoice. Long documents, image-heavy scans and unbounded retry loops are the usual reasons a bill grows.
03What happens when the automation gets something wrong?
It will get things wrong, so the workflow is designed around that fact. Output below the confidence threshold goes to a review queue instead of straight through. Validation rejects results that fail a schema or an arithmetic check. Every run is logged with its input, output and model version, so a bad result can be traced, corrected, and added to the evaluation set.
04Where does our data go, and is it used for training?
Anything a workflow sends to a third-party model API leaves your infrastructure. We tell you which fields are sent, to which provider, and what that provider's published terms state about retention and training on API data. Where the content is sensitive we prefer redaction before sending, a model running inside your own cloud account, or leaving that step manual.
05Can we run and change this ourselves afterwards?
Yes, and it is built on that assumption. Code lives in your repository, API keys sit in accounts you own and pay for directly, and prompts and schemas are versioned files rather than settings inside a vendor console. Where a taxonomy or template will change often, we put it somewhere your staff can edit. You are not required to keep us to keep it running.
06What will you tell us not to automate?
Low-volume work, where the build costs more than the manual effort it saves. Decisions with legal or financial consequence that nobody is willing to review. Processes that change every month, because the evaluation set never stabilises. Anything where a wrong answer is both expensive and undetectable. In those cases the honest answer is often a better form, a cleaner process, or a small script.
What this work usually connects to
Automate one workflow properly
Tell us about the task your team repeats most, how often it happens and what it looks like when it goes wrong. We will tell you whether it is worth automating.
Directcontact@mnfinfotech.com