India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
AI Agents That Execute Multi-Step Business Workflows Under Control
An AI agent is a language-model application that plans a task, calls business systems through defined tools, checks results and either completes the work or hands it to a person for approval. NTSPL builds agents for operations teams with repetitive, multi-system casework, such as clearances, settlements and onboarding, where each step must be permissioned, logged and reversible.
Delivered on
In scope
What a Production AI Agent Actually Does Between Trigger and Approval
Back-office casework is rarely one decision. A customs file, an employee exit or a vendor onboarding touches five systems, two inboxes and a spreadsheet, and the person doing it spends most of the time collecting facts before making a judgement. RPA scripts break when a screen changes and cannot read an email that says 'please see revised invoice attached'. Teams have seen agent demos that book meetings and write code, but nobody wants an agent with ERP write access and no record of why it acted.
NTSPL designs agents as constrained workers. Each agent gets a narrow job description, a small set of typed tools with read or write scope declared per tool, and explicit points where a named human approves before anything is posted, paid or sent externally. We build the deterministic skeleton in a workflow engine and let the model handle only the judgement steps, then measure task completion and override rates against a replay set of real historic cases.
Casework Patterns Where Agents Outperform Scripts and Queues
Signals you need AI Agents & Workflow Automation
- A team of 10-60 people handles 2,000+ similar cases a month that each require pulling data from 3-6 systems before a decision.
- Average handling time is above 30 minutes, and more than half of it is fact gathering rather than judgement.
- RPA bots exist but fail on more than 10% of cases because inputs arrive as free-text emails, PDFs or scanned attachments.
- Backlogs spike at month-end or season peaks and the business cannot hire temporary staff fast enough.
- Auditors already ask for a step-by-step record of who did what on each case, which the current manual process cannot produce.
When to choose something else
- If the workflow is fully structured with stable inputs, a conventional workflow engine or integration flow is cheaper and more predictable than an agent.
- If the main need is answering questions from documents with no actions taken, build a RAG knowledge assistant instead.
- If no system exposes an API and screens change monthly, fix integration access first; an agent driving a fragile UI inherits the fragility.
Agent Components We Design, Build and Hand Over
Case and task decomposition
Map 30-50 historic cases step by step, separating deterministic steps from judgement steps and identifying the approval points the business insists on.
Tool layer
Typed tools over ERP, HRMS, TMS or DMS APIs, each declared read-only or write, with input validation and idempotency keys for every write.
Agent reasoning and prompts
Planner and checker prompts, structured output schemas and few-shot examples drawn from real cases rather than synthetic ones.
Human approval surfaces
Approval cards in Teams, Google Chat, email or the case system showing the agent's proposed action, evidence and confidence.
Trace, audit and replay
Every plan, tool call, response and approval stored with a case ID so any outcome can be reconstructed and replayed against a new version.
Operations runbook
Kill switch, rate limits, stuck-case alerts and a weekly override review led by the process owner.
Controlled Agent Runtime: Tools, Memory, Approvals and Trace
Controlled Agent Runtime with Typed Tools and Approval Gates
A case event starts a workflow that calls the agent only for judgement steps; the agent uses scoped tools to read systems, drafts an action and pauses for human approval before any write. Every step is traced against the case ID and replayable.
Select any component
Controlled Agent Runtime with Typed Tools and Approval Gates: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Agent Services on AWS, Azure and Google Cloud Compared in Practice
We run the agent on AgentCore Runtime with AgentCore Gateway exposing internal APIs as tools and AgentCore Identity handling credentials, while Step Functions owns case state and approval waits via task tokens.
Foundry Agent Service hosts the agent with tools defined as OpenAPI specs or Functions; Logic Apps handles approvals in Teams and Outlook, and each agent gets its own Entra identity with scoped app roles.
Agents are written in ADK and deployed on the agent platform or Cloud Run; Workflows manages long-running case state with callbacks for Google Chat approvals, and tools run under dedicated service accounts.
Autonomy, Tool Scope and Orchestration Choices for Safe Agents
Autonomy level per action
We grade every action: L0 suggest only, L1 act with approval, L2 act and notify, L3 act silently. New agents start with all writes at L1. An action moves to L2 only after 500 approved instances with an override rate under 2%. Payments, statutory filings and external communications stay at L1 permanently unless the process owner and risk team sign off in writing.
Workflow engine versus agent-led planning
Let the model plan only where the path genuinely varies. If 80% of cases follow the same five steps, encode those in Step Functions, Logic Apps or Workflows and call the model for classification, extraction and drafting. Fully agent-planned flows suit investigation tasks with unpredictable paths, and even there we cap tool calls at around 12 per case.
Tool design
Fewer, coarser tools beat many fine-grained ones. A tool such as get_shipment_status(awb) returning a validated object works better than exposing raw SQL. Each tool declares read or write, required approval level and idempotency key. We expose internal APIs through a gateway or MCP server so permissions are enforced outside the model, never by instruction alone.
Single agent or multi-agent
Start with one agent and a checker step. Split into multiple agents only when distinct sub-tasks need different tools, permissions or models, for example a document reader with no write access and a posting agent with narrow ERP rights. Each extra agent adds latency of 2-6 seconds and a new failure surface, so the split must earn its cost.
Replay-Tested Agent Delivery in Six Steps
Case archaeology
Walk through 30-50 historic cases with operators, timing each step and recording where judgement, rework and approvals happen.
Tool and permission design
Define typed tools, scopes and approval levels with each system owner; build stubs against non-production APIs.
Agent build and replay set
Implement planner, checker and workflow; assemble 200-400 historic cases with known outcomes for automated replay.
Shadow mode
Agent proposes actions on live cases while humans work as usual; compare proposals with actual decisions daily.
Assisted production
Agent drafts and humans approve every write; override reasons feed prompt and tool fixes.
Autonomy review
Process owner promotes specific actions to higher autonomy based on override data, recorded in the permission manifest.
What you receive
Measuring Agent Throughput, Accuracy and Human Override
| KPI | Typical target |
|---|---|
| Cases completed without rework after approval | 85-95% |
| Human override rate on proposed actions | Under 8% at assisted stage, under 2% before autonomy promotion |
| Average handling time per case | 40-70% reduction |
| Cases stuck beyond SLA due to agent loops or tool errors | Under 0.5% |
| Replay pass rate before each release | No regression above 1 point |
Agent Failure Modes: Excessive Agency, Loops and Silent Errors
| Risk | How NTSPL prevents it |
|---|---|
| Excessive agency: the agent performs a write it should not | Write tools require approval tokens issued by the workflow engine, and scopes are enforced at the API gateway rather than in prompts. |
| Prompt injection through inbound emails or documents | Untrusted content is passed as data fields, never as instructions, and a classifier screens inbound text before the planner sees it. |
| Loops and runaway token spend | Per-case caps on tool calls, tokens and time, with stuck cases routed to a human queue and alerted. |
| Silent wrong outcomes that pass approval | Weekly sampled audit of approved cases and checker rules for the highest-value fields, such as amounts and dates. |
AI agents vs RPA: which should automate our back-office process?
Use RPA, or better an API integration, when inputs are structured and screens are stable; it is cheaper per transaction and fully deterministic. Use an agent when cases arrive as emails, PDFs and exceptions that need reading and judgement before the next step, which is where RPA failure rates climb above 10-15%. In most programmes we build a hybrid: the workflow engine and existing bots handle fixed steps, and the agent handles classification, extraction, reconciliation and drafting. Replacing a working bot with an agent just to modernise adds cost and variability with no gain.
Key facts: AI Agents & Workflow Automation
AI Agents & Workflow Automation in Practice
2 AI Agents & Workflow Automation scenarios, from Logistics (customs brokerage and clearance) and HR shared services (diversified manufacturing group), plus related platform case studies.
Customs broker clears import filings 2.4x faster with an agent that prepares each file
HR shared services settles employee exits in 9 days instead of 34 with an agent
General insurer cuts motor-claim intake from 2 days to 25 minutes with serverless
Infrastructure company's legal team reviews contracts in hours, not days
AI Agents & Workflow Automation: Frequently Asked Questions
Will an AI agent make decisions without human approval?
Only where you explicitly allow it. Every action is assigned an autonomy level, and new agents start with all writes requiring approval. Actions move to notify-only status after hundreds of clean approvals and a documented sign-off. Payments, filings and customer communications usually stay behind approval permanently.
How long and how much does a first agent take?
A first agent for one well-defined case type typically takes 10-12 weeks to assisted production, with indicative NTSPL fees of about ₹22-45 lakh depending on the number of systems and approval surfaces. Run costs are usually ₹8-40 per case in model and orchestration spend, depending on documents and tool calls.
Which systems can the agent connect to?
Anything with an API, a database view or a message queue: SAP, Oracle, Dynamics, HRMS, ticketing tools, transport systems and email. We prefer API or MCP-server access with a dedicated service identity. Screen-driving is a last resort and only for read steps.
How do we audit what the agent did on a case?
Each case has a trace showing the trigger, every plan step, tool call, tool response, checker result and the approver's decision with timestamps. Traces are retained in-region per your policy, and the replay harness can rerun any historic case against a newer agent version to show what would change.
How does CERT-In or the DPDP Act affect agent design?
Agents are new privileged identities, so their actions must be logged and retained, typically for at least 180 days in India to meet CERT-In's 2022 directions, and incidents must be reportable within six hours. Under the DPDP Act 2023, agents should access only the personal data needed for the case purpose.
What happens if a connected system is down?
The workflow engine holds case state, so the agent does not lose progress. Tool calls retry with backoff, and after a set threshold the case moves to a human queue with the work done so far. No write is retried without its idempotency key, so duplicate postings are prevented.