Home / Services / AI agent development

Service · Aarohii AI Solution Private Limited

AI agent development

An agent decides on steps and calls tools to finish a task. Because it can change state in another system, the interesting work is the policy around it — not the loop.

Agent or workflow?

This is the first question, and for most requests the honest answer is "workflow." If the steps are known and fixed, write the steps and put one model call inside them. A deterministic workflow is cheaper to run, easier to test, and far easier to explain to an auditor than a loop that re-decides its own plan on every execution.

An agent earns its complexity when the path genuinely varies per case: the next step depends on what the last tool returned, and enumerating the branches in advance would be longer than the task. Background: what is an AI agent and agent vs chatbot.

The pieces we build

An agent that can call tools is useful only if you can list the tools, the policy, and the evaluation that proves it stayed inside both. If you cannot name all three, you do not have an agent — you have an autocomplete holding API keys.

• Planner or loop — usually a single model with an explicit tool list, not a hierarchy of models delegating to each other.
• Tools at least privilege, so the worst case is bounded by the credentials rather than by the model's judgement.
• Approval gates before irreversible actions: refunds, sends, deletions, anything a customer sees.
• Short memory or none. Long-lived memory is a product decision with a privacy cost, not a free upgrade.
• Traces for replay, so a failure can be reproduced and fixed instead of described.
• A stop condition, plus a step and spend ceiling per run, because a loop without a bound is an outage waiting for a bad input.

Blast radius, decided on purpose

We write down, per tool, what the agent may do without asking and what always needs a human. Read operations are usually free. Writes to internal systems are usually gated at first and relaxed once the override rate shows review has become theatre. Anything a customer receives — an email, a refund, a status change — stays gated until there is evidence, not optimism.

The same document names who can turn the agent off, before an incident rather than during one. That is the practical half of AI governance.

How we evaluate an agent

Task-level tests on real cases: did the run reach the right end state, using tools it was allowed to use, within the step and cost ceiling? Trajectory matters as much as outcome — an agent that reached the right answer by calling a tool it should not have touched has failed the test it matters most to pass.

Traces make this possible, which is why observability is built in the first week rather than added after the first incident. See AI testing.

What we will not do

We do not grant write access to production systems on day one. We do not build agents that act on customer-facing decisions without a human gate. And we do not sell an agent when a workflow would do the job — the second conversation on most agent enquiries ends with a simpler, cheaper scope.

How an engagement runs

1. 20-minute fit call — we say yes or no, including "this should be a workflow."
2. Written plan — tools, approval policy, stop conditions, success tests.
3. Build with traces and weekly demos you can inspect.
4. Support after launch — we stay for the messy month, not just demo day.

Proof you can open without an NDA: Captverse, Auvora, ViraQueue. Buying notes: what drives cost.

Questions