How Agentic AI is Transforming the IT Services Landscape in Kolkata

The important shift is not that models got better at answering questions. It is that they became reliable enough to use tools — to query a database, call an API, write to a file, control a browser, send a message — and to plan a sequence of those actions towards a goal rather than performing one at a time.

That turns a language model from a text generator into something that can complete a task. An invoice arrives by email; an agent extracts it, checks the supplier against master data, validates the GSTIN, compares line items to the purchase order, flags the discrepancy, and prepares the entry for a human to confirm. Nothing in that chain is intellectually difficult. All of it was previously a person.

The second change is cost. Running a well-engineered extraction workflow over three thousand invoices a month costs less than a mid-range mobile phone. Two years ago the same workload would have been priced out of consideration for most mid-market businesses.

This is where most projects succeed or fail, and where most vendor claims deserve scrutiny. Our operating rule is straightforward: reads are autonomous, writes are gated. An agent may query anything it is authorised to see, compose a response, prepare a transaction and present it for approval — and a human confirms before anything changes in a system of record.

That sounds conservative and it is deliberately so. The failure mode of an over-trusted agent is not a wrong answer on a screen. It is three hundred incorrect entries in an ERP that take a fortnight to unwind, discovered by an auditor. Starting gated and widening deliberately, with evaluation data to justify each widening, is faster overall than starting open and rebuilding organisational trust after an incident.

The corollary is that the approval step must be cheap. If confirming an agent's work takes as long as doing it, nothing has been gained. Good design puts the document and the extracted values side by side and makes confirmation a two-second action.

Document processing dominates, and it is not close. Mid-sized companies here handle an enormous volume of semi-structured paper relative to their size, largely because their trading partners do — purchase orders in twelve formats, supplier invoices, transport documents, lab reports, bank statements. Straight-through processing rates of 88 to 96% are routine after tuning, which converts a full-time data entry role into a twenty-minute daily exception review.

Reconciliation is second. Bank statements against gateway settlements against the ledger, matched automatically with only genuinely ambiguous cases presented for judgement. Finance teams consistently report this as their single largest time recovery.

Third is knowledge retrieval — assistants grounded in a company's own SOPs, equipment manuals, quality specifications and contracts, answering with a citation or refusing to answer. In a plant environment where the correct answer about an operating limit matters, an assistant that says "I do not know" is far more valuable than one that guesses confidently.

If a firm sells hours and a tool removes hours, that firm has a structural problem. This is the uncomfortable part of the conversation in Sector V, and it is not solved by adopting the tool — adopting it accelerates the problem for an hours-based business.

The firms that come through this comfortably are the ones already selling outcomes: a system that works, a report that arrives at 06:30, a straight-through rate above ninety per cent. If what you sell is a result, cheaper delivery improves your margin. If what you sell is effort, cheaper delivery destroys your revenue.

For buyers, the practical consequence is that you should be increasingly sceptical of proposals priced by team size. Ask what outcome is being committed to and how it will be measured. A vendor who cannot express their work as an outcome is telling you something about their pricing model.

Five questions separate serious work from a demo. First: what is your evaluation set, how many cases does it contain, and can we see the accuracy trend over the last three months? A team without an eval harness cannot tell you whether last week's change made things better or worse.

Second: what happens when the model is uncertain? "It handles it" is not an answer. There should be a confidence threshold, a human queue and a measured rate of escalation.

Third: where does our data go? Enterprise API tiers with training disabled, or self-hosted open-weight models for data that cannot leave the premises. If the answer is vague, assume the worst.

Fourth: what does it cost to run per thousand documents, and what did you do to get it there? A naive implementation can cost ten times a well-engineered one, and the difference is entirely in routing, caching and prompt design.

Fifth: what is the baseline? If nobody measured the current process before building, there is no way to prove improvement — only to assert it.

Our expectation, from what we see across client engagements: the volume of routine transaction processing done by hand in Kolkata businesses falls sharply, and it falls faster in companies with growing volumes than in flat ones — because the economics there are about avoiding a hire rather than removing a person.

Headcount in most of our clients has not fallen. What has changed is what those people do: exception handling, supplier follow-up, analysis and the judgement calls the system routes to them. Whether that holds across the wider economy is a genuinely open question, and anyone claiming certainty about it is guessing.

For IT services firms specifically, the differentiator becomes domain depth and accountability. Anyone can call a model API. Knowing which of a cement plant's forty daily numbers actually matters, and being willing to be accountable when the system produces the wrong one, is not something the tooling provides.