AI agents that do the work, inside the systems you already run

An agent is a language model given tools and a loop: it reads a goal, decides which tool to call, reads the result, decides again, and stops when the goal is met or it cannot proceed. The tools are the point — a function that looks up an order in ERPNext, one that creates a ticket in ServiceNow, one that drafts an email — and the model's job is to sequence them sensibly for a case it has not seen before. That is different from a chatbot, which only talks, and from classic workflow automation, which follows a fixed path and breaks on the first exception.

Agents pay where the work is repetitive, multi-step, exception-heavy and has a clear definition of done: three-way matching invoices to purchase orders and receipts and chasing the mismatches; triaging IT and HR tickets and resolving the ones with known fixes; onboarding a vendor by checking the documents, the registry and the sanctions list; preparing the weekly status report from Jira, timesheets and the risk register; answering a customer and then actually raising the return. Where the path is fixed and the exceptions rare, a workflow engine — Frappe's, Liferay's, or plain code — is cheaper and more predictable, and we will say so.

The assistant on this website is an agent in its smallest honest form. As a visitor talks to it, it records what it learns — name, company, need — as structured fields rather than prose, decides against a written policy when the visitor needs a person, and hands the conversation to our team on Telegram with the details already captured. One job, typed output, an escalation rule, a human at the end of the loop. Every enterprise agent we build is that pattern at larger scale.

We build agents as explicit graphs on LangGraph rather than as an open-ended loop. Each node is a step — gather context, classify, decide, act, verify, escalate — with defined inputs and outputs; the model is called only at the nodes that need judgement, and plain code handles the rest. The graph has a step limit, checkpoints so a long task can resume after a failure, and retries with backoff on tool errors. This structure is what makes an agent debuggable: when it does something odd, the trace shows the node, the state and the decision, not a wall of chat.

Tools are typed functions with schemas, built once and shared: a read tool for each system, a small number of write tools that are idempotent and permission-checked, and a set of 'propose' tools that draft an action for a human to approve. We expose them through MCP servers so that the same ERPNext or Liferay tool serves the finance agent, the support agent and the assistant in the portal. Knowledge comes from a retrieval layer — policies, product documents, past cases — so the agent looks things up rather than remembering them; short-term state lives in the graph, long-term memory in a store you control, and nothing is learned into the model.

The human gate is designed, not bolted on. Every action is classified as autonomous, notify or approve: a lookup runs freely; a draft reply is sent with a notification; a payment, a deletion, a contract change or an outbound message to a customer waits for a person in the tool they already use — the portal, Teams, Slack, an ERPNext workflow. Where a bank's maker-checker regime applies, the agent is the maker and a person is always the checker, which is exactly the control model behind the early-warning workflows we run for Bank of Baroda.

• Graph — explicit states on LangGraph; model calls only where judgement is needed; step limits, checkpoints, retries
• Tools — typed, idempotent, permission-checked; read / propose / write tiers; shared via MCP servers
• Knowledge — RAG over policies and past cases; no facts fine-tuned into the model
• Memory — graph state per task; long-term store in your database; retention you set
• Human gate — autonomous / notify / approve per action; approvals in the tools people already use
• Model — Claude, GPT or Gemini via API or in-region, or an open model on your infrastructure, chosen per node

Finance operations: invoice capture and three-way matching against purchase orders and goods receipts in ERPNext or SAP, with mismatches explained and routed; collections follow-ups drafted from the ageing report; month-end reconciliations where the agent finds the breaks and a person clears them. Procurement and vendor onboarding: the document checks, registry lookups and compliance questionnaires that L&T Infotech's supplier portal turned from a three-week cycle into four days by workflow alone — an agent now does the reading and the chasing, and the workflow keeps the audit trail.

IT and HR service desks: an agent inside the intranet that resolves password resets, access requests, leave queries and known-fix incidents against the identity, HR and ITSM systems, and hands the rest to a person with the diagnosis attached — the next step beyond the self-service that took Wipro's HR tickets from three days to four hours. Project and delivery operations: the status report assembled from Jira, timesheets and the risk register, which removed 80 % of project managers' reporting overhead at Fulcrum when it was automated, now with the narrative written and the anomalies flagged. Customer operations: order status, returns and claims handled end to end for retail and logistics platforms, with the action taken in the order system rather than described in a chat. Risk and compliance: KYC document review, alert triage and case preparation for banks, where every agent action is a maker's action awaiting a checker.

The question an operations lead asks is not 'is it clever' but 'what percentage of cases does it complete correctly, and what happens to the rest'. So we build the evaluation set first: a few hundred real, anonymised cases from the workflow — tickets, invoices, onboarding packs — with the correct outcome and the correct steps recorded by your team. Every version of the agent is replayed against that set in a sandbox of your systems, and we report task success rate, step accuracy, escalation rate and cost per task. A change to a prompt, a tool or the model that lowers the numbers does not ship.

Agents fail in characteristic ways — looping on a tool that keeps failing, calling the right tool with the wrong argument, declaring a task done when it is half done, or being talked into an action by text inside a document it was asked to read. Each has an engineering answer: step and cost limits, schema validation and idempotent tools, a verification node that checks the outcome against the goal before the agent stops, compensating actions for anything that must be undone, and treating every tool output — an email, a PDF, a web page — as data to be checked rather than instructions to be followed. These are built in from the first sprint, not added after the first incident.

Go-live is staged. Shadow mode first: the agent runs on live cases and proposes, a person does the work, and we compare. Then supervised mode: the agent acts on the cases it scores highest on, a person approves, and the approval rate is the release gate. Then autonomous mode for the case types that have earned it, with everything else still routed to people. The split is reviewed monthly and widened as the numbers justify — which is how the 'what happens to the rest' question gets a good answer.

The security team's first question is the right one: what can this thing do, and with whose access? Each agent gets its own identity in your directory with least-privilege access to exactly the systems and actions its job needs — never a shared service account, never an administrator token. Its tools enforce an allowlist of actions and a schema on every argument; spend limits cap model cost and rate limits cap actions per hour; anything the agent reads — documents, emails, retrieved passages, web pages — passes through prompt-injection defences before the model sees it; PII is masked where policy requires; and a kill switch pauses the agent, or all agents, in one action.

Every run is logged as an audit record: the goal, every tool call with its arguments and result, every decision, the approvals given and by whom, and the final outcome — kept in a store you own with the retention you set. That record is what turns 'why did it do that' from an argument into a lookup, and it is what a regulator or an internal auditor will ask for. Where the data may not leave your control, the model runs as a private deployment on your infrastructure and the whole agent stays inside your network; where an API model is permitted, prompts are minimised to what the step needs. We document the controls against the framework that governs you — RBI and SAMA for financial institutions, DPDP and PDPL for personal data — as a control matrix your security review can work through before the first supervised run.

As a guide from our engagements: a two-week discovery picks one workflow with a measurable success criterion, maps the systems and actions involved, classifies each action as autonomous, notify or approve, and produces the evaluation set and a costed plan. A four- to six-week pilot builds the agent against a sandbox and runs it in shadow mode on live cases, ending with measured task success, escalation rate and cost per task. Production — supervised mode, permissions and audit, integration into the tools your team approves in, monitoring and hand-over — is typically three to four months from kick-off, and each further workflow is faster because the tools and the platform are already there.

Five things set the cost. The number of systems the agent must act in and the quality of their APIs — a clean ERPNext or ServiceNow API is one thing, a legacy system with no API is another; the permission model and how many approval paths it needs; the exception rate of the workflow and the quality bar, which decide how much evaluation and hardening is needed; the model choice, where API models are cheapest to start and a private model is mandatory for some data; and the human-review design, because an approval flow inside a portal your team already uses costs more to build than an email but is what gets adopted. Running costs are model tokens per task plus the platform, and we report cost per completed task monthly against what the manual process cost.

Discovery is a fixed fee, the pilot a fixed price, and production a fixed price for the agreed scope with change control. We do not publish a rate card because an agent without a workflow inventory is a guess; tell us the workflow, the systems and the volume, and we will send a bracket within a week.

Not every automation needs an agent. If the path is fixed and the exceptions are rare, a workflow engine — the one already inside ERPNext or Liferay, or a general tool — is cheaper, faster and easier to audit, and adding a model to it adds cost without value. If your vendor already ships a copilot for the job — a ticketing tool's triage assistant, an ERP's reconciliation helper — and it acts inside that one system only, use it; we integrate it rather than compete with it. A custom agent earns its place when the work crosses systems, when the exceptions are the work, when the vendor's copilot cannot reach the systems that matter, or when the data and the model must stay under your control.

Most of what we build sits on top of platforms we already run for the client — an ERPNext instance, a Liferay portal, a Spring Boot or FastAPI backend — which is why the tools are quick to build and the approvals land in a screen people already open. The broader practice — RAG assistants, private models, LLM integrations, responsible-AI process — is on the enterprise AI services page.