Loading
AI agents · LLM applications · Workflow automation
A chatbot answers a question. An agent is given a goal, works out the steps, uses the tools you approved, does the work and reports back. We build the second kind, with permissions, logs and human approval built in from the first sprint.
The problem
Most businesses do not lose time to hard problems. They lose it to the same forty minutes repeated across a week: reading a supplier email and re-typing the line items into an order form, checking whether a purchase order matches the goods received note, drafting the fourth near-identical quotation of the day, hunting through a shared drive for the version of the policy that was current in March.
None of that is difficult work. It is just work that only a person can currently do, because it involves reading unstructured text, making a small judgement, and then touching two or three systems that were never designed to talk to each other. That is the exact shape of task a language model plus a set of tool permissions handles well.
The useful distinction is between answering and acting. A chatbot is a question-answering surface: you type, it replies, and a human still does the work. An AI agent is given an objective, plans a sequence of steps, calls the tools it has been granted, and then either completes the task or stops and asks a person to approve the step you decided a person should approve. The second one changes how long a process takes. The first one mostly changes how the FAQ is delivered.
This is also where the honest conversation belongs. Plenty of processes that get described as AI candidates are really validation rules, a scheduled job and a decent form. When that is true we will say so, because a rules engine that costs a fraction as much and never hallucinates is the better answer.
What is included
8 areas of work. Most engagements start with one or two and widen once the first release is in use.
Agents that plan a multi-step task, call only the tools you have granted, and pause for a named person's approval at the steps you designate. Least privilege by default: an agent that needs to read the CRM does not get write access to it. Every run is logged end to end.
Retrieval-augmented applications that answer from your own documents, contracts, tickets and manuals rather than from the model's general training. Chunking, embedding, re-ranking and citation, so every answer shows which source paragraph it came from and a reader can check it.
Invoices, purchase orders, delivery challans, lab reports, insurance forms and scanned contracts read, extracted into typed fields, validated against your master data, and pushed into the system that needs them. Low-confidence extractions are routed to a human queue instead of being guessed at.
The non-AI half of the job, which is usually the larger half. Triggers, queues, retries, idempotency, scheduled jobs, approval chains and notifications, so a step that fails at 2am is retried and surfaced rather than silently dropped.
Connectors into ERP, Tally, CRM, email, WhatsApp Business, shared drives and internal databases, written as explicit tool definitions with typed inputs and outputs. The model never gets loose database access; it gets a small set of functions that do exactly one thing each.
Input and output validation, refusal handling, confidence thresholds and a regression suite of real cases that runs on every prompt or model change. Approval gates are designed with you: which actions need a human, who that human is, and what they see when they are asked.
Which data can leave your network, which model tier each step actually needs, whether an open-weights model running on your own infrastructure is the right call, and a per-workflow token budget with alerting. Cost per completed task is tracked, not cost per thousand tokens.
A fixed-scope pilot on one process, a dedicated pod when several processes are moving at once, or a support retainer once the agents are live and need evaluation runs and model updates. Pilots are deliberately small enough to abandon without regret.
How we work
We start by watching the process, not by choosing a model. One or two sessions with the people who do the task today, a written description of the current steps, the exceptions, the volumes and the cost of getting it wrong. That last item decides almost everything downstream: a task where a mistake is caught at the next desk can run with light supervision, and a task where a mistake reaches a customer or a ledger gets a mandatory approval gate.
Then we build a narrow pilot on real data, usually four to six weeks, scoped to one process and one team. It runs alongside the manual process rather than replacing it, so you can compare outputs before anything is trusted. We write an evaluation set from your own historical cases, so accuracy is measured against your records rather than against a benchmark from a paper.
Rollout is staged by permission. The agent starts read-only, then gains write access to one system, then to the next, each step logged and reversible. Every action it takes is recorded with the inputs, the tools it called and the output, so when someone asks why an invoice was coded to the wrong account in week nine you can answer with evidence rather than a shrug. Monitoring and a cost ceiling per workflow are part of the handover, not a later phase.
In practice
We start by watching the process, not by choosing a model. One or two sessions with the people who do the task today, a written description of the current steps, the exceptions, the volumes and the cost of getting it wrong. That last item decides almost everything downstream: a task where a mistake is caught at the next desk can run with light supervision, and a task where a mistake reaches a customer or a ledger gets a mandatory approval gate.
Where it comes up
Stack
We pick from a stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Sector context
Domain knowledge shortens discovery. These are the sectors where we already understand the vocabulary and the failure modes, so the first version of the build is closer to right.
Lot and parcel movement, job-work with karigars, grading records and the reconciliation that follows a stone through five pairs of hands.
Shift-based production data, downtime causes, quality records and the daily gap between what the ERP holds and what the floor actually did.
Appointments, records, billing and reporting, where patient data handling and clinical workflow set the constraints before anything is designed.
We have not published a case study for this service yet. When we do, it will name the client with written permission and quote numbers the client can defend. Nothing else is worth reading.
Until then, the useful version of proof is a conversation about your problem. Ask us how we would approach it, what we would refuse to do, and where the estimate is soft.
Ask about comparable workQuestions
Your chatbot receives a question and returns text. An agent receives a goal, decides on a sequence of steps, and calls tools that change something: creating a ticket, updating a record, sending a draft for approval. The distinction matters commercially because only the second kind removes work from a person's day. It also matters for risk, which is why an agent gets an explicit permission list and an audit log and a chatbot does not need either.
Not unless you have decided a particular step is safe to run unattended, and even then it is logged. We design the approval boundary with you during discovery: typically read and draft actions run automatically, and anything that moves money, changes a customer-facing record or sends an external message stops for a named approver. Permissions follow least privilege, so an agent has access only to the specific functions its task requires.
Not on the configurations we deploy. Enterprise API tiers from the major providers exclude API traffic from training by default, and we set that explicitly rather than assuming it. Where the data cannot leave your network at all, which is common for financial records and patient data, we run open-weights models on your own infrastructure and accept the trade-off in capability rather than sending the data out.
A pilot on a single process usually runs four to six weeks. The cost depends on how many systems have to be integrated and how clean the source data is, and we quote it after discovery rather than before, because a two-week integration with a legacy ERP is not the same job as reading an email inbox. We scope pilots small enough that abandoning one is a cheap decision, which is the point of running one.
You find out from the evaluation suite before it reaches production, or from the confidence threshold and the human queue after it does. Every workflow we build has a defined behaviour for low confidence, which is to escalate rather than to proceed. Wrong outputs that do reach a person are captured as new test cases, so the same failure is checked on every subsequent change to the prompt or the model.
Sometimes, and we would rather tell you at the start than three months in. Retrieval over documents copes with fairly messy input. Extraction into a system of record does not, because it will faithfully write bad data faster than a person could. If the master data is unreliable, a short data and BI engagement usually has to come first, and that conversation is cheaper than the pilot it would have sunk.
Works well with
Send a paragraph about what is not working today. You will get a written reply from someone who would be on the build, covering how we would approach it, roughly what a first phase looks like, and whether ai & automation is even the right place to spend the budget.
What happens next
