An agent is a system that can decide what to do next and then use your tools to do it: look something up, write a record, send a message, escalate to a person. The interesting engineering is not making it act. It is deciding what it may act on, and making sure somebody can see what it did.
This is for you if
Where this is used
All of these have the same shape: several steps, more than one system, and a decision in the middle that a rule alone cannot make. Where the work is one step and the rule is fixed, you do not want an agent. You want a script, and it will be cheaper and more reliable.
Checks the order, issues the refund inside your limits, books the collection, and hands anything outside those limits to a person with the work already done. Touches: helpdesk, order system, payments.
Finds the purchase orders with no delivery note, works out who to ask, drafts the email, and follows up. The job nobody enjoys and everybody postpones. Touches: ERP, email, spreadsheets.
Reads the account history, the last three tickets and the contract, and puts a short brief in the CRM before the call. Reading, not writing, so the risk is low and the time saved is real. Touches: CRM, tickets, documents.
Sorts what has gone wrong, gathers the evidence for each, fixes the ones with a clear remedy, and sends the rest onward already investigated. Touches: monitoring, ticketing, your own systems.
Your customers ask your product to do something and it does it, within that user's own permissions. Sold as a feature of your product rather than as a separate tool. Touches: your own application and its API.
Building the standard connectors that let agents and assistants reach your internal systems safely, so each new use does not need its own integration written from scratch. Touches: whatever you choose to expose.
Services
A demonstration agent takes a week. The difference between that and something you would let near a customer is entirely in the boring half of this list.
If the steps are always the same and the rules never bend, a plain automation is cheaper, faster and easier to test. An agent earns its complexity only where the path genuinely varies. We will tell you which you have.
Every action listed, with a limit and an owner. Refund up to this much. Never change a price. Always ask a person before emailing a customer. This document is the actual product, and it is signed off before code starts.
Each action is a separate, narrow tool with its own permissions, its own limits and its own log. Not a general connection to your database. An agent should not be able to do anything nobody deliberately gave it.
An agent guessing at your policies is worse than no agent. It retrieves from your documents and records, with citations, so its reasoning starts from something true.
Some actions run freely, some need a person, some need a person above a threshold. Configured rather than coded, so you can tighten it after a bad week and loosen it after a good quarter.
When it is unsure, blocked or looping, it hands over with what it has gathered. An agent that keeps trying alternatives until something works is the one that causes the incident.
Instructions hidden inside an email, a document or a web page it reads, telling it to do something else. This is the defining security problem of agents, it has no complete fix, and it is managed with narrow tools, approval steps and treating retrieved text as untrusted.
What it was asked, what it looked at, what it decided, which tool it called, what came back, and who approved. When someone asks why a customer got that refund, the answer exists.
Anyone can test the happy path. We build a set of cases where the correct behaviour is to stop, escalate or say no, and rerun it on every change. That set is worth more than the demonstration.
Limits on steps, tool calls and spend per task. Alerts on unusual behaviour. A single switch that stops it safely mid-task. Agents fail in loops, and a loop with a company card attached is expensive.
Watching only, then acting on a small share of cases, then more. Each stage compared against what your team would have done. Nothing goes from demonstration to full traffic in one step.
Describe the task and which systems it touches. We will tell you if an agent is the right answer.
Our stack
Including MCP, which is the emerging standard for connecting AI systems to tools. It is worth knowing about because it decides whether your integrations are reusable or written again for every project.
Example
A support agent, with a refund limit set by the client. The step worth reading is the fourth.
A customer writes in about a damaged item. The agent locates the order, the delivery record and the two previous tickets from the same customer.
Not from memory. It retrieves the returns policy and quotes the clause that applies, so the decision can be checked afterwards against the same words a person would have used.
The refund is below the threshold the client set, the order qualifies, so it issues the refund and books a collection. Two tool calls, both logged, both attributed to the agent.
This is the third damage claim from this address in a month. That is not in the returns policy, so it has no rule to apply. It refunds nothing further, writes what it found, and sends it to a supervisor. Guessing here is exactly what you do not want.
The supervisor sees the three claims side by side with the evidence gathered, and makes the call. The decision is recorded against her name, not the agent's.
Months later, one search shows the original message, the policy clause it used, every tool it called, what came back, where it stopped and who approved what.
An example, with invented details, to show where the boundaries sit. Your limits and approval points would be yours.
FAQ
It is as safe as the limits you put on it. An agent that can only take actions you listed, with approval above your threshold, and that stops when unsure, is a controlled system. An agent given broad access to act because it demonstrated well is not. The difference is engineering, not the model.
It is an emerging standard for exposing a tool once so that any AI system can use it, rather than writing a new integration for every project. If you expect more than one AI use of the same system, it saves real work. If this is a single narrow project, it may be unnecessary and we will say so.
Nothing completely, and be careful of anyone who tells you otherwise. It is managed rather than solved: narrow tools, approval on anything consequential, treating retrieved content as untrusted, and testing specifically for it. That is the honest state of the field today.
Automation follows a path you defined. An agent chooses the path. Where the steps are fixed, automation is cheaper and easier to test, and we would rather build you that. Agents are for work where the route genuinely varies.
More per task than a fixed automation, because it reasons at several points. We cap the spend per task and report cost per completed task, so it is a number you watch rather than discover.
Yes. Open models handle tool use well enough for most agent work now. The strongest reasoning is still hosted, so a common arrangement is private for the routine steps and a hosted model for the difficult decision, when your rules allow it.
Next step
What the work is, which systems it touches, and the one action you would never want taken without a person. That last part tells us more about the build than anything else you could send.
Ahmedabad, India. We work with teams in the US, UK, Europe, Singapore and the Gulf, and we are used to the time difference.