AI Agents That Work Inside Your Business Systems

An AI agent is software given a goal and a set of actions it is allowed to take, which then decides which of those actions to take to reach the goal. In a business that usually means reading something that arrived — an email, a PDF, a message, a new record — working out what it is, checking it against your rules, and then doing something: updating a system, routing an approval, drafting a reply, or escalating to a person. The defining feature is that it acts, rather than only answering.

A chatbot answers a question a person asked. An agent completes a task a trigger started. A chatbot that gets it wrong gives a bad answer someone can catch before acting on it; an agent that gets it wrong writes a bad record into a live system, which is why an agent build spends most of its design time on permissions, approval points, and logging. Many businesses end up with both: the agent does the work, and a chat interface is how people talk to it.

Our AI work is priced as fixed-scope sprints, typically RM 8,000-15,000 for a 2-3 week implementation, and an agent build is quoted the same way: one agent, one named job, one price agreed in writing before the build starts. The number moves with how many systems the agent has to reach, how messy the inputs are, how many actions need a human approval step, and whether processing has to stay on infrastructure you control. Running costs are separate: model usage is billed per token by the provider, and WhatsApp messaging is billed by Meta.

Two to three weeks for one agent with a clearly named job. The scoping workshop runs in the first few days, the build and integration take the middle, and the last stage runs the agent alongside the existing manual process before it takes over. What pushes a project past three weeks is almost never the build — it is waiting on access to a system, or discovering that the business rules everyone described are not the rules actually being applied.

Yes, and this is usually the deciding question rather than a detail. Where a system has an API we use it. Where it does not, there is normally still a safe route: a read-only database view, a scheduled export, or a monitored file drop. An on-premise SQL Server with no public endpoint is reachable when the agent runs inside your network, which cloud-only automation platforms cannot do. We map the routes and confirm access before quoting, because that is what the scope depends on.

Handle inputs nobody standardised, and decisions that need context. A script does the same steps in the same order every time, which is exactly right when the rule is a straight line. An agent earns its cost when the input is forty different supplier invoice layouts, an enquiry written in mixed English, Malay, and Chinese, or a request that has to be checked against a policy before anyone acts on it. If your rule is genuinely if-this-then-that, a script is cheaper and breaks less often, and we will tell you so.

When the rule is a straight line with no judgement in it. When the underlying process is broken rather than slow, because an agent running a bad process only produces bad outcomes faster. When the job runs a handful of times a month and the build cannot pay back. When nobody internally will own it. And when the data it would need does not exist in any system yet — capture it first, automate it second. We would rather say this on the scoping call than in week three.

By deciding what it may do before it is built, not after. The agent gets its own credentials with the narrowest permissions the job needs rather than a shared admin login, the actions it may take alone are written into the scope document, and everything else stops for a human approval. Every action is logged with its trigger, its inputs, and who approved it, so a decision can be audited afterwards. Write access to anything financial or customer-facing stays gated by default.

Yes. Where documents cannot leave your infrastructure, the model runs inside your environment or private cloud instead of calling a public API. That changes the shape of the cost rather than only the number: you take on the hosting and hardware, and the choice of model narrows to what runs well on the machine you have. We scope it with you rather than assuming it, because for many workflows the sensitive fields can be masked before anything reaches a model at all.

You do. Hosting accounts, API keys, and model credentials are in your company name from day one, and handover includes documentation, a runbook for what to do when a run fails, admin access, and training. Thirty days of tuning after go-live are included, because the first weeks of real inputs always surface edge cases a workshop cannot. After that, ongoing support is available under a separate agreement if your team would rather not own it.